74 lines
4.9 KiB
Markdown
74 lines
4.9 KiB
Markdown
---
|
|
name: ai-proj-cicd-release
|
|
description: 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
|
|
|
|
1. Resolve the PR, base, head SHA, service scope, and requirement ID.
|
|
2. Confirm the head is pushed and the release checkout is clean.
|
|
3. Inspect every required Gitea status for the exact SHA. Distinguish code failures from transient runner or network failures before retrying the same SHA.
|
|
4. Read the latest review result and resolve blocking findings.
|
|
5. Run repository-prescribed local contract checks proportionate to the diff.
|
|
6. Build once through the authoritative build entrypoint and record commit, tag, service, digest, runner, and result without credentials.
|
|
7. Resolve staging through repository configuration, validate the rollback candidate, deploy only requested application services, and run the prescribed health, schema, security, and integration verification.
|
|
8. 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
|
|
|
|
1. Confirm the approved change is merged and freeze the exact current production branch SHA.
|
|
2. Recheck required gates and the staging receipt against that SHA.
|
|
3. Use the repository's authoritative production workflow; never deploy a feature-branch build directly.
|
|
4. Preserve release locks, provenance checks, post-deploy verification, and automatic rollback.
|
|
5. Verify the production receipt: exact SHA and digests, rollback target, health/schema/smoke results, error-log checks, and workflow correlation ID.
|
|
6. 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.
|