CI/CD AI Review Kit

# CI/CD AI Review Kit

AI Summary

Purpose:

• Capture durable facts about the LabradorLabs CI/CD AI review kit so human portfolio outputs can stay grounded in actual Confluence and Bitbucket sources.

Key points:

• Source Confluence page: [DSGN|CICD] CI/CD AI Review Kit 설계 문서 (4082532543).
• Source Bitbucket repository: labrador-cicd-ai-review-kit.
• The kit standardizes the development-completion flow across multiple Bitbucket repositories instead of copying CI scripts into each repository.
• Target repositories keep only thin wrappers/configuration; common behavior lives in the central kit repository.
• The standard flow is Jira issue/branch → local/pre-push validation → Bitbucket branch pipeline → automatic PR creation → PR pipeline validation → Claude-based AI PR review → Slack notification → main merge → Docker image build/push → actual deployment system/Jira deployment event.
• The kit supports java-spring, go, python, js, and mixed profiles.
• mixed profile can test only components affected by changed paths and fails by default when a changed path is not mapped, reducing false-green risk.
• Production repositories pin the executed kit version by full commit SHA; moving refs like main are not trusted as execution anchors.
• PR pipelines use the destination branch .labrador-devflow.env as the trusted policy source, not the source branch.
• AI review first creates PR diff, runs secret scan, then calls Claude only when suspicious secrets are not found; raw secrets are not written to logs/artifacts.
• Bitbucket branch restrictions and merge checks are required for enforcement; copying kit files alone does not enforce merge policy.
• Related earlier CI/CD work also includes a Jenkins plugin/toolkit path for Bitbucket/Jenkins analysis integration, but the public portfolio item should emphasize the Bitbucket Pipelines central kit because it is the clearer current source.

Relevant when:

• Updating human/portfolio/items/ai-cicd-review-kit.html.
• Writing resume/portfolio material about CI/CD centralization, AI PR review, Bitbucket/Jira/Slack development workflow automation, and pipeline quality gates.

Do not read full document unless:

• Exact operational constraints, failure modes, or profile-level behavior are needed.

Linked documents:

• human/portfolio/items/ai-cicd-review-kit.html
• human/portfolio/index.html
• ai/wiki/projects/labrador-platform.md

Open Questions

• Quantitative adoption metrics such as number of repositories actually onboarded are not confirmed here and should not be claimed unless later verified.
• Runtime reduction or review-time reduction percentages are not confirmed and should not be invented.

Details

What the work was

The work was not simply adding an AI reviewer to CI. The stronger framing is that it created a central CI/CD execution kit for a repeatable development-completion routine across Bitbucket repositories.

The kit pulls common logic into one central repository and leaves target repositories with thin wrapper/configuration files. This avoids each repository growing a different copy of similar CI scripts.

Standard flow

The intended flow is:

1. Jira issue and branch convention.
2. Local or pre-push validation.
3. Bitbucket branch push pipeline.
4. Automatic PR creation when branch validation succeeds.
5. PR pipeline validation before merge.
6. Claude-based AI PR review after secret scanning the diff.
7. Slack success/failure notification with short failure summary and pipeline/PR links.
8. Main pipeline after merge.
9. Docker image build/push.
10. Actual deployment system reports deployment completion separately.

Security and reliability points

• Target repositories pin the kit version with a full commit SHA.
• PR pipelines trust destination branch configuration rather than source branch configuration.
• The kit uses allowlist logic for the central kit repository/ref/profile boundary.
• Secret values are stored in Bitbucket Variables, not committed configuration files.
• AI review scans added diff lines for token/password/API key/webhook-like patterns before calling the external model API.
• Docker build success alone is not treated as a test pass unless an explicit test signal or build-only opt-in is present.
• mixed profile fails by default when changed files do not match known component/common/ignored paths.
• Bitbucket branch restrictions and merge checks remain the enforcement layer.

Portfolio framing

Good public wording:

• “CI/CD 중앙 실행 킷”
• “Bitbucket PR 품질 게이트”
• “Claude 기반 AI PR 리뷰를 secret scan 이후에 실행”
• “Jira/Bitbucket/Slack/Docker로 이어지는 개발 완료 루틴 자동화”
• “full-SHA pinning, destination-branch policy, false-green 방지”

Avoid or qualify:

• Do not say it fully automated production deployment; Docker image push and actual deployment completion are separate.
• Do not claim team-wide adoption counts or performance gains without verified numbers.
• Do not expose internal repository URLs, tokens, hostnames, customer names, or variable values in public portfolio pages.