Bind auto-publish jobs to actual spec updates#825
Merged
Conversation
Each time an update was made to any of the specs in the repository, all 16 specs got re-published because the auto-publish workflow did not know what was changed. This took time for no good reason. The [`paths` filter](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) allows to run a workflow conditionally. Unfortunately, it only applies at the workflow level (and cannot be set at the job level within a workflow in particular). This adds an auto-publish workflow template and a companion script to generate auto-publish workflows for each and every spec in the repository, that only run when needed, meaning only when the spec source did change. The script only needs to run once in a while when new specs get added or when the workflows need to change. The new auto-publish workflows created by the script replace the previous `auto-publish.yml` workflow. Note: The `auto-publish.yml` workflow still had a `BUILD_FAIL_ON: nothing` property, which was meant to be a temporary measure and should no longer be needed: adfb63c This update switches back to `BUILD_FAIL_ON: warning`. This is the same approach as that done for w3c/encrypted-media: w3c/encrypted-media@cefbd73
Djuffin
approved these changes
Aug 19, 2024
Member
Author
|
Merging. The setting seems to work for w3c/encrypted-media in particular. I'm around to fix issues if that ends up not working as expected. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Each time an update was made to any of the specs in the repository, all 16 specs got re-published because the auto-publish workflow did not know what was changed. This took time for no good reason.
The
pathsfilter allows to run a workflow conditionally. Unfortunately, it only applies at the workflow level (and cannot be set at the job level within a workflow in particular). This means the only direct way to avoid running a job is to create a workflow per spec.This adds an auto-publish workflow template and a companion script to generate auto-publish workflows for each and every spec in the repository, that only run when needed, meaning only when the spec source did change. The script only needs to run once in a while when new specs get added or when the workflows need to change.
The new auto-publish workflows created by the script replace the previous
auto-publish.ymlworkflow.Note: The
auto-publish.ymlworkflow still had aBUILD_FAIL_ON: nothingproperty, which was meant to be a temporary measure and should no longer be needed (see adfb63c). This update switches back toBUILD_FAIL_ON: warning.This is the same approach as that done for w3c/encrypted-media: w3c/encrypted-media@cefbd73