Repository navigation
docs: pin the reusable workflows to @latest in examples and guidance - #14
Merged
Merged
Conversation
The workflow examples pinned @v0.1.0, a tag that does not exist, so a copied example failed. Every example now uses @latest, and the guidance says so: - releasing.md makes `latest` the default choice, with the trade-off that a new release can start failing pull requests in enforce mode. A version tag, `stable`, and a full SHA remain supported. - The onboarding guides, READMEs, and both onboarding skills recommend @latest and drop the "a version tag is the default; @latest does not suit an enforced check" wording, so examples and guidance agree. The release procedure in releasing.md keeps v0.1.0 as the placeholder for the version being released. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Edson Tirelli <etirelli@redhat.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
antowaddle
self-requested a review
November 12, 2026 15:47
antowaddle
requested changes
Nov 12, 2026
antowaddle
left a comment
Contributor
There was a problem hiding this comment.
@etirelli one very small clarification, otherwise all good here.
| `stable`, `latest` or a full commit SHA; `$ACT/docs/releasing.md` explains the choices. | ||
| Never pin to a branch. Confirm the release contains `provider-coverage-check.yml` and the | ||
| Pin the reusable workflows to **`@latest`**, unless the user asks for a version tag, | ||
| `stable` or a full commit SHA; `$ACT/docs/releasing.md` explains the choices. |
Contributor
There was a problem hiding this comment.
Stable doesn't seem to exist as a tag. A caller following the docs gets a workflow-resolution failure — the same class of bug as the @v0.1.0 example this PR fixes. Either create/promote stable now, or mark it as available only after the first promotion and remove it from the copyable alternatives.
Contributor
There was a problem hiding this comment.
That will be created after this merges, closing.
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
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
The workflow examples pinned
@v0.1.0, a tag that does not exist (the releases arev1.0.0andv2.0.0), so a copied example failed the pin check. All examples and documentation now pin the reusable workflows to@latest.Changes
@latest.releasing.mdmakeslatestthe default choice. The onboarding guides, the READMEs, and both onboarding skills recommend@latest. A version tag,stable, and a full commit SHA are still listed as supported alternatives; branches remain rejected.@latestdoes not suit one" and "latest: not for gates". These contradicted the new examples, which is the inconsistency flagged on feat: make mode: enforce the default everywhere #13.releasing.mdkeepsv0.1.0as the placeholder for the version being released. The pinning table's version-tag row still shows a version tag as its example.Trade-off for reviewers
With
@latest, every release reaches callers without a change in their repository. In enforce mode, a release that reports new findings can start failing pull requests.releasing.mdnow says this and asks callers to read the release notes. Callers that need nothing to change between upgrades can still pin a version tag.Docs only.
git diff --checkpasses, and no headings or anchors changed.🤖 Generated with Claude Code