Faciliate installation in the CI

[theofidry]

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:

• if you install those tools with that action:
  • I don't know if there are verified
  • It may be a different version than what you specified with phive
  • You need to be explicit (as opposed to $ phive install)
• if you use phive in the CI:
  • you might get rate limited by the GitHub API
  • you need to specify the GPG key...

Do you have any suggestion/recommendation on how to make it easier?

[theseer]

Partially.

you might get rate limited by the GitHub API

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 GITHUB_AUTH_TOKEN set in the environment, for instance via the settings -> security: secrets -> actions.

you need to specify the GPG key...

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 phive install things from any open source project all the keys they accepted would be auto-imported. That would make you inherit their trust choices. Not exactly a good idea ;)

I'm not sure what the best option would be here? Maybe store the key id in the phive.xml and add an option to explicitly auto-imoport trusted keys from it?

[theofidry]

I'm not sure easier.

From a practical PoV, I can see it as a show-stopper:

1. There is https://github.com/bamarni/composer-bin-plugin that can help you to install such tools as their package version without polluting your code
2. https://github.com/shivammathur/setup-php already helps to install such tools in the CI

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:

• Would it make sense to list the trusted keys within .phive and:
  • Add an option to take it as the list of trusted keys; not done by default, allowing to do so for the CI
  • When passing the option whilst not in the CI, show a fat warning which could link to a doc entry to discourage users from abusing it or accidentally use it without being aware of the problem?
• Might be silly but do we care at all about the trusted keys in the CI? I.e. would it hurt to install those PHARs without have the keys checked at all there?

[theofidry]

Coming back to this:

Would it make sense to list the trusted keys within .phive and:

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)

Might be silly but do we care at all about the trusted keys in the CI? I.e. would it hurt to install those PHARs without have the keys checked at all there?

Still relevant IMO. At this point, which tool you added has been "acknowledged"/vetted already.

[theseer]

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.

[theofidry]

FWIW I'm happy to talk about that in a call too :)

[theseer]

Sounds like a plan :) Now we need to find a time slot :)

[pereorga]

I'm not sure if this has been discussed before, but could you consider adding a --insecure or --skip-gpg-verification flag to phive?

I use phive to download and update tools, as it is faster than Composer, and because it helps reduce the risk of dependency conflicts, and not because it is more secure. While I understand that security is a primary goal of phive, for my use case, HTTPS verification is enough, and I would prefer not to install GPG in the CI pipeline.

[pereorga]

One other thing that may facilitate using phive in the CI is releasing a version that supports PHP 8.4. PHP 8.4.0 Beta 3 is already available, but can't be tested in the CI for projects that require phive.

[theseer]

Version 0.15.3 has been released with PHP 8.4 support.