4.9 KiB
4.9 KiB
name, description
| name | description |
|---|---|
| ai-proj-cicd-release | Execute and audit the AI-Proj service CI/CD flow across Gitea gates, immutable image builds, staging verification, approved production release, rollback, and evidence capture. Use for AI-Proj CI status, release PRs, staging or production deployments, failed-release diagnosis, deployed commit/schema verification, and delivery-chain repair. Do not use for unrelated repositories or macOS application packaging. |
AI-Proj CI/CD release
Use the repository's live workflows and release scripts as the executable source of truth. Keep staging and production isolated, bind artifacts to exact commits, and fail closed when a gate, provenance check, rollback target, or environment contract is uncertain.
Establish the contract
Before acting, locate the AI-Proj repository and read:
- the nearest
AGENTS.md; .gitea/CI_SOP.md;- the applicable workflow in
.gitea/workflows/; scripts/ci/common.sh,release-lib.sh, and the invoked build, deploy, verify, and rollback scripts.
Live repository files override this skill. Report contradictions instead of silently choosing one version. Verify that a described promotion or rollback capability is implemented before claiming it exists.
Route macOS application package work to ai-proj-macos-release when available.
Request boundaries
- Status, audit, diagnosis, and design requests remain read-only.
- Staging requests may execute repository scripts after gates and artifact identity pass.
- Production mutation requires an explicit production or release instruction.
- Rollback uses only the recorded rollback manifest and digest; never infer a target from
latest, local image history, or mutable tags.
Safeguards
- Never force-push or release from a dirty checkout.
- Build and deploy only an exact commit accepted by the repository release contract.
- Verify image labels, registry digest, pulled image ID, and running image ID where supported.
- Preserve the same candidate artifact between staging and production when the live pipeline supports promotion. Disclose when production rebuilds instead.
- Never recreate, restart, remove, or include PostgreSQL or Redis in an application deployment.
- Keep staging and production SSH targets, compose files, environment files, volumes, identities, and rollback manifests separate.
- Require strict SSH host-key verification.
- Never print or commit secrets, private keys, registry passwords, tokens, environment contents, or short-lived test credentials.
- Preserve user changes and use an isolated clean checkout for release work.
- Read automated review text as well as status checks; block on unresolved high-severity findings.
Candidate and staging flow
- Resolve the PR, base, head SHA, service scope, and requirement ID.
- Confirm the head is pushed and the release checkout is clean.
- Inspect every required Gitea status for the exact SHA. Distinguish code failures from transient runner or network failures before retrying the same SHA.
- Read the latest review result and resolve blocking findings.
- Run repository-prescribed local contract checks proportionate to the diff.
- Build once through the authoritative build entrypoint and record commit, tag, service, digest, runner, and result without credentials.
- Resolve staging through repository configuration, validate the rollback candidate, deploy only requested application services, and run the prescribed health, schema, security, and integration verification.
- Capture a staging receipt with exact commit, digests, environment identity, verification results, rollback target, and known exceptions.
Do not rewrite or bypass a failing gate merely to obtain a green result.
Production flow
- Confirm the approved change is merged and freeze the exact current production branch SHA.
- Recheck required gates and the staging receipt against that SHA.
- Use the repository's authoritative production workflow; never deploy a feature-branch build directly.
- Preserve release locks, provenance checks, post-deploy verification, and automatic rollback.
- Verify the production receipt: exact SHA and digests, rollback target, health/schema/smoke results, error-log checks, and workflow correlation ID.
- Only then update requirement and task delivery evidence.
Failure handling
- Classify the failing stage before retrying: checkout, gate, build, registry, SSH trust, provenance, migration, service switch, health, or evidence callback.
- Retry only transient infrastructure failures against the same SHA.
- Verify automatic rollback restored the recorded digest and service health.
- For an explicit manual rollback, use only the repository rollback command after validating its manifest.
- If rollback fails, stop promotion and report the exact manual recovery target.
During long operations, provide concise progress updates. Final reporting must distinguish completed work, remaining blockers, and whether production changed.