ci: adopt consolidated ospo-reusable-workflows release.yaml#211
Merged
Conversation
## What Bump the `release.yaml` reusable workflow pin to v1.0.0 (`592067a6...`), which collapses the previous three-workflow release/release-image/release-discussion pipeline into a single draft-first workflow. Also add a "Breaking Changes" category to release-drafter so PRs labeled `breaking` get their own section in the generated changelog. ## Why The pinned SHA was the pre-consolidation version. Moving to v1.0.0 puts this repo on the supported release flow and aligns it with the pvtr CLI's release workflow. Because pvtr-sdk ships no binaries or container images, only the `create_release` / `publish_release` portion of the consolidated workflow runs; the existing `contents: write` + `pull-requests: read` permissions are still all that's needed. The "Breaking Changes" category matches the upstream release-drafter template (github-community-projects/ospo-reusable-workflows#134); the `breaking` label was already wired up under `version-resolver.major`, so this just surfaces those PRs in their own changelog section. ## Notes - No `goreleaser-config-path` or `image-name` inputs are passed, so the optional `release_goreleaser` and `release_image` jobs in the reusable workflow are skipped at the job-level `if:` and never spin up runners. - Likewise, no `id-token: write` / `attestations: write` permissions are needed here since there are no artifacts to attest. - `create-discussion` is intentionally not enabled; flip on later with the input plus `discussion-repository-id` / `discussion-category-id` secrets if we want auto-announcements. Signed-off-by: jmeridth <jmeridth@gmail.com>
## What Bump the pin on ospo-reusable-workflows/release.yaml from v1.0.0 to v1.0.1 (SHA e92cb6053ace495fe40a5f185988557afcdcecbc). ## Why v1.0.1 lands two fixes from upstream PR github-community-projects/ospo-reusable-workflows#138: 1. release_discussion runs only after publish_release succeeds (no announcing releases that never published). 2. release_goreleaser auto-installs syft when GoReleaser config declares an sboms: block. ## Notes - No caller-side configuration changes are required; v1.0.1 is backward-compatible with v1.0.0 inputs and secrets. Signed-off-by: jmeridth <jmeridth@gmail.com>
eddie-knight
approved these changes
May 11, 2026
jmeridth
added a commit
that referenced
this pull request
May 11, 2026
## What Expand the `release` job's `permissions:` block to grant `id-token: write`, `attestations: write`, `packages: write`, and `discussions: write` in addition to the existing two. The block now covers the union of permissions declared by every job in the called `ospo-reusable-workflows/release.yaml@v1.0.1`. ## Why The merge of #211 left main on the consolidated workflow with only `contents: write` + `pull-requests: read`. The `pull_request_target: closed` Release run that fired on merge failed with `startup_failure`: "The nested job 'release_image' is requesting 'attestations: write, packages: write, id-token: write', but is only allowed ...". GitHub validates each nested job's `permissions:` against the caller's grant at workflow startup, **before** evaluating that job's `if:` — except when the gate folds statically to `false`. The gates on `release_goreleaser` (`inputs.goreleaser-config-path != ''`) and `release_image` (`inputs.image-name != ''`) are string comparisons the validator can't fold, so their perms are checked even though both jobs would have been skipped at runtime here (this repo sets neither input). ## Notes - `release_discussion`'s gate (`inputs.create-discussion && ...`) DOES fold statically (boolean default `false`), so the validator skips it today and `discussions: write` is not technically required. Granting it anyway as a defensive measure in case the upstream rearranges that `if:` later. - This PR carries the `release` label so the now-fixed workflow fires on merge and cuts the release that #211 never produced. Worth confirming the `Release` run on the merge commit completes (create_release + publish_release succeed, release_goreleaser / release_image / release_discussion skipped). Signed-off-by: jmeridth <jmeridth@gmail.com>
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.
What
Bump the
release.yamlreusable workflow pin to v1.0.0 (592067a6...), which collapses the previous three-workflow release/release-image/release-discussion pipeline into a single draft-first workflow. Also add a "Breaking Changes" category to release-drafter so PRs labeledbreakingget their own section in the generated changelog.Why
The pinned SHA was the pre-consolidation version. Moving to v1.0.0 puts this repo on the supported release flow and aligns it with the pvtr CLI's release workflow. Because pvtr-sdk ships no binaries or container images, only the
create_release/publish_releaseportion of the consolidated workflow runs; the existingcontents: write+pull-requests: readpermissions are still all that's needed. The "Breaking Changes" category matches the upstream release-drafter template (github-community-projects/ospo-reusable-workflows#134); thebreakinglabel was already wired up underversion-resolver.major, so this just surfaces those PRs in their own changelog section.Notes
goreleaser-config-pathorimage-nameinputs are passed, so the optionalrelease_goreleaserandrelease_imagejobs in the reusable workflow are skipped at the job-levelif:and never spin up runners.id-token: write/attestations: writepermissions are needed here since there are no artifacts to attest.create-discussionis intentionally not enabled; flip on later with the input plusdiscussion-repository-id/discussion-category-idsecrets if we want auto-announcements.Testing
make test— passes (command,config,internal/...,pluginkit,utilsall green).golangci-lint run ./...— 0 issues.feature/fix/breaking/vuln/releaselabel that firespull_request_target: closed. Watch for: release-drafter creating a draft,create_releasepushing the new tag plus the major-version moving tag, optional jobs (release_goreleaser,release_image,release_discussion) showing as skipped, andpublish_releaseflipping the draft to published.