CI `run` job only tests with lock files about composer-install

[ramsey]

I'd love to test ALL THE THINGS, but GitHub Actions only allows for 256 jobs per workflow run, so we'll need to get creative with how we test these different permutations. Adding just one more item to the matrix will probably put us over this limit.

[jrfnl]

Maybe we could get creative with, for instance, combining testing --lowest, --highest and --locked in the same run (by using something like git reset HEAD and deleting the vendor directory between the steps ? That would reduce the number of build significantly.

[jrfnl]

Just thinking, testing various Composer versions could probably also be done in the same run using --self-update --1/--2.

Want me to do some experimenting ?

[ramsey]

Sounds good to me. Feel free. This is an issue lots of us run into for libraries that have lots of permutations like this. It'd be nice to have an approach we can replicate.

[jrfnl]

Been doing some thinking about this and came up with some more brainfarts ;-)

The integration tests as they are, basically always do a "clean install", i.e. presume there is no vendor directory in place yet (either because it was committed to a repo or because the action is used multiple times within a single workflow).

That would remain the same if the repo would be brought back to its original state between tests as per the suggestion in comment #219 (comment)

Would it make sense to also test "unclean" installs ? Run select integration tests without the "cleaning up" between tests ?

Note: the integration tests don't actually test the caching part of this plugin as such anyway and that wouldn't change.

Also, once the integration test runs have been changed as per this issue, the matrix for the expect test could be expanded to cover multiple PHP versions.

What do you think @ramsey ?