mav-bp-cicd

CI/CD Standards

Pipeline standards and the post-push monitoring loop. CI is the last line of defence for autonomous work: it does not hallucinate, skip steps, or declare success prematurely.

Maverick's Rules

• Every stage gates the next; cheapest checks first (lint/typecheck), expensive last. Never skip stages — no [skip ci], no conditional bypasses for "quick fixes".
• Build once, promote the same artifact — never rebuild for production; only environment config changes between environments.
• Secrets come from the platform's secret store, never the repository. Pin action/image versions.
• Production deploys are human-gated. Hotfixes follow the same pipeline, just expedited.
• Failing gates are fixed, never bypassed — no --no-verify, no force merge, no editing gate config to get green (gate configuration is infrastructure; see Boundaries).

Monitoring CI After Push

After every push, monitor the pipeline with the platform CLI, read the failed job's logs, fix locally, and re-push. From a do-issue-* workflow, use the bounded wait: uv run maverick pr wait <repo> <pr-num> --checks --timeout 30m.

Platform	Status	Logs
GitHub Actions	gh run list --branch <br> / gh pr checks <pr>	gh run view <id> --log-failed
GitLab CI	glab ci status	glab ci trace <job>
Azure DevOps	az pipelines runs list --branch <br>	az pipelines runs show --id <id>
Bitbucket Pipelines	curl .../2.0/repositories/<ws>/<repo>/pipelines/?sort=-created_on	pipeline page / API step logs

Anything genuinely project-specific (required checks, runner quirks, deploy targets) belongs in the project skill, not here.

Project Implementation Lookup

Check docs/maverick/skills/cicd/SKILL.md for the project's pipeline platform, stages, required checks, and deployment targets. If present, it wins on specifics. If missing, proceed with these standards and note the gap in your summary — do not trigger skill generation mid-task.

Detecting CI/CD Issues in Code Review

Pattern	Issue	Fix
No CI pipeline in repository	No automated quality enforcement	Add pipeline with validate/build/test stages
Pipeline has no lint/typecheck stage	Style and type errors reach main	Add validate stage before build
Tests run but failures don't block merge	False confidence	Make test stage a required gate
Secrets in pipeline YAML or repo files	Security risk	Move to platform secret store
Pipeline rebuilds for each environment	Inconsistent artifacts	Build once, promote artifact
No manual gate for production deploy	Risk of unreviewed production changes	Add manual approval step
Pipeline takes >15 minutes	Developer productivity drain	Profile and optimise, add caching
Unpinned action/image versions	Non-reproducible builds	Pin to specific versions/SHAs

Boundaries

Never, without explicit issue authorization (per mav-scope-boundaries): create or modify pipeline configuration, change stages/jobs/gates, touch CI secrets or environment variables, or trigger production deployments. Always: monitor CI after pushing and fix failures before declaring work complete.