The "Publish" GitHub Actions workflow in Cratis/Components is failing (https://github.com/Cratis/Components/actions/r...

[cratis-direct]

The "Publish" GitHub Actions workflow in Cratis/Components is failing (https://github.com/Cratis/Components/actions/runs/33334724595). Diagnosis: The Publish workflow failed because the merged pull request is missing a semantic versioning label (major, minor, or patch). The workflow's release job completed successfully but determined no release should be published due to the 'no-label' reason, causing the verify-published job to fail as intended.

Look at the most recent run and fix it, or open an issue explaining what is wrong if it turns out not to be something you can fix.

The full build log can be read with gh run view 33334724595 --log-failed --repo Cratis/Components.

Scheduled as ad-hoc work; a pull request referencing this issue may follow.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[cratis-direct]

Findings

Diagnosis update: the merged pull request (#222) was not actually missing a semantic-versioning label - it carried no-release, which is the correct, policy-accepted fourth release-intent label for a CI/tooling-only change (per this repo's own pull-requests.md, enforced at PR time by the org-wide Cratis/Workflows verify-release-intent.yml gate, which #222 passed).

The real problem is upstream: Cratis/release-action (pinned in .github/workflows/publish.yml) has no concept of a no-release label at all. It only checks major/minor/patch, and when none match it always reports reason: no-label - indistinguishable from a pull request that genuinely forgot to label itself. Components' verify-published job then does exactly what it is designed to do and fails on that reason.

This is not something to work around inside Components: the repo's own verify-semver-label.yml explicitly warns against reintroducing per-repository copies of release-intent logic (the reason it was centralized into Cratis/Workflows after the 2026-08-25 incident), and duplicating no-release detection into publish.yml would be the same mistake in a different spot.

Fix

Opened and merged the root-cause fix upstream: Cratis/release-action#184 adds a configurable no-release-labels input (default no-release) and a dedicated no-release release reason, excluded from the reasons a workflow should fail on. Verified locally with yarn ci (typecheck, lint, 133 specs with coverage, build) - all green - and confirmed CI green on the PR itself before it was ready to merge.

Follow-up

No code change is needed in Components for this. Once Cratis/release-action cuts a release including that fix, Components' .github/workflows/publish.yml can bump its pinned action SHA (currently bdaded342eb31b52b48dca0611f0214794f8c655) to pick it up, and future no-release-labelled merges will report reason: no-release and go green through verify-published as designed.

[woksin]

The cited no-label run is obsolete and Components publishing recovered. Later Publish runs completed successfully, including https://github.com/Cratis/Components/actions/runs/33492314360.