feat: define releases channel operations
This commit is contained in:
@@ -1,50 +1,205 @@
|
||||
---
|
||||
name: corp-v1-channel-releases
|
||||
description: "Use as the central reference when defining or adopting project-scoped operating guidance for a Corp v1 releases channel. This repository is initial setup only; detailed purpose and procedures remain pending steering walkthrough."
|
||||
version: 0.1.0
|
||||
description: "Use when operating or synchronizing a Corp v1 project's releases channel. Assesses release readiness and, only when the team requests a release, updates the Gondor v1 template source, renders it, pushes a separate branch to Gondor v1, and opens a pull request requiring team approval before deployment."
|
||||
version: 1.0.0
|
||||
author: Hermes Agent
|
||||
license: MIT
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [corp-v1, discord, channel, releases, reference]
|
||||
related_skills: [corp-v1-steering-committee, home-v1-discord]
|
||||
tags: [corp-v1, discord, channel, releases, gondor-v1, gitops, pull-request]
|
||||
related_skills: [corp-v1-steering-committee, home-v1-discord, gondor-v1-nodes]
|
||||
---
|
||||
|
||||
# Corp v1 Releases Channel Reference
|
||||
# Corp v1 Releases Channel
|
||||
|
||||
## Overview
|
||||
|
||||
This is the central source skill for the `releases` channel created for each Corp v1 project.
|
||||
This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels for release implications, but it starts release execution only after an explicit team request.
|
||||
|
||||
**Current status: setup only.** Its detailed purpose, responsibilities, procedures, artifacts, authority boundaries, and verification rules are intentionally not defined yet. They will be agreed in a separate walkthrough before promotion beyond version `0.1.0`.
|
||||
The release workflow updates the project-specific portion of:
|
||||
|
||||
```text
|
||||
https://gitea.lego-cloud.eu/home-v1/gondor-v1-tmpl
|
||||
```
|
||||
|
||||
It then runs the repository's authoritative rendering process and pushes the rendered change to a separate branch in:
|
||||
|
||||
```text
|
||||
https://gitea.lego-cloud.eu/home-v1/gondor-v1
|
||||
```
|
||||
|
||||
The skill opens a pull request for team review. Deployment must not proceed until the team approves the pull request and all required gates pass.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this source when walking through the future `releases` channel skill, creating a reviewed project copy after finalization, or comparing an adopted copy with its source.
|
||||
Use this skill when:
|
||||
|
||||
Do not use this version as complete operating guidance for a live project channel.
|
||||
- operating in `corp-v1-<code>-releases`;
|
||||
- running its recurring synchronization job;
|
||||
- assessing release readiness;
|
||||
- preparing version/changelog/deployment evidence;
|
||||
- the team explicitly asks to release the project;
|
||||
- updating Gondor v1 template/rendered configuration through a reviewable PR;
|
||||
- tracking migration, rollback, deployment, and post-release outcomes.
|
||||
|
||||
## Adoption Contract
|
||||
Do not start a release merely because CI is green or a synchronization run detected changes.
|
||||
|
||||
After finalization, `corp-v1-steering-committee` requires a project copy named `corp-v1-channel-releases--<code>` under `corp-v1-<code>-skills-code-agent`. Adoption preserves source history and attribution, applies project context, validates the result, and records the source branch and commit.
|
||||
## Approved Information Boundary
|
||||
|
||||
Creating existing-project copies is explicitly deferred until separately requested.
|
||||
Inspect only:
|
||||
|
||||
## Purpose Definition Pending
|
||||
```text
|
||||
corp-v1-<code>-general
|
||||
corp-v1-<code>-architecture
|
||||
corp-v1-<code>-delivery
|
||||
corp-v1-<code>-releases
|
||||
```
|
||||
|
||||
The walkthrough must define channel outcomes, responsibilities, activities, artifacts, cross-channel relationships, applicable engineering skills, synchronization behavior, approval boundaries, and verification criteria.
|
||||
Use mapped-channel history to avoid duplicate work and new relevant activity from the other three channels. Never inspect another project's channels.
|
||||
|
||||
## Release Readiness
|
||||
|
||||
Before proposing or executing a release, verify:
|
||||
|
||||
- explicit team release request and intended scope;
|
||||
- target project, environment, version, image/artifact references, and source commit;
|
||||
- approved requirements and architecture implications;
|
||||
- required tests, builds, CI, security/quality gates, and artifacts;
|
||||
- changelog/release notes accuracy;
|
||||
- configuration and secret **names/references** without accessing secret values;
|
||||
- migrations, compatibility, dependencies, capacity, and operational risk;
|
||||
- rollback strategy and previous known-good state;
|
||||
- deployment verification and ownership plan;
|
||||
- unresolved blockers and required approvals.
|
||||
|
||||
Readiness reporting does not itself authorize deployment.
|
||||
|
||||
## Controlled Gondor v1 Release Workflow
|
||||
|
||||
### Gate 1 — explicit request
|
||||
|
||||
Require an unambiguous request from the project team identifying the project and intended release. If version, environment, artifact, or scope is missing, prepare a readiness summary and ask for the missing decision rather than guessing.
|
||||
|
||||
### Gate 2 — discover repositories and instructions
|
||||
|
||||
1. Load applicable Gitea and Gondor v1 skills.
|
||||
2. Fetch both repositories and verify authenticated identity, remotes, default branches, clean worktrees, and divergence.
|
||||
3. Inspect repository-native instructions, Taskfiles/scripts, schemas, and validation commands.
|
||||
4. Identify the exact project-owned template subtree and generated destination.
|
||||
5. Verify no unrelated project configuration will be modified.
|
||||
|
||||
### Gate 3 — update template source
|
||||
|
||||
Make the smallest project-scoped change in `home-v1/gondor-v1-tmpl`. The template repository remains the source of truth; do not patch generated Gondor output manually as a substitute.
|
||||
|
||||
Validate template syntax, project values, artifact references, naming, and any repository-specific schema/checks. Keep secrets out of files, logs, commits, and chat.
|
||||
|
||||
### Gate 4 — render
|
||||
|
||||
Run the repository's authoritative rendering command. Do not invent a renderer command. Compare generated output and confirm:
|
||||
|
||||
- only expected project files changed;
|
||||
- output matches the requested release inputs;
|
||||
- no unrelated generated content drifted;
|
||||
- generated configuration passes repository validation.
|
||||
|
||||
If rendering changes unexpected projects/resources, stop and report the discrepancy.
|
||||
|
||||
### Gate 5 — separate branch in Gondor v1
|
||||
|
||||
Create a dedicated, descriptive branch in `home-v1/gondor-v1`, for example:
|
||||
|
||||
```text
|
||||
release/corp-v1-<code>-<version>
|
||||
```
|
||||
|
||||
Use the project's actual branching convention when defined. Commit only intended rendered artifacts, push the branch, and verify remote SHA equality and readback.
|
||||
|
||||
If the template repository itself also requires a reviewed source change, follow its repository policy and preserve traceability between source and rendered commits. Never force-push or bypass protected branches.
|
||||
|
||||
### Gate 6 — pull request
|
||||
|
||||
Open a PR against the configured deployment branch with:
|
||||
|
||||
- project, environment, version, and requested scope;
|
||||
- source application commit and artifact/image references;
|
||||
- template source commit;
|
||||
- rendered Gondor commit;
|
||||
- changed resources;
|
||||
- validation and CI evidence;
|
||||
- migration and rollback notes;
|
||||
- risks, blockers, and required reviewers;
|
||||
- explicit statement: **team approval required before deployment**.
|
||||
|
||||
Read back the PR URL, number, head/base SHAs, state, checks, and review status.
|
||||
|
||||
### Gate 7 — stop before deployment
|
||||
|
||||
Opening the PR completes autonomous release preparation. Do not merge, synchronize GitOps, or deploy unless the team separately approves that action and the applicable deployment workflow explicitly authorizes execution.
|
||||
|
||||
## Post-Approval and Deployment Evidence
|
||||
|
||||
When separately authorized after approval:
|
||||
|
||||
- verify approval and required checks still apply to the exact head SHA;
|
||||
- follow Gondor/GitOps deployment instructions;
|
||||
- monitor actual deployment state;
|
||||
- verify health and release-specific acceptance checks;
|
||||
- post version, commit, PR, deployment, and rollback evidence;
|
||||
- record post-release outcomes and unresolved follow-up.
|
||||
|
||||
Never claim deployment from a merged PR alone.
|
||||
|
||||
## Synchronization Workflow
|
||||
|
||||
1. Read new same-project activity and enough release history to avoid duplicates.
|
||||
2. Identify readiness changes, version/changelog drift, deployment evidence, migration/rollback risk, and release requests.
|
||||
3. Without an explicit release request, maintain readiness information and proposals only.
|
||||
4. With an explicit request, execute the controlled workflow through PR creation.
|
||||
5. Verify every repository, branch, commit, render, check, and PR claim.
|
||||
6. Post a concise release update; otherwise remain silent.
|
||||
|
||||
## Authority and Escalation
|
||||
|
||||
May autonomously after explicit release request:
|
||||
|
||||
- assess readiness;
|
||||
- update project-scoped template configuration;
|
||||
- run rendering and validation;
|
||||
- create commits and a separate branch;
|
||||
- push the branch and open a PR;
|
||||
- prepare release notes and rollback guidance.
|
||||
|
||||
Requires separate approval for:
|
||||
|
||||
- merging the release PR;
|
||||
- deployment/GitOps synchronization;
|
||||
- migrations with impact;
|
||||
- rollback execution;
|
||||
- changing secrets, permissions, costs, or unrelated infrastructure;
|
||||
- destructive or irreversible operations.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
1. Treating this setup scaffold as finalized policy.
|
||||
2. Creating project copies before the requested migration.
|
||||
3. Defining behavior indirectly instead of completing the walkthrough.
|
||||
4. Losing source history or attribution during adoption.
|
||||
1. Treating green CI as a release request.
|
||||
2. Editing generated Gondor files without updating template source.
|
||||
3. Inventing render commands instead of reading repository instructions.
|
||||
4. Including unrelated project drift in the release branch.
|
||||
5. Opening a PR without traceable source/template/rendered commits.
|
||||
6. Merging or deploying before team approval.
|
||||
7. Claiming deployment from PR or commit state alone.
|
||||
8. Exposing secret values while validating configuration.
|
||||
9. Inspecting another project's channels.
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- [ ] Repository exists under `home-v1-skills-code-agent`.
|
||||
- [ ] Default branch is `test`.
|
||||
- [ ] Skill name is `corp-v1-channel-releases`.
|
||||
- [ ] Version remains `0.1.0` until purpose is finalized.
|
||||
- [ ] No project-scoped copy was created during setup.
|
||||
- [ ] The team explicitly requested the release.
|
||||
- [ ] Scope, version, environment, artifact, and source SHA are known.
|
||||
- [ ] Readiness gates and blockers are recorded.
|
||||
- [ ] Only the project's template portion changed.
|
||||
- [ ] Authoritative rendering and validation passed.
|
||||
- [ ] Rendered output contains only expected changes.
|
||||
- [ ] A separate Gondor v1 branch was pushed and read back.
|
||||
- [ ] PR head/base SHAs, checks, and URL were verified.
|
||||
- [ ] The PR clearly requires team approval before deployment.
|
||||
- [ ] No merge or deployment occurred without separate authorization.
|
||||
|
||||
Reference in New Issue
Block a user