Run relevant workflows on release branch creation #221
Conversation
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
It is often necessary to escape the newline for continuation when breaking shell commands into multiple lines for readability. However, if a line break occurs in a shell command in an unterminated command, the continuation is implicit. The escaping in these shell commands was unnecessary and only made them a bit more cryptic, since the brackets already clearly indicate the structure
This is a follow up to the original campaign to provide release branch coverage. The trigger on release branch creation system was added only to the most critical workflows at that time. Since then, the system has proven itself through several releases. A new critical "Check Go Dependencies" workflow was added which was missing the trigger due to being created prior to the campaign, but then staged until after it. While updating that workflow, I took the time to review all the remaining workflows for ones that might provide valuable information for project evaluation prior to release. I identified several additional workflows that, while not critical, still might reveal problems with the project at its state in the release branch. So I also added it to those. --- The trunk-based development strategy is used by some tooling projects (e.g., Arduino CLI). Their release branches may contain a subset of the history of the default branch. The status of the GitHub Actions workflows should be evaluated before making a release. However, this is not so simple as checking the status of the commit at the tip of the release branch. The reason is that, for the sake of efficiency, the workflows are configured to run only when the processes are relevant to the trigger event (e.g., no need to run unit tests for a change to the readme). In the case of the default branch, you can simply set the workflow runs filter to that branch and then check the result of the latest run of each workflow of interest. However, that was not possible to do with the release branch since it might be that the workflow was never run in that branch. The status of the latest run of the workflow in the default branch might not match the status for the release branch if the release branch does not contain the full history. For this reason, it will be helpful to trigger all relevant workflows on the creation of a release branch. This will ensure that each of those workflows will always have at least one run in the release branch. Subsequent commits pushed to the branch can run based on their usual trigger filters and the status of the latest run of each workflow in the branch will provide an accurate indication of the state of that branch. Branches are created for purposes other than releases, most notably feature branches to stage work for a pull request. Because the collection of workflows in a Tooling project are often very comprehensive, it would not be convenient or efficient to run them on the creation of every feature branch. Unfortunately, GitHub Actions does not support filters on the `create` event of branch creation like it does for the `push` and `pull_request` events. There is support for a `branches` filter of the `push` event, but that filter is an AND to the `paths` filter and this application requires an OR. For this reason, the workflows must be triggered by the creation of any branch. The unwanted job runs are prevented by adding a `run-determination` job with the branch filter handled by Bash commands. The other jobs of the workflow use this `run-determination` job as a dependency, only running when it indicates they should via a job output. Because this minimal `run-determination` job runs very quickly, it is roughly equivalent to the workflow having been skipped entirely for non-release branch creations. This approach has been in use for some time already in the versioned "Deploy Website" workflows.
per1234
added
type: enhancement
umbynos
approved these changes
Apr 20, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a follow up to the original campaign to provide release branch coverage (#148). The trigger on release branch creation
system was added only to the most critical workflows at that time. Since then, the system has proven itself through
several releases.
A new critical "Check Go Dependencies" workflow was added which was missing the trigger due to being created prior to
the campaign, but then staged until after it. While updating that workflow, I took the time to review all the remaining
workflows for ones that might provide valuable information for project evaluation prior to release. I identified several
additional workflows that, while not critical, still might reveal problems with the project at its state in the release
branch. So I also added it to those.
The trunk-based development strategy is used by some tooling projects (e.g., Arduino CLI). Their release branches may contain a subset of the history of the default branch.
The status of the GitHub Actions workflows should be evaluated before making a release. However, this is not so simple as checking the status of the commit at the tip of the release branch. The reason is that, for the sake of efficiency, the workflows are configured to run only when the processes are relevant to the trigger event (e.g., no need to run unit tests for a change to the readme).
In the case of the default branch, you can simply set the workflow runs filter to that branch (example) and then check the result of the latest run of each workflow of interest. However, that was not possible to do with the release branch since it might be that the workflow was never run in that branch. The status of the latest run of the workflow in the default branch might not match the status for the release branch if the release branch does not contain the full history.
For this reason, it will be helpful to trigger all relevant workflows on the creation of a release branch. This will ensure that each of those workflows will always have at least one run in the release branch. Subsequent commits pushed to the branch can run based on their usual trigger filters and the status of the latest run of each workflow in the branch will provide an accurate indication of the state of that branch.
Branches are created for purposes other than releases, most notably feature branches to stage work for a pull request. Because the collection of workflows in a Tooling project are often very comprehensive, it would not be convenient or efficient to run them on the creation of every feature branch.
Unfortunately, GitHub Actions does not support filters on the
createevent generated by branch creation like it does for thepushandpull_requestevents. There is support for abranchesfilter of thepushevent, but that filter is an "AND" to thepathsfilter and this application requires an "OR". For this reason, the workflows must be triggered by the creation of any branch. The unwanted job runs are prevented by adding arun-determinationjob with the branch filter handled by Bash commands. The other jobs of the workflow use thisrun-determinationjob as a dependency, only running when it indicates they should via a job output. Because this minimalrun-determinationjob runs very quickly, it is roughly equivalent to the workflow having been skipped entirely for non-release branch creations. This approach has been in use for some time already in the versioned "Deploy Website" workflows.