Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Use GitHub actions for continuous integration (CI) #442

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

Merged
merged 1 commit into from
Jan 26, 2021

Conversation

clue
Copy link
Member

@clue clue commented Jan 23, 2021

Bye bye Travis CI, you've served us well.

This changeset replaces the existing Travis CI integration with a new GitHub actions workflow. Travis CI has served us well for years, but is in the process of discontinuing its previous open source support. Right now, Travis CI builds may take anywhere from a few minutes to several hours.

The new GitHub actions workflow is designed to be as close as possible to the original definition, it does not introduce any new features. The GitHub actions workflow is significantly faster and uses higher concurrency, so it should take no longer than a couple of minutes to execute. Other than that, this switch should not have a noticeable impact on anybody contributing to this project.

I'm filing this PR here in the hope we can discuss this once and then later apply similar workflows for all our components. I've prepared PRs for this and will file these as soon as this one is merged.

Builds on top of #439 and clue/reactphp-flux#21

@clue clue added this to the v1.2.0 milestone Jan 23, 2021
@clue
Copy link
Member Author

clue commented Jan 23, 2021

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.

@clue clue requested review from jsor and WyriHaximus January 23, 2021 17:11
Copy link
Member

@WyriHaximus WyriHaximus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@clue clue force-pushed the github-ci branch 2 times, most recently from 1e6c966 to a99f4c1 Compare January 24, 2021 15:36
Bye bye Travis CI, you've served us well.
@clue
Copy link
Member Author

clue commented Jan 24, 2021

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 :shipit:

@WyriHaximus
Copy link
Member

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 :shipit:

@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 :shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants