-
Notifications
You must be signed in to change notification settings - Fork 29
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
[CMS-319] Add Github Actions support #107
Conversation
- Convert TravisCI to Github Actions - Convert PHAR generation to use Box - Remove (now) unused prep scripts - Add release workflow (WIP)
Looks pretty good. Have you used your fork to demonstrate that the release operation is working? |
@@ -15,14 +15,16 @@ | |||
$project_composer = dirname( dirname( dirname( __FILE__ ) ) ) . '/composer.json'; | |||
$built_phar = dirname( dirname( dirname( __FILE__ ) ) ) . '/wp_launch_check.phar'; | |||
|
|||
// Load WPLC via Phar |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way this could be done in a Behat bootstrap or init function, rather than running this code whenever this file is included?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really wanted to rewrite this, but every time I attempted it, there was some weird error as to how WPCLI was being loaded and how it included Launch Check. I'll agree this is pretty brittle, but I took the approach of baby steps to just get Behat running successfully. I even made an attempt to migrate from Behat v2 -> v3, but that caused more headache, so I abandoned that in the interest of just getting Github Actions working.
Yes. I could use some help figuring out the logic of when the release runs. Right now I have it set to a tag push that matches a semver regex, but it should probably include some kind of protected branch mechanism? This piece is a bit out of my depth. The validation workflow is meant mostly for PRs. The release workflow includes the same validation job as a requirement before continuing with the packaging and release.
The release requires at least one Github release before subsequent releases are generated (has to do with fetching the previous release git reference to capture the commits between the last release and HEAD. |
This should also close #95 as Travis would no longer be used. |
Encrypted env variables are not accessible through pull requests from forks https://docs.travis-ci.com/user/pull-requests#pull-requests-and-security-restrictions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed. All of the changes are either specific to the Travis -> GitHub Actions change or other minor non-code changes.
Since TravisCI.org is no more and we tend to be adopting Github Actions, I thought I would start converting the Travis config over to Github Actions. I tried to make as few changes as possible, but mostly remove duplicative code and standardized some processes on other tools (like using Box to generate the Phar).
You can see the successful run here: https://github.com/kyletaylored/wp_launch_check/actions/runs/1074096395
Todo
PANTHEON_WPVULNDB_API_TOKEN
)