Automatically release and promote workflows after merges to main #113

New issue

Open

opened 2026-10-16 20:32:56 -05:00 by kiyi · 0 comments

kiyi commented

2026-10-16 20:32:56 -05:00

Member

Expected flow:

A merge/push to protected main starts the automatic release flow and determines the next semantic version and release notes. Verify tool compatibility with the installed Forgejo before selecting an implementation. Normal operation must not require a separate manual release-PR merge or version entry.
Run or wait for the existing required checks for the exact merged source commit, including Library checks / tests and repository security. Pending, failed, cancelled or stale results must not authorize publication. Preserve existing workflow, job and required status-check names.
Publish that exact checked commit as an immutable vX.Y.Z release through the existing release implementation.
Automatically compile and validate its channel snapshot, wait for the existing canary/compatibility gates, and promote that release to stable-v1 using the existing atomic tag/audit procedure. Consumers already using stable-v1 should pick it up without caller version edits.
Retain links and evidence connecting the source commit, successful checks, numbered release, channel snapshot, canary and promotion. Failures must identify the blocked stage and leave the previous stable selection available.

Implementation requirements:

Reuse the maintained publisher/channel code in Homelab/workflows. Introduce an explicitly reviewed automatic-main execution/authentication path: current manual-dispatch-only guards and Authorized Integrations grants need compatible, narrowly scoped automation support rather than being disabled. This issue requests preparation and review; it does not change live access.
Serialize releases/promotions and make retries idempotent. Duplicate events must not create duplicate releases, overwrite immutable tags, or let an older run move stable-v1 backward after a newer promotion. Prevent automation-generated version/changelog commits from creating release loops.
Keep the existing manual recovery/rollback path available and document normal automatic operation and failure recovery. This automates the workflow-library release/channel lifecycle; application deployments keep their owning approval gates.

Acceptance:

An ordinary reviewed merge to main automatically publishes a new semantic release after its exact-commit required checks pass.
The same flow automatically promotes that release to stable-v1 after channel validation/canary success, with no routine manual publish/promote dispatch.
Failed library/security checks prevent publication; failed channel validation prevents promotion.
Tests cover duplicate events, transient retry, concurrent merges, stale checks, release-loop prevention and failed promotion recovery.
Existing required check names, immutable releases, promotion audit evidence and rollback behavior are preserved.
The runbook and hosted acceptance evidence demonstrate the complete automatic sequence.

Related: #93 (shared release channel), #112 (CI retries can adopt promoted workflow fixes).

Merging reviewed changes to main should be enough to deliver the workflow library to stable-v1. The owner currently has to publish a numbered release manually, wait for checks, and dispatch channel promotion after every update. Automate that sequence using Release Please or a Forgejo-compatible equivalent. Expected flow: 1. A merge/push to protected main starts the automatic release flow and determines the next semantic version and release notes. Verify tool compatibility with the installed Forgejo before selecting an implementation. Normal operation must not require a separate manual release-PR merge or version entry. 2. Run or wait for the existing required checks for the exact merged source commit, including `Library checks / tests` and repository security. Pending, failed, cancelled or stale results must not authorize publication. Preserve existing workflow, job and required status-check names. 3. Publish that exact checked commit as an immutable `vX.Y.Z` release through the existing release implementation. 4. Automatically compile and validate its channel snapshot, wait for the existing canary/compatibility gates, and promote that release to `stable-v1` using the existing atomic tag/audit procedure. Consumers already using stable-v1 should pick it up without caller version edits. 5. Retain links and evidence connecting the source commit, successful checks, numbered release, channel snapshot, canary and promotion. Failures must identify the blocked stage and leave the previous stable selection available. Implementation requirements: - Reuse the maintained publisher/channel code in Homelab/workflows. Introduce an explicitly reviewed automatic-main execution/authentication path: current manual-dispatch-only guards and Authorized Integrations grants need compatible, narrowly scoped automation support rather than being disabled. This issue requests preparation and review; it does not change live access. - Serialize releases/promotions and make retries idempotent. Duplicate events must not create duplicate releases, overwrite immutable tags, or let an older run move stable-v1 backward after a newer promotion. Prevent automation-generated version/changelog commits from creating release loops. - Keep the existing manual recovery/rollback path available and document normal automatic operation and failure recovery. This automates the workflow-library release/channel lifecycle; application deployments keep their owning approval gates. Acceptance: - [ ] An ordinary reviewed merge to main automatically publishes a new semantic release after its exact-commit required checks pass. - [ ] The same flow automatically promotes that release to stable-v1 after channel validation/canary success, with no routine manual publish/promote dispatch. - [ ] Failed library/security checks prevent publication; failed channel validation prevents promotion. - [ ] Tests cover duplicate events, transient retry, concurrent merges, stale checks, release-loop prevention and failed promotion recovery. - [ ] Existing required check names, immutable releases, promotion audit evidence and rollback behavior are preserved. - [ ] The runbook and hosted acceptance evidence demonstrate the complete automatic sequence. Related: #93 (shared release channel), #112 (CI retries can adopt promoted workflow fixes).

kiyi added this to the Homelab Roadmap project

2026-10-16 20:33:20 -05:00

kiyi added the

ci-cd

label

2026-10-16 20:33:30 -05:00