Skip to content

Refactor: Call the shared release workflow - #18

Open
ModeSevenIndustrialSolutions wants to merge 1 commit into
lfreleng-actions:mainfrom
modeseven-lfreleng-actions:refactor/thin-release-caller
Open

Refactor: Call the shared release workflow#18
ModeSevenIndustrialSolutions wants to merge 1 commit into
lfreleng-actions:mainfrom
modeseven-lfreleng-actions:refactor/thin-release-caller

Conversation

@ModeSevenIndustrialSolutions

@ModeSevenIndustrialSolutions ModeSevenIndustrialSolutions commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Why

tag-push.yaml here duplicated a validate-then-promote job graph that 96
repositories each carried their own copy of. This replaces it with a thin
caller delegating to the
release reusable in generic-workflows,
pinned to
v0.0.4
(007258a132e4ba5358a20a5c0a902fa04de3a045).

Renamed to release.yaml

The name describes the outcome rather than the trigger, and sits beside the
release-drafter.yaml that creates the draft this workflow publishes.

Behaviour changes to be aware of

The caller passes no inputs, so it adopts the reusable's defaults in full —
the release-gating policy and the runner-hardening defaults.

1. Gating. Repositories that enforced only the versioning scheme, signature
and pre-release checks gain four gates:

Gate Effect
enforce_increment Tag must exceed the highest existing comparable tag
require_branch Tag commit must be reachable from the default branch
require_recent Tag object must be under three minutes old
require_latest Tag must point at the current tip of the default branch

Tags that are stale, raised off the default branch, or not at its tip now fail
rather than produce a faulty immutable release. This is the intended
organisation-wide default; it had simply not been rolled out everywhere. Eight
repositories already carried all eight gates — for those, nothing tightens.

2. Runner hardening. 14 repositories still ran harden-runner in audit
mode and move to block. Every one of those 14 also lacks the
harden-runner-block-action allow-list loader, while all 82 on block have
it — they are stragglers on an older template, not deliberate opt-outs. After
this conversion all 96 run an identical workflow, so the egress profile is
uniform and already proven by the 82 running these exact steps under block.

3. Concurrency. Six repositories used a global group
(${{ github.workflow }}), serialising all releases; they move to the
estate-standard per-tag group (${{ github.workflow }}-${{ github.ref }}).
Distinct tags are independent work, and the reusable serialises itself per-tag
as well.

mark_latest defaults to true, matching the latest: true the old promote
step passed.

Tag deletions

Deleting a tag also fires this push event. The reusable already guards its
own jobs with if: ${{ !github.event.deleted }}, but the caller carries the
guard too so that — exactly as before — no run starts at all.

Validation

The reusable and this caller pattern were exercised end-to-end in
test-release-process,
the repository built to test the organisation's release tooling: a signed tag
push validated against the full gate set and promoted its draft release. This
generated caller passes actionlint and yamllint against this repository's
own configuration.

Review note

The caller keeps its own concurrency block. That is safe: the reusable
serialises under generic-workflows-release-${{ github.ref }}, a literal
prefix that cannot collide with the caller's own group.

timeout-minutes is deliberately absent — GitHub does not permit it on a job
that calls a reusable workflow (actionlint rejects it). The reusable sets its
own timeouts of 2, 5 and 5 minutes on its three jobs.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Ready to approve

The workflow refactor is straightforward and aligned with the stated goal; only a small naming/description mismatch remains.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

Refactors the repository’s tag-push release automation to delegate to the shared lfreleng-actions/generic-workflows reusable release workflow (pinned to v0.0.3), reducing duplicated workflow logic and aligning this repo with the organization-wide release gating policy.

Changes:

  • Replaced the in-repo “validate then promote draft release” job graph with a reusable workflow call.
  • Renamed the workflow file from tag-push.yaml to release.yaml while preserving concurrency serialization behavior.
  • Adopted the organization’s default release gating policy by intentionally providing no with: inputs to the reusable.
File summaries
File Description
.github/workflows/tag-push.yaml Removes the previously inlined validate/promote job graph (duplication).
.github/workflows/release.yaml Adds a thin reusable-workflow caller pinned to generic-workflows v0.0.3, keeping local concurrency settings.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 1
  • Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

Comment thread .github/workflows/release.yaml
The tag-push.yaml here duplicated a validate-then-promote job graph that
almost a hundred repositories each carried their own copy of. Replace it
with a caller that delegates to the release reusable in
generic-workflows, pinned to v0.0.3.

Rename the file to release.yaml. The name describes the outcome rather
than the trigger, and sits beside the release-drafter.yaml that creates
the draft this workflow publishes.

The caller passes no inputs, so it adopts the organisation's default
gating policy in full. Where a repository enforced only the versioning
scheme, signature and pre-release checks, that adds four gates:
enforce_increment, require_branch (default branch), require_recent
(three minutes) and require_latest. Tags that are stale, raised off the
default branch, or not at its tip now fail instead of producing a faulty
immutable release.

Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Matthew Watkins <mwatkins@linuxfoundation.org>
Copilot AI review requested due to automatic review settings August 3, 2026 22:13

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Not ready to approve

The pinned generic-workflows ref in the new caller workflow does not match the version/SHA stated in the PR description, which needs to be reconciled to ensure reviewers can validate the exact adopted workflow version.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (1)

.github/workflows/release.yaml:45

  • The workflow call is pinned to generic-workflows v0.0.4 (SHA 007258…), but the PR description states it should be pinned to v0.0.3 (b80a5a8…). Please align the pinned ref (and the inline version comment) with the PR description so reviewers can verify exactly what version is being adopted.
    uses: lfreleng-actions/generic-workflows/.github/workflows/release.yaml@007258a132e4ba5358a20a5c0a902fa04de3a045  # v0.0.4
  • Files reviewed: 2/2 changed files
  • Comments generated: 0 new
  • Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

refactor Refactoring of code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants