Tags: github-community-projects/ospo-reusable-workflows
Tags
fix(ci): order discussion after publish + auto-install syft for SBOMs (… …#138) * fix(release): create discussion only after publish succeeds ## What Move the release_discussion job to run after publish_release succeeds instead of in parallel with the build jobs. The publish_release job no longer depends on release_discussion. ## Why Previously, the discussion was created before the draft release was published. If publish_release failed (or publish was disabled), subscribers were still notified about a release that did not actually exist as a published artifact. Gating discussion creation on a successful publish ensures announcements only fire for releases users can actually consume. ## Notes - The redundant inputs.publish check on release_discussion was removed; gating now flows through publish_release, which itself requires inputs.publish. - Total wall-clock time for a full release increases slightly because the discussion job no longer runs in parallel with goreleaser/image builds — it now runs after publish. - Behavior when create-discussion is false or discussion secrets are unset is unchanged. Signed-off-by: jmeridth <jmeridth@gmail.com> * feat(release): auto-install syft when GoReleaser config uses sboms ## What In `release_goreleaser`, detect a `sboms:` block in the user's GoReleaser config (via yq, already installed for the existing release.disable check) and conditionally install `syft` before running GoReleaser. Generated `dist/*.spdx.json` files are now included in both the draft-release upload and the build provenance attestation subject paths. ## Why GoReleaser configs that declare `sboms.cmd: syft` previously failed inside the reusable workflow with `exec: "syft": executable file not found in $PATH`, because the `release_goreleaser` job did not install syft. Consumers had to either drop SBOM generation from their GoReleaser config or maintain a separate workflow job to install syft, which defeats the purpose of consolidating into this reusable workflow. ## Notes - The new `Install Syft for SBOM generation` step only runs when the config has a `sboms:` key, so consumers without SBOMs see no behavior change. - syft is pinned via `anchore/sbom-action/download-syft@e22c389904149dbc22b58101806040fa8d37a610 # v0.24.0`. If a newer release is preferred I am happy to bump it before merge. - SBOM `.spdx.json` files are included in `attest-build-provenance` subject paths so attestation covers the same set of artifacts the user sees in the published release. - The `Detect SBOM generation` step is intentionally placed after the existing `Validate GoReleaser config has release disabled` step, so the validate-first behavior is preserved. Signed-off-by: jmeridth <jmeridth@gmail.com> * ci: allow github and release scopes in PR titles ## What Add `github` and `release` to the allowed PR-title scope list in test-pr-title.yaml. ## Why PRs that touch GitHub-platform-specific config (workflows, issue templates, labels) and the release pipeline previously had to use a less specific scope or no scope at all, since `fix(release): ...` and `chore(github): ...` would fail scope validation. This PR's own title uses `release` as its scope. ## Notes - `requireScope` remains `false`, so scope is still optional; this only widens the allowed set when one is used. Signed-off-by: jmeridth <jmeridth@gmail.com> --------- Signed-off-by: jmeridth <jmeridth@gmail.com>
fix(ci): order discussion after publish + auto-install syft for SBOMs (… …#138) * fix(release): create discussion only after publish succeeds ## What Move the release_discussion job to run after publish_release succeeds instead of in parallel with the build jobs. The publish_release job no longer depends on release_discussion. ## Why Previously, the discussion was created before the draft release was published. If publish_release failed (or publish was disabled), subscribers were still notified about a release that did not actually exist as a published artifact. Gating discussion creation on a successful publish ensures announcements only fire for releases users can actually consume. ## Notes - The redundant inputs.publish check on release_discussion was removed; gating now flows through publish_release, which itself requires inputs.publish. - Total wall-clock time for a full release increases slightly because the discussion job no longer runs in parallel with goreleaser/image builds — it now runs after publish. - Behavior when create-discussion is false or discussion secrets are unset is unchanged. Signed-off-by: jmeridth <jmeridth@gmail.com> * feat(release): auto-install syft when GoReleaser config uses sboms ## What In `release_goreleaser`, detect a `sboms:` block in the user's GoReleaser config (via yq, already installed for the existing release.disable check) and conditionally install `syft` before running GoReleaser. Generated `dist/*.spdx.json` files are now included in both the draft-release upload and the build provenance attestation subject paths. ## Why GoReleaser configs that declare `sboms.cmd: syft` previously failed inside the reusable workflow with `exec: "syft": executable file not found in $PATH`, because the `release_goreleaser` job did not install syft. Consumers had to either drop SBOM generation from their GoReleaser config or maintain a separate workflow job to install syft, which defeats the purpose of consolidating into this reusable workflow. ## Notes - The new `Install Syft for SBOM generation` step only runs when the config has a `sboms:` key, so consumers without SBOMs see no behavior change. - syft is pinned via `anchore/sbom-action/download-syft@e22c389904149dbc22b58101806040fa8d37a610 # v0.24.0`. If a newer release is preferred I am happy to bump it before merge. - SBOM `.spdx.json` files are included in `attest-build-provenance` subject paths so attestation covers the same set of artifacts the user sees in the published release. - The `Detect SBOM generation` step is intentionally placed after the existing `Validate GoReleaser config has release disabled` step, so the validate-first behavior is preserved. Signed-off-by: jmeridth <jmeridth@gmail.com> * ci: allow github and release scopes in PR titles ## What Add `github` and `release` to the allowed PR-title scope list in test-pr-title.yaml. ## Why PRs that touch GitHub-platform-specific config (workflows, issue templates, labels) and the release pipeline previously had to use a less specific scope or no scope at all, since `fix(release): ...` and `chore(github): ...` would fail scope validation. This PR's own title uses `release` as its scope. ## Notes - `requireScope` remains `false`, so scope is still optional; this only widens the allowed set when one is used. Signed-off-by: jmeridth <jmeridth@gmail.com> --------- Signed-off-by: jmeridth <jmeridth@gmail.com>
refactor: consolidate release pipeline with draft-first pattern (#124) ## What Collapse the three separate release workflows (release.yaml, release-image.yaml, release-discussion.yaml) into a single release.yaml reusable workflow using a draft-first pattern: create draft, push tags, build artifacts (optional GoReleaser, optional Docker image), create discussion, then publish. Preserve the legacy release-image.yaml and release-discussion.yaml as stubs that fail with migration instructions. ## Why The three workflows were always chained and shared data flow, so callers had to wire up three workflow calls and reason about ordering themselves. The draft-first sequence supports repositories with immutable releases enabled by ensuring every artifact and attestation lands before the release becomes visible. ## Notes - Breaking: callers of release-image.yaml / release-discussion.yaml hit a deprecation error with migration instructions. - Breaking: update-major-tag input removed; the major tag is always pushed in create_release. - publish defaults to true and is backwards compatible, but release-drafter always creates a draft first and publish_release handles the final flip. - publish_release uses always() with per-job result checks so it runs when optional jobs are skipped but blocks on any failure. - GoReleaser config is validated via yq to require release.disable: true, avoiding conflict with the draft. - Attestation steps probe repo visibility via the GitHub API and warn on private repos instead of failing cryptically. - release_discussion always spins up a runner when a tag is created and skips at the step level if secrets are missing (job-level if: cannot read secrets). - publish_release uses -F draft=false (capital F) to send a boolean rather than a string. Signed-off-by: jmeridth <jmeridth@gmail.com>
fix: revert autolabeler to release-drafter v6.4.0 (#115) ## What Reverted the auto-labeler workflow from the release-drafter v7 autolabeler sub-action back to the v6.4.0 main action with disable-releaser: true. ## Why The v7 autolabeler sub-action hardcodes a strict check for the pull_request event and rejects pull_request_target. Since this reusable workflow is called from a pull_request_target trigger (required for labeling fork PRs with write permissions), the autolabeler fails on every fork PR. ## Notes - The v6 action uses GITHUB_TOKEN via env rather than the token input - release-drafter v7 is still used in the release workflow; only the autolabeler is pinned to v6 - Consider opening an upstream issue on release-drafter to support pull_request_target in the v7 autolabeler Signed-off-by: jmeridth <jmeridth@gmail.com>
chore(deps): bump release-drafter/release-drafter from 6.4.0 to 7.0.0 (… …#109) * chore(deps): bump release-drafter/release-drafter from 6.4.0 to 7.0.0 Bumps [release-drafter/release-drafter](https://github.com/release-drafter/release-drafter) from 6.4.0 to 7.0.0. - [Release notes](https://github.com/release-drafter/release-drafter/releases) - [Commits](release-drafter/release-drafter@6a93d82...3a7fb5c) --- updated-dependencies: - dependency-name: release-drafter/release-drafter dependency-version: 7.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> * ci: migrate release-drafter usage to v7 breaking changes ## What Migrate auto-labeler workflow to the new dedicated autolabeler sub-action, switch both workflows from `GITHUB_TOKEN` env var to the `token` input, and convert the singular `label:` config key to `labels:` array syntax in the release-drafter config. ## Why Release-drafter v7 splits the autolabeler into its own action entrypoint, removes the `disable-releaser` input, and replaces the `GITHUB_TOKEN` env var with a `token` input. The singular `label:` key lost `array.single()` support in the Joi-to-Zod validation migration, making the array form the safer choice. ## Notes - The v7.0.0 tag resolves to the same commit SHA (`3a7fb5c8`) as the previously pinned version — the breaking changes are in action entrypoint routing and input validation, not the underlying commit - Callers of these reusable workflows need no changes since the `workflow_call` interface (inputs/secrets) is unchanged Signed-off-by: jmeridth <jmeridth@gmail.com> --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: jmeridth <jmeridth@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: jmeridth <jmeridth@gmail.com>
PreviousNext