Skip to content

Commit 68d98f0

Browse files
nicolas2bertnicolas2bert
authored
Merge pull request #81 from scality/setup/claude-code-review
Introduce claude code review workflow
2 parents 853b56e + 01d45db commit 68d98f0

File tree

4 files changed

+242
-0
lines changed

4 files changed

+242
-0
lines changed

‎.claude/skills/review-pr/SKILL.md‎

Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,135 @@
1+
---
2+
name: review-pr
3+
description: Review a PR on scality/workflows (reusable GitHub Actions workflows for the Scality org)
4+
argument-hint: <pr-number-or-url>
5+
disable-model-invocation: true
6+
allowed-tools: Bash(gh repo view *), Bash(gh pr view *), Bash(gh pr diff *), Bash(gh pr comment *), Bash(gh api *), Bash(git diff *), Bash(git log *), Bash(git show *)
7+
---
8+
9+
# Review GitHub PR
10+
11+
You are an expert code reviewer. Review this PR:
12+
13+
## Determine PR target
14+
15+
Parse `` to extract the repo and PR number:
16+
17+
- If arguments contain `REPO:` and `PR_NUMBER:` (CI mode), use those values directly.
18+
- If the argument is a GitHub URL (starts with `https://github.com/`), extract `owner/repo` and the PR number from it.
19+
- If the argument is just a number, use the current repo from `gh repo view --json nameWithOwner -q .nameWithOwner`.
20+
21+
## Output mode
22+
23+
- **CI mode** (arguments contain `REPO:` and `PR_NUMBER:`): post inline comments and summary to GitHub.
24+
- **Local mode** (all other cases): output the review as text directly. Do NOT post anything to GitHub.
25+
26+
## Repo context
27+
28+
This is the **Scality reusable GitHub Actions workflows repository**. It provides standardized CI/CD workflow templates consumed by downstream Scality repos. It contains:
29+
30+
- Reusable workflow definitions (`.github/workflows/*.yaml`) — Docker builds, Trivy scanning, LFS warnings, Claude code review
31+
- MkDocs Material documentation (`docs/`, `mkdocs.yml`)
32+
- Test fixtures (`tests/docker/`) — Dockerfiles used to validate workflows
33+
- Dependabot configuration for automated dependency updates
34+
- Python dependencies only for docs tooling (`requirements.txt`)
35+
36+
PRs typically involve: workflow YAML changes, action version bumps (Dependabot), documentation updates, and test Dockerfile modifications.
37+
38+
## Steps
39+
40+
1. **Fetch PR details:**
41+
42+
```bash
43+
gh pr view <number> --repo <owner/repo> --json title,body,headRefOid,author,files
44+
gh pr diff <number> --repo <owner/repo>
45+
```
46+
47+
2. **Read changed files** to understand the full context around each change (not just the diff hunks).
48+
49+
3. **Analyze the changes** against these criteria:
50+
51+
| Area | What to check |
52+
|------|---------------|
53+
| Workflow syntax | Valid GitHub Actions YAML — correct `on` triggers, proper `uses` references, required `inputs`/`secrets` declarations, job dependency chains |
54+
| Action version pinning | Actions should pin to a specific major version tag (e.g., `@v6`), not `@main` or a full SHA without comment |
55+
| Secret exposure | No credentials, tokens, or keys in plain text; secrets passed only via `secrets:` blocks |
56+
| Permissions | Jobs use least-privilege `permissions:` — no unnecessary `write` scopes |
57+
| Breaking changes | Changes to workflow `inputs`, `secrets`, or `outputs` that would break downstream callers |
58+
| Backward compatibility | Renamed/removed inputs must have a migration path for consuming repos |
59+
| Docker best practices | Multi-stage builds, minimal base images, no unnecessary `RUN` layers, proper use of build cache |
60+
| Trivy/security scanning | Correct SARIF output, proper severity thresholds, rate-limiting mitigations |
61+
| Documentation sync | Workflow changes reflected in corresponding `docs/*.md` files |
62+
| MkDocs config | Valid `mkdocs.yml` navigation, no broken internal links |
63+
| Test coverage | New workflow features have corresponding test scenarios in `tests/` |
64+
| Security | OWASP-relevant issues — command injection in `run:` steps, untrusted input in expressions |
65+
66+
4. **Deliver your review:**
67+
68+
### If CI mode: post to GitHub
69+
70+
#### Part A: Inline file comments
71+
72+
For each specific issue, post a comment on the exact file and line:
73+
74+
```bash
75+
gh api -X POST -H "Accept: application/vnd.github+json" "repos/<owner/repo>/pulls/<number>/comments" -f body="Your comment<br><br>— Claude Code" -f path="path/to/file" -F line=<line_number> -f side="RIGHT" -f commit_id="<headRefOid>"
76+
```
77+
78+
**Never use newlines in bash commands** — use `<br>` for line breaks in comment bodies. The command must stay on a single line.
79+
80+
Each inline comment must:
81+
- Be short and direct — say what's wrong, why it's wrong, and how to fix it in 1-3 sentences
82+
- No filler, no complex words, no long explanations
83+
- When the fix is a concrete line change (not architectural), include a GitHub suggestion block so the author can apply it in one click:
84+
````
85+
```suggestion
86+
corrected-line-here
87+
```
88+
````
89+
Only suggest when you can show the exact replacement. For architectural or design issues, just describe the problem.
90+
- Never put `<br>` inside code blocks or suggestion blocks — `<br>` renders as literal text in code. Use `<br>` only in regular comment text.
91+
- End with: `— Claude Code`
92+
93+
Use the line number from the **new version** of the file (the line number you'd see after the PR is merged), which corresponds to the `line` parameter in the GitHub API.
94+
95+
#### Part B: Summary comment
96+
97+
```bash
98+
gh pr comment <number> --repo <owner/repo> --body "LGTM<br><br>Review by Claude Code"
99+
```
100+
101+
**Never use newlines in bash commands** — use `<br>` for line breaks in comment bodies. The command must stay on a single line.
102+
103+
Do not describe or summarize the PR. For each issue, state the problem on one line, then list one or more suggestions below it:
104+
105+
```
106+
- <issue>
107+
- <suggestion>
108+
- <suggestion>
109+
```
110+
111+
If no issues: just say "LGTM". End with: `Review by Claude Code`
112+
113+
### If local mode: output the review as text
114+
115+
Do NOT post anything to GitHub. Instead, output the review directly as text.
116+
117+
For each issue found, output:
118+
119+
```
120+
**<file_path>:<line_number>** — <what's wrong and how to fix it>
121+
```
122+
123+
When the fix is a concrete line change, include a fenced code block showing the suggested replacement.
124+
125+
At the end, output a summary section listing all issues. If no issues: just say "LGTM".
126+
127+
End with: `Review by Claude Code`
128+
129+
## What NOT to do
130+
131+
- Do not comment on markdown formatting preferences
132+
- Do not suggest refactors unrelated to the PR's purpose
133+
- Do not praise code — only flag problems or stay silent
134+
- If no issues are found, post only a summary saying "LGTM"
135+
- Do not flag style issues already covered by the project's linter (eslint, biome, pylint, golangci-lint)

‎.github/workflows/claude-code-review.yml‎

Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
name: Claude Code Review
2+
3+
on:
4+
workflow_call:
5+
secrets:
6+
GCP_WORKLOAD_IDENTITY_PROVIDER:
7+
required: true
8+
description: GCP Workload Identity Provider for Vertex AI
9+
GCP_SERVICE_ACCOUNT:
10+
required: true
11+
description: GCP Service Account for Vertex AI
12+
ANTHROPIC_VERTEX_PROJECT_ID:
13+
required: true
14+
description: GCP project ID for Vertex AI
15+
CLOUD_ML_REGION:
16+
required: true
17+
description: GCP region for Vertex AI
18+
19+
jobs:
20+
claude-review:
21+
runs-on: ubuntu-latest
22+
timeout-minutes: 15 # adds cost protection
23+
permissions:
24+
contents: read
25+
pull-requests: write
26+
id-token: write # claude-code-action needs this to authenticate with GitHub
27+
28+
steps:
29+
- uses: actions/checkout@v6
30+
with:
31+
fetch-depth: 1
32+
33+
- name: Authenticate to Google Cloud
34+
uses: google-github-actions/auth@v2
35+
with:
36+
workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
37+
service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}
38+
39+
- name: Run Claude Code Review
40+
id: claude-review
41+
continue-on-error: true
42+
uses: anthropics/claude-code-action@v1
43+
with:
44+
use_vertex: "true"
45+
prompt: "/review-pr REPO: ${{ github.repository }} PR_NUMBER: ${{ github.event.pull_request.number }}"
46+
claude_args: |
47+
--allowedTools "Bash(git diff *)" "Bash(git log *)" "Bash(git show *)" "Bash(gh repo view *)" "Bash(gh pr view *)" "Bash(gh pr diff *)" "Bash(gh pr comment *)" "Bash(gh api *)"
48+
--model "claude-opus-4-6"
49+
env:
50+
ANTHROPIC_VERTEX_PROJECT_ID: ${{ secrets.ANTHROPIC_VERTEX_PROJECT_ID }}
51+
CLOUD_ML_REGION: ${{ secrets.CLOUD_ML_REGION }}

‎.github/workflows/review.yml‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
name: Code Review
2+
3+
on:
4+
pull_request:
5+
types: [opened, synchronize]
6+
7+
jobs:
8+
review:
9+
uses: ./.github/workflows/claude-code-review.yml
10+
secrets:
11+
GCP_WORKLOAD_IDENTITY_PROVIDER: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
12+
GCP_SERVICE_ACCOUNT: ${{ secrets.GCP_SERVICE_ACCOUNT }}
13+
ANTHROPIC_VERTEX_PROJECT_ID: ${{ secrets.ANTHROPIC_VERTEX_PROJECT_ID }}
14+
CLOUD_ML_REGION: ${{ secrets.CLOUD_ML_REGION }}

‎CLAUDE.md‎

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
# CLAUDE.md
2+
3+
## Project overview
4+
5+
This is **scality/workflows**, a repository of reusable GitHub Actions workflows shared across the Scality organization. Downstream repos call these workflows via `workflow_call`.
6+
7+
## Repository structure
8+
9+
- `.github/workflows/` — Reusable workflow definitions (the core asset)
10+
- `docs/` — MkDocs Material documentation for each workflow
11+
- `tests/` — Dockerfiles used as fixtures to validate workflows on PR
12+
- `mkdocs.yml` — Documentation site configuration
13+
- `requirements.txt` — Python dependency for docs (`mkdocs-material`)
14+
15+
## Workflows
16+
17+
| File | Purpose |
18+
|------|---------|
19+
| `docker-build.yaml` | Build and push Docker images with Buildx, caching, multi-platform support |
20+
| `trivy.yaml` | Container vulnerability scanning, uploads SARIF to GitHub Security tab |
21+
| `lfs-warning.yaml` | Validates file sizes in PRs, warns about files not tracked by Git LFS |
22+
| `claude-code-review.yml` | AI-powered PR review via Vertex AI |
23+
24+
## Conventions
25+
26+
- Workflow files use `.yaml` extension (except `claude-code-review.yml`)
27+
- All workflows use `workflow_call` trigger with typed `inputs` and `secrets`
28+
- Secrets have sensible defaults where possible (e.g., `GITHUB_TOKEN` for registry auth)
29+
- Actions are pinned to major version tags (e.g., `@v6`, `@v3`)
30+
- `tests.yaml` calls all workflows locally (`./.github/workflows/...`) to validate on PR
31+
32+
## Testing
33+
34+
There is no test framework. Workflows are tested by `tests.yaml` which calls each reusable workflow with test fixtures from `tests/docker/`.
35+
36+
## Documentation
37+
38+
Documentation is built with MkDocs Material (`mkdocs build --strict`). When adding or modifying a workflow, update the corresponding page in `docs/`.
39+
40+
## Downstream impact
41+
42+
Changes to workflow `inputs`, `secrets`, or `outputs` can break consuming repos. Treat these as public API surfaces — avoid removing or renaming parameters without a migration path.

0 commit comments

Comments
 (0)