New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Faciliate installation in the CI #384
Comments
Partially.
I don't know why Github rate limits their own action subsystem and not auto-grants the same API access levels as when authenticating with an API token. But phive supports github auth tokens - simply ensure we have a valid token in
This is indeed a bit annoying. I'm open for suggestions here, but it feels like a general conflict of interests: When run locally, you want to interactively be asked whether to import an unknown key. In CI, no means of interaction exists yet auto-importing everything would kill the very idea of using keys. Our current compromise is to specify a list of trusted keys and with that have a means to auto-trust them for importing. One might argue, we could persist the acceptance of the key in use when done locally. But that's dangerous, as long as we use a shared key storage as it would allow to poison the key store: When you I'm not sure what the best option would be here? Maybe store the key id in the |
I'm not sure easier. From a practical PoV, I can see it as a show-stopper:
The current reason why I would personally pick 1) over 2) is that I can make sure it's the same tools installed locally and in the CI: the least variation in setup and how things are running I have between my local environment and the CI the better. There is inevitable differences of course, but it's still something I'm striving for. However I do like PHIVE so I would like to make it work more easily! Maybe two possibilities:
|
Coming back to this:
This would also offer the benefit of being able to cache it and even create a GitHub Actions step that takes care of it (it would be quite a simple step: cache/restore that directory + run phive install)
Still relevant IMO. At this point, which tool you added has been "acknowledged"/vetted already. |
I totally see that we need to find a better automated/CI support. I'm just not sure yet what approach is feasible without sacrificing security ;) Phive has quite some things that need to get addressed. This certainly one of them. |
FWIW I'm happy to talk about that in a call too :) |
Sounds like a plan :) Now we need to find a time slot :) |
I've been giving another try to phive, locally I'm quite happy with it but the CI integration is a bit more annoying.
The GitHubAction shivammathur/setup-php does quite a good job at facilitating things and in fact allows to install multiple tools, but you have the following problems:
$ phive install
)Do you have any suggestion/recommendation on how to make it easier?
The text was updated successfully, but these errors were encountered: