Publish artifacts in workflow #339
Merged
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
We were unable to eat our own dogfood, because the artifacts always had to be committed along with the source code changes in a pull request. This would lead to conflicts when backporting the changes of the pull request to an older release branch. By publishing the artifacts in a separate step of the workflow, we can avoid that the commit with the artifacts is part of the pull request. The artifacts should only be published on pushes to the `main` branch and on branches starting with `release` (which will be the naming scheme for long living release branches in this repo). Packaging the artifacts should always be done, to make sure a pull request's changes don't break packaging the artifacts.
Packaging the artifacts goes really fast (few seconds), and failure may indicate severe errors. It should be run before tests.
It should only be run on pushes to the main branch, on pushes to a release branch, or in pull requests. Contributors, should also not be able to change the CI workflow in their pull request, so it should be run with pull_request_target instead of pull_request.
GHA have a rule that workflows cannot be triggered on events caused by the GITHUB_TOKEN. So, the commit pushed by the CI (publishing the artifacts) would not trigger the release next preview workflow. But, it should, because the next preview tag should point to the commit with the artifacts. To circumvent this, we can checkout the repo in the workflow with a PAT. This PAT will automatically be used when committing and pushing the packaged artifacts. In addition to this commit, the repo now needs to specify a secret: `BACKPORT_ACTION_PAT`. There are no workflows run on pull_request, so this should be safe (secrets are not exposed to pull_request_target), and contributors can't push directly to main or release branches.
korthout
force-pushed
the
312-build-artifacts-workflow
branch
from
42e211d to
8c5df58
Compare
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 changes the
CIworkflow to package and publish the artifacts automatically.By packaging and publishing the artifacts in a workflow, we avoid that they have to be part of a pull request. This allows us to eat our own dogfood and backport pull requests automatically. Previously, pull requests could not be backported because the commit with the artifacts would almost certainly lead to conflicts during cherry-picking.
This pull request also limits when the CI workflow is run. It used to be run both on any
push, and on anypull_requestevent, which is excessive. The workflow actually only needs to be run on pull requests and on any push tomainor release branch (release*). Additionally, contributors should not be able to change the CI that is run on their changes, so it should be run onpull_request_targetinstead ofpull_request.closes #312