[skip changelog] Run relevant workflows on release branch creation #1400
Conversation
This file contains 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
The trunk-based development strategy is employed by this repository. This means that the release branch 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 the Go 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 workflows are 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 website deployment workflow.
per1234
added
type: enhancement
cmaglie
requested changes
Aug 17, 2021
rsora
approved these changes
Aug 17, 2021
Co-authored-by: Cristian Maglie <[email protected]>
cmaglie
approved these changes
Aug 17, 2021
4 tasks
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.
Please check if the PR fulfills these requirements
before creating one)
our contributing guidelines
UPGRADING.mdhas been updated with a migration guide (for breaking changes)What kind of change does this PR introduce?
Infrastructure enhancement
What is the current behavior?
The trunk-based development strategy is employed by this repository. This means that the release branch 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 the Go 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 is 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.
What is the new behavior?
For the reason explained above, 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 workflows are 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 of 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 website deployment workflow (#1028).Does this PR introduce a breaking change, and is titled accordingly?
No breaking change
Other information:
Demo of workflow runs on release branch creation: https://github.com/per1234/arduino-cli/actions?query=branch%3A0.0.x
(note that the workflows were triggered and all jobs ran)
Demo of workflow runs on feature branch creation: https://github.com/per1234/arduino-cli/actions?query=branch%3Asome-feature
(note that the workflows were triggered but all jobs other than
run-determinationwere skipped)