Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: github-community-projects/contributors
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v2.0.10
Choose a base ref
...
head repository: github-community-projects/contributors
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: v2.0.11
Choose a head ref
  • 1 commit
  • 2 files changed
  • 1 contributor

Commits on May 10, 2026

  1. ci: adopt consolidated ospo-reusable-workflows release.yaml (#468) 

    * ci: adopt consolidated ospo-reusable-workflows release.yaml

## What

Collapse the three legacy `release` / `release_image` / `release_discussion` job calls into a single call to the consolidated `release.yaml` reusable workflow at v1.0.0 (`592067a6...`). Pass `image-name`, `create-attestation: true`, and `create-discussion: true` so the workflow handles GitHub release, container image build/push to GHCR, build provenance attestation, and announcement discussion in one draft-first pipeline. Also add a "💥 Breaking Changes" category to `release-drafter.yml`.

## Why

The legacy three-workflow setup forced callers to wire up the same job chain by hand in every repo and made it easy for permissions, secrets, and ordering to drift. v1.0.0 of ospo-reusable-workflows owns the chain internally and exposes a single entry point. The "Breaking Changes" category matches the upstream release-drafter template (github-community-projects/ospo-reusable-workflows#134); the `breaking` label already maps to a major bump in `version-resolver`, so this just surfaces those PRs in their own changelog section.

## Notes

- The job-level permission block now lists the union of what the called workflow's internal jobs need (contents/pull-requests/packages/id-token/attestations/discussions). A `uses:` caller can only grant — never expand — what the reusable workflow requests, so missing perms here silently disable features instead of erroring.
- `image-registry` and `image-registry-username` moved from `secrets:` to inputs in v1.0.0 (defaults to `ghcr.io` and `github.actor`). Both defaults match the previous explicit values, so they're omitted.
- `image-registry-password` stays a secret and continues to use `GITHUB_TOKEN` for ghcr.io pushes.
- The reusable workflow's `release_discussion` job validates the discussion secrets at the step level and skips with a notice if they're unset, so the workflow keeps working even if the discussion secrets aren't configured.

Signed-off-by: jmeridth <jmeridth@gmail.com>

* style: align release.yml comments to prettier formatting

Single-space before `#` so prettier (via super-linter) accepts the workflow file. No behavior change.

Signed-off-by: jmeridth <jmeridth@gmail.com>

---------

Signed-off-by: jmeridth <jmeridth@gmail.com>
    @jmeridth
    jmeridth authored May 10, 2026
    Configuration menu
    Copy the full SHA
    b859081 View commit details
    Browse the repository at this point in the history
Loading