Conversation
b5e757e to
6714969
Compare
|
Plugin builds for 9568f67 are ready 🛎️!
|
cddb1c6 to
2df4fe7
Compare
johnwatkins0
left a comment
There was a problem hiding this comment.
@pierlon This is very impressive. My review mainly consists of questions rather than requests for changes. It looks like it's all working, which is awesome.
| run: echo "::add-matcher::${{ runner.tool_cache }}/phpunit.json" | ||
|
|
||
| - name: Set up tests | ||
| # TODO: Add step to install plugins instead of relying on .dev-lib |
There was a problem hiding this comment.
Correct me if I'm wrong, but couldn't we do this now by moving the code from .dev-lib into install-wp-tests.sh? It seems like this PR gets us 90% of the way toward removing the wp-dev-lib dependency. Can we get to 100%?
There was a problem hiding this comment.
Good question. The original intention was to remove the wp-dev-lib dependency but I realized it is being used for generating the readme (@westonruter any other uses I'm missing?) which also relies on the .dev-lib file, so I didn't spend much time looking into migrating the installation of the plugins just yet. I suppose that still can be done and then we could leave the .dev-lib file in place until all use cases for it are migrated.
| @@ -0,0 +1,64 @@ | |||
| name: External Libraries | |||
There was a problem hiding this comment.
Curious, why are these tests in a separate configuration? Shouldn't these also depend on the preceding linting/testing?
There was a problem hiding this comment.
Technically these libs aren't apart of the plugin so these tests shouldn't be impeded by the plugin's lint/tests jobs (unless I'm missing something here).
/cc @schlessera
There was a problem hiding this comment.
I'm currently working on extracting these libraries out (https://github.com/ampproject/amp-toolbox-php), so we shouldn't waste too much thought on these. I will rebuild GHA testing on that other repo.
There was a problem hiding this comment.
Awesome! WIll remove the workflow then.
|
The current approach here is to run lint jobs first, then if those succeed it moves on to running the tests, then it builds the plugin for deployment to GCS and finally comments on the PR with links for downloading those builds. One major drawback with this approach is that if any of these jobs fail for whatever reason, the whole workflow has to be re-run (i.e. if a test job fails, all lint jobs have to be re-run irregardless of their outcome). The only alternative I see so far is to split the relevant jobs into separate workflows. That allows for easier re-run of jobs if they fail, but it also means that all jobs would be running in parallel as there is currently no way for separate workflows to depend on one another (i.e. all workflows would be running in parallel). Any thoughts on this? Should we keep the linear approach and have one workflow with all the jobs, or split the relevant jobs in different workflows and have all the jobs run asynchronously to allow for easier re-run of failed jobs? |
@pierlon Do you mean in the case that some technical issue in the action itself causes the build to stop? I don't think we would expect that case to happen frequently, right? In that case, it might be annoying to have to restart the entire process when the failure was extrinsic to the code change, but it would also indicate to us that the action workflow might not be stable enough and may need attention, which is useful. To me it makes sense to have all the jobs that depend on each other run in sequence, with the entire sequence needing to start over if linting or tests fail. |
@johnwatkins0 Yep that's what I meant. That would also include flaky tests we sometimes encounter, but yes those should be happening quite infrequently from now on. I also prefer having the jobs run in sequence, but just wanted to make it known that the inability to re-run a separate job is currently not a feature on GHA. |
ba4cc07 to
f040121
Compare
This reverts commit 2240e1b
|
|
70a7736 to
8ccb12c
Compare
85f6cb1 to
3f4b81b
Compare
westonruter
left a comment
There was a problem hiding this comment.
Amazing work. You are a GitHub Action whisperer. Just a couple questions:
| ${{ runner.os }}-npm- | ||
|
|
||
| - name: Install Node dependencies | ||
| run: npm ci |
There was a problem hiding this comment.
TIL npm ci: https://docs.npmjs.com/cli/v6/commands/npm-ci
| needs: | ||
| - lint-js |
There was a problem hiding this comment.
Why do JS unit tests depend on linting?
There was a problem hiding this comment.
This can be removed as well.
| needs: | ||
| - lint-js |
There was a problem hiding this comment.
Why do E2E tests depend on linting?
There was a problem hiding this comment.
No definitive reason, this can be removed.
| needs: | ||
| - lint-php | ||
| - static-analysis-php |
There was a problem hiding this comment.
Why does PHPUnit depend on linting and static analysis?
There was a problem hiding this comment.
This can be removed as well.
pierlon
left a comment
There was a problem hiding this comment.
Thanks @westonruter. See 9568f67 for the amendments made.
| needs: | ||
| - lint-js |
There was a problem hiding this comment.
No definitive reason, this can be removed.
| needs: | ||
| - lint-php | ||
| - static-analysis-php |
There was a problem hiding this comment.
This can be removed as well.
| needs: | ||
| - lint-js |
There was a problem hiding this comment.
This can be removed as well.
westonruter
left a comment
There was a problem hiding this comment.
I can't claim to certify all the GH Action code, but it looks good to me!

Summary
Migrates all lint and test jobs from Travis to GHA.
Checklist