For the reference: The test run will only be triggered for any push or PR after this PR has been merged. This makes it a bit harder to review to see if the suggested workflow is actually successful. You can check the build status on my fork which executes the workflow from this PR branch: https://github.com/clue-labs/reactphp/tree/github-ci This is one time setup only, after this is merged, the build status will also show up in this repository.

Suggested changes result in not having to add new PHP versions every time a new version is released. The action takes version ranges into account so it won't include versions outside that range.

@WyriHaximus Thanks for your suggestion! I agree this is an excellent suggestion and something that clearly demonstrates how GitHub actions are way more powerful than Travis has ever been!

That being said, I have indeed evaluated this option after we've originally talked about this a few weeks back and think the current suggestion would be better suited for our use case.

By relying on the automatic PHP version detection, a random PR that is opened some time in the future may fail because a new PHP version might have been tagged in the meantime. This means future PR reviews and development may be slowed down with something that's out of our control. Think awesome feature X in 1 year can not be merged because some obscure TLS error handling doesn't work as we're used to with a fresh PHP 8.1 release.

Of course, we could get rid of the open ended PHP version constraint which we're currently using in all our components, but this comes with its own set of pros and cons, so this is something I would rather discuss in a separate ticket.

I agree having to manually add future PHP versions to this list is not something that sounds like a very interesting task. I think this is however preferable because it's a) exactly what we did with Travis and known to be a reasonable amount of work and b) something that can easily be automated in the future (think a dedicated GitHub action that works kind of like dependabot?).

Besides this suggestion, I've applied all other suggested changes 👍 My vote regarding automatic PHP versions would be to keep this as-is. We can always change this in the future as discussed above, so I don't think this should block the introduction of GitHub actions

Besides this suggestion, I've applied all other suggested changes 👍 My vote regarding automatic PHP versions would be to keep this as-is. We can always change this in the future as discussed above, so I don't think this should block the introduction of GitHub actions

@clue The discussion about that doesn't block getting this in. Still think it is the better option, and possibly combined with scheduled runs we can mitigate that. But let's discuss that another time