Attest release archives and publish to the BCR #30
Conversation
kormide
force-pushed
the
provenance
branch
30 times, most recently
from
d070a63 to
7d0688f
Compare
kormide
force-pushed
the
provenance
branch
11 times, most recently
from
8d0c137 to
b06a4d9
Compare
kormide
changed the title
| # in the entry that we will publish later. This entry will be discarded. | ||
| - name: Create entry | ||
| id: create-entry | ||
| uses: bazel-contrib/publish-to-bcr@fa7d3c8ad241c2c0cde639eb2225be55816e9565 |
There was a problem hiding this comment.
TODO: cut a release of the publish to bcr action and point to the version tag
| release_files: | ||
| required: true | ||
| description: | | ||
| Newline-delimited globs of paths to assets to upload for release. | ||
| See https://github.com/softprops/action-gh-release#inputs | ||
| type: string |
There was a problem hiding this comment.
The files to upload to the release are now determined by the release_prep.sh script. The script is supplied with a pre-created directory defined in $ARTIFACTS_DIR to put all artifacts. The script also returns a JSON blob pointing out which artifact(s) are release archives so that we know what to attest.
A couple of alternative solutions are:
- We keep
release_filesbut also addattest_files. - We automatically attest all files under
$ARTIFACTS_DIR, not just the release archives.
There was a problem hiding this comment.
In my opinion, I like giving all of the responsibility for the release to the release_prep.sh script, rather than partially the script and partially some inputs.
| The script will be provided with the following env vars: | ||
|
|
||
| ARTIFACTS_DIR: Path to a pre-created directory where all artifacts to be | ||
| uploaded to the GitHub release must be placed. | ||
|
|
||
| RELEASE_NOTES: Path to a pre-created file where release notes content should | ||
| be written. | ||
|
|
||
| The following arguments are passed to the script: | ||
|
|
||
| <tag_or_ref> The tag supplied as an input to this workflows, or ${{ github.ref_name }}. | ||
|
|
||
| The script must output a JSON blob with paths to release archives. The path can | ||
| be absolute or relative to the ARTIFACTS_DIR. For example: | ||
|
|
||
| { | ||
| "release_archives": ["my-ruleset-vX.Y.Z.tar.gz"] | ||
| } |
There was a problem hiding this comment.
I can understand this new API for release_prep being controversial because it will be a breaking change. I'm open to ideas to try to make it less breaking. The crux is that we need a way to identify release archives for the attestations later on in the workflow.
There was a problem hiding this comment.
I chose JSON output so that it's extensible in the future, for example, maybe we'll have a attest_artifacts property for users who wish to attest more files. GitHub runners have jq installed so parsing is easy.
|
Please review @alexeagle, @loosebazooka, @meteorcloudy, @fweikert. I don't have the permissions to request a review on this repo. |
kormide
force-pushed
the
provenance
branch
3 times, most recently
from
9d454e1 to
8f808b4
Compare
| - name: Checkout BCR | ||
| uses: actions/[email protected] | ||
| with: | ||
| repository: ${{ github.event.inputs.registry }} | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
| path: bazel-central-registry |
There was a problem hiding this comment.
TODO: experiment with sparse checkouts
| # Create an initial entry so that we can attest the generated source.json and MODULE.bazel | ||
| # files. These are needed to solve a chicken and egg problem where the attestations are referenced | ||
| # by attestations.template.json entry file, which is included in the entry published later on. | ||
| # This entry will be discarded. | ||
| - name: Create entry | ||
| id: create-entry | ||
| uses: bazel-contrib/publish-to-bcr@fa7d3c8ad241c2c0cde639eb2225be55816e9565 |
There was a problem hiding this comment.
I can see an argument for making a second action in publish-to-bcr that only outputs the attestations, since that's all we're creating the entry here for. But it's an internal implementation detail for now.
|
I think we need a nice |
| - name: Create Pull Request | ||
| id: create-pull-request | ||
| uses: peter-evans/create-pull-request@v7 |
There was a problem hiding this comment.
TODO: verify that an existing PR can be updated on a second publish
| # Publish to BCR can run substitutions on an attestations.template.json file. Add a default | ||
| # template here and don't require it to exist in the module repo's .bcr templates folder. | ||
| - name: Create attestations template | ||
| working-directory: this/.bcr |
There was a problem hiding this comment.
Although this is a long script and it's tempting to put it in a file, it's surprisingly difficult to try to reference a file in a reusable workflow. This is because it runs in the context of the calling workflow. GitHub does not provide any path with a checkout of the reusable workflow repository, and it does not provide the ref used. The only way to properly reference a file is to pass in the reusable workflow ref/tag as an input, then manually check it out at that ref and retrieve the file.
This updates the reusable release workflow to publish attestations and adds a new publish workflow for mirroring a release to the Bazel Central Registry.
The publish workflow can be set up to run automatically after a successful release run (configured in the calling repo), or manually. The manual option allows the publish to re-run from main, for the release tag, in case there was an error, for example, incorrect template files in .bcr.
I made some breaking changes to the
release_prep.shscript inputs and outputs due to the need to identify the release archive for attesting. A release can upload many different artifacts and there wasn't surefire way to single out the archive. See an example release_prep.sh in one of my test fixtures.