sam_oneal/pulumi-docker-build
1
0
Fork 0
Code Actions Packages Releases Wiki Activity

[rollout] Set up GH-AW and install shared PR review workflows (#794)

Browse Source 
## Summary

This PR sets up GitHub Agentic Workflows (GH-AW) and installs shared PR
review workflows in `pulumi/pulumi-docker-build`.

### Commands Executed

- `gh-aw version` → `v0.56.2` (used as entrypoint)
- `gh-aw init` → ran (`.github/aw/` was not present)
- `gh-aw add
pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-review.md@main
--name docker-build-pr-review --force`
- `gh-aw add
pulumi-labs/gh-aw-internal/.github/workflows/gh-aw-pr-rereview.md@main
--name docker-build-pr-rereview --force`
- `gh-aw compile`
- `gh-aw validate`

### Configuration

| Property | Value |
|---|---|
| AW entrypoint | `gh-aw` (v0.56.2) |
| Target base branch | `main` |
| `prefix_stem` | `docker-build` |
| `gh-aw init` | Ran (was not previously initialized) |

### Changed Files

- `.gitattributes` — added `merge=ours` strategy for
`.github/workflows/*.lock.yml`
- `.github/agents/agentic-workflows.agent.md` — created by `gh-aw init`
- `.github/workflows/copilot-setup-steps.yml` — generated dependency
workflow
- `.github/workflows/docker-build-pr-review.md` — shared PR review
workflow source
- `.github/workflows/docker-build-pr-review.lock.yml` — compiled lock
file
- `.github/workflows/docker-build-pr-rereview.md` — shared PR re-review
workflow source
- `.github/workflows/docker-build-pr-rereview.lock.yml` — compiled lock
file
- `.github/workflows/shared/review.md` — imported shared workflow
- `.github/workflows/shared/plugins/code-review/code-review.md` —
imported shared plugin

### Validation Output

**compile:**
````
⚠ Compiled 2 workflow(s): 0 error(s), 2 warning(s)
```

**validate:**
```
⚠ Compiled 2 workflow(s): 0 error(s), 2 warning(s)
```

### Validation Warnings

Both workflows produced the same non-blocking warning:
```
warning: This workflow grants id-token: write permission
OIDC tokens can authenticate to cloud providers (AWS, Azure, GCP).
Ensure proper audience validation and trust policies are configured.
````

These warnings are expected for the shared review workflows which use
OIDC for cloud authentication and are non-blocking.

---
Rollout triggered by
[provider-ops#41](https://github.com/pulumi/provider-ops/issues/41).




> Generated by [Generic Rollout
Worker](https://github.com/pulumi/provider-ops/actions/runs/23014445857)
·
[◷](https://github.com/search?q=repo%3Apulumi%2Fpulumi-docker-build+%22gh-aw-workflow-id%3A+gh-aw-workflow-rollout-worker%22&type=pullrequests)

<!-- gh-aw-agentic-workflow: Generic Rollout Worker, engine: claude, id:
23014445857, workflow_id: gh-aw-workflow-rollout-worker, run:
https://github.com/pulumi/provider-ops/actions/runs/23014445857 -->

<!-- gh-aw-workflow-id: gh-aw-workflow-rollout-worker -->

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Pulumi Bot
2026-03-12 19:25:04 +00:00
committed by GitHub
parent a8af1bfb5d
commit f6b499a9d4
9 changed files with 2899 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

179
.github/workflows/shared/plugins/code-review/code-review.md vendored Normal file
View File

@@ -0,0 +1,179 @@
---
description: High-signal PR review for gh-aw workflows using safe outputs
---
Provide a code review for the given pull request.
**Agent assumptions (applies to all agents and subagents):**
- All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched.
- Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.
- Use GitHub MCP tools for repository reads. Do not use `gh` CLI commands for repository inspection or for posting review output.
- Use the workflow PR number as the authoritative target.
- Use only gh-aw safe outputs for review side effects:
- `create-pull-request-review-comment` for actionable inline findings on changed lines
- `submit-pull-request-review` for the final review decision
- `noop` when no action should be taken
- Use cache-memory only for short-lived continuity and deduplication hints. Treat live PR state and current review threads as the source of truth.
- Never post free-form issue comments or use any side channel for review output.
- Respect the workflow safe-output limits. Prioritize the highest-signal unique findings and keep the inline review set within the configured maximum.
- Consult `.gitattributes` when relevant and treat files matched there as generated by default. Ignore findings that exist only in generated outputs such as `.lock.yml` files unless the corresponding source-of-truth files show a real behavioral problem.
To do this, follow these steps precisely:
1. Create a short todo list for yourself before starting.
2. Launch a fast subagent to check if any of the following are true:
- The pull request is closed
- The pull request is a draft
- The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
- Required PR context cannot be read from the workflow tools
If any condition is true, call `noop` with a brief reason and stop.
Note: Do not skip solely because prior automated review comments exist. Use prior comments for deduplication and stale-thread cleanup instead.
3. Read any prior review memory for this PR from cache-memory before you start detailed analysis.
Use a PR-specific file such as:
- `/tmp/gh-aw/cache-memory/pr-${PR_NUMBER}.json`
If a prior memory file exists, use it only as a hint for:
- Previously reported issues
- Dedupe patterns
- Prior review timestamps
- Risk areas worth re-checking
Do not trust cache-memory over current GitHub state. If memory conflicts with the live PR, changed files, or review threads, trust the live PR and ignore stale memory.
4. Launch a fast subagent to return a list of file paths (not their contents) for all relevant `CLAUDE.md` files including:
- The root CLAUDE.md file, if it exists
- Any CLAUDE.md files in directories containing files modified by the pull request
5. Launch a subagent to summarize:
- The PR title and description
- The changed files
- The main behavioral changes in the diff
- Any obvious risk areas worth checking carefully
6. Fetch existing review comments on the PR before preparing any new findings. Use them to identify:
- Similar issues already flagged
- Threads where a human already acknowledged the feedback
- Comments on code that has changed since the earlier review and may now be stale
7. Launch 4 review subagents in parallel. Each agent should return a list of candidate issues, where each issue includes:
- A concise description
- The reason it was flagged (for example `CLAUDE.md adherence` or `bug`)
- The changed file path
- The changed line or closest changed hunk
- Why the issue is likely real
Agents 1 + 2: CLAUDE.md compliance sonnet agents
Audit changes for `CLAUDE.md` compliance in parallel. When evaluating a file, only consider `CLAUDE.md` files that share a path scope with that file or its parents.
Agent 3: bug-focused review agent
Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.
Agent 4: behavior-focused review agent
Look for problems introduced by the new code, including security issues, incorrect logic, regressions, and missing error handling. Only look for issues that fall within changed code.
**CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where:
- The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
- The code will definitely produce wrong results regardless of inputs (clear logic errors)
- The code introduces a clear security or regression bug in changed lines
- Clear, unambiguous `CLAUDE.md` violations where you can quote the exact rule being broken
Do NOT flag:
- Code style or quality concerns
- Potential issues that depend on specific inputs or state
- Subjective suggestions or improvements
If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.
Each review subagent should receive the PR title and description so it can evaluate intent.
8. For each candidate issue, launch validation subagents in parallel. Each validator should receive the PR title, description, issue description, affected file, and affected hunk. The validator must confirm that the issue is real with high confidence.
For bug and logic issues, verify the changed code actually causes the stated problem.
For `CLAUDE.md` issues, verify both:
- The cited rule exists
- The rule applies to that file path and is actually violated
9. Filter out any issue that fails validation.
10. Deduplicate and prune the validated issue list. Remove:
- Issues already covered by an existing review comment
- Issues in threads where a human has already acknowledged the feedback
- Issues that were present in an earlier revision but are fixed in the latest code
- Duplicate findings reported by multiple subagents
- Findings that are not on changed lines or cannot be tied to a changed hunk
- Findings that only came from cache-memory and are not confirmed by the current PR state
11. Classify the remaining issues:
- `Blocking`: correctness, security, regression, data loss, or clear required-rule violations
- `Non-blocking`: actionable but not merge-blocking concerns
12. Produce a short internal summary of findings for yourself:
- If issues remain, list the highest-signal ones first
- If no issues remain, summarize that no actionable high-signal issues were found
13. If no actionable issues remain, submit exactly one final review with `submit-pull-request-review`:
- Use `APPROVE`
- Briefly state that no issues were found after checking for bugs and `CLAUDE.md` compliance
- Do not create inline comments
- Before stopping, write a compact review memory file for this PR containing:
- review timestamp
- PR number
- files reviewed
- summary of what was checked
- `issues_reported: []`
- Stop after the final review is submitted and memory is updated
14. If actionable issues remain, choose the highest-signal unique issues up to the safe-output comment limit. Create a list of planned inline comments for yourself before posting anything.
15. Post one inline comment per chosen issue using `create-pull-request-review-comment`. For each comment:
- Provide a brief description of the issue
- Explain why it matters
- Reference the exact changed line
- Cite the relevant `CLAUDE.md` rule when applicable
- Keep the comment concise and actionable
- Do not post duplicate comments for the same issue
16. Submit exactly one final review using `submit-pull-request-review`:
- Use `REQUEST_CHANGES` when at least one blocking issue remains
- Use `APPROVE` otherwise, including when only non-blocking inline comments were left
- Do not use `COMMENT` as the final review state
- Keep the summary short and aligned with the issues you posted
17. After the final review is submitted, update the PR-specific cache-memory file with a compact record of this review. Store only short-lived operational state such as:
- review timestamp
- PR number
- files reviewed
- issue fingerprints or short summaries
- whether the final review was `APPROVE` or `REQUEST_CHANGES`
Do not store secrets, tokens, personal data, or large blobs. Keep the file concise so future runs can use it for continuity and dedupe.
Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):
- Pre-existing issues
- Something that appears to be a bug but is actually correct
- Pedantic nitpicks that a senior engineer would not flag
- Issues that a linter will catch (do not run the linter to verify)
- General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md
- Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment)
- Differences that exist only in files classified as generated by `.gitattributes`, unless they expose a real issue in the source workflow, prompt, or other source-of-truth file
Notes:
- Use GitHub tools for all repository reads. Do not use web fetch.
- Always operate on the workflow PR target rather than guessing from local git state.
- Inline comments should only be created for actionable issues on changed lines.
- Cache-memory is best-effort and may be missing or stale. Use it to improve continuity, never to override current repository state.
- When linking to code in an inline comment, use a full GitHub blob URL with a full SHA and a line range, for example: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
- Requires full git sha
- Do not use shell substitution in the URL
- Repo name must match the repo you're code reviewing
- Use `#L[start]-L[end]`
- Provide at least one line of context before and after when possible
- If context checks fail or the PR is not reviewable, call `noop` with a brief explanation instead of exiting silently.