212 lines
9.2 KiB
Markdown
212 lines
9.2 KiB
Markdown
---
|
|
name: corp-v1-channel-releases
|
|
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.1.0
|
|
author: Hermes Agent
|
|
license: MIT
|
|
metadata:
|
|
hermes:
|
|
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
|
|
|
|
## Overview
|
|
|
|
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.
|
|
|
|
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 skill when:
|
|
|
|
- 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.
|
|
|
|
Do not start a release merely because CI is green or a synchronization run detected changes.
|
|
|
|
## Proactive Iteration Requirement
|
|
|
|
Every releases iteration must add or materially improve at least one useful, safe release artifact in project documentation: readiness evidence, version/changelog accuracy, release dependency mapping, migration or rollback guidance, deployment verification criteria, post-release follow-up, or a concrete approval/blocker record. Never create filler and never start release execution without an explicit human team request.
|
|
|
|
## Approved Information Boundary
|
|
|
|
Inspect only:
|
|
|
|
```text
|
|
corp-v1-<code>-general
|
|
corp-v1-<code>-architecture
|
|
corp-v1-<code>-delivery
|
|
corp-v1-<code>-releases
|
|
```
|
|
|
|
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, proactively improve readiness documentation, version/changelog evidence, rollback planning, or a concrete blocker/approval request 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 with documentation and verification evidence, or the concrete gate that prevented useful work.
|
|
|
|
## 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 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.
|
|
10. Remaining passive when readiness, versioning, rollback, or release documentation can be safely improved.
|
|
|
|
## Verification Checklist
|
|
|
|
- [ ] 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.
|
|
- [ ] At least one useful release artifact was improved, or a concrete human-request/approval blocker was documented.
|