ci: use docker/cagent-action/.github/workflows/review-pr.yml

[dvdksn]

• needs: actually pass prompt-files through to the root action cagent-action#36
• closes docker/gordon#118

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	44692cc
🔍 Latest deploy log	https://app.netlify.com/projects/docsdocker/deploys/6990ac088ba7a70008341792
😎 Deploy Preview	https://deploy-preview-24132--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

Review Summary

Workflow refactoring looks good! ✅

This PR successfully migrates from an inline agent configuration to using the reusable workflow from docker/cagent-action. The configuration is clear and well-structured with no documentation quality issues found.

The additional-prompt parameter appropriately configures the review agent with clear instructions and guidelines. The content is technically accurate and suitable for its purpose as agent configuration.

[derekmisler]

the only reason i haven't approved this yet is because we need this one to land first, or the prompt files will be ignored

[thaJeztah]

@dvdksn could we make it aware of pages being removed, and for those to check if a correct redirect is added? i.e., to prevent things like #23949 (comment)

[thaJeztah]

I think we were also looking at (or already have?) helping with triage; for 404 reports, it could also check wayback-machine to verify if it was a page that previously existed to exclude reports for made-up links 🤔 (if I'm not sure, I usually do a quick check to see if there was anything at that URL in the first place #23949 (comment))

[dvdksn]

@thaJeztah yes that would be a good addition. Let me update the instruction 👍

[dvdksn]

@thaJeztah for 404 - yes, for the triage agent (todo) we could probably just add a tool to check the wayback api, eg: https://archive.org/wayback/available?url=docs.docker.com/engine/reference/builder

[usha-mandya]

LGTM

[thaJeztah]

Silly question; I see secrets: inherit what permissions does that grant, and are all permissions needed for this workflow?

[thaJeztah]

Oh; nevermind; GitHub hid those lines, but I'm guessing it's these;

permissions:
  contents: read
  pull-requests: write
  issues: write

(Was mostly concerned it could inherit write access on content 😅)

[thaJeztah]

Still wondering; would it be good to set the top-level defaults to not be permissive, and explicitly set more permissions here? I recall that's what we do in most places; e.g. https://github.com/moby/moby/blob/3068dc540f79ea43d312918857d1465f25ad128f/.github/workflows/ci.yml#L3-L10

# Default to 'contents: read', which grants actions to read commits.
#
# If any permission is set, any permission not included in the list is
# implicitly set to "none".
#
# see https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
permissions:
  contents: read

And then in steps that must have more permissions, we set it locally;
https://github.com/moby/moby/blob/3068dc540f79ea43d312918857d1465f25ad128f/.github/workflows/ci.yml#L130-L138

  govulncheck:
    runs-on: ubuntu-24.04
    timeout-minutes: 120 # guardrails timeout for the whole job
    # Always run security checks, even with 'ci/validate-only' label
    permissions:
      # required to write sarif report
      security-events: write
      # required to check out the repository
      contents: read

[dvdksn]

cc @derekmisler - do you know if we should set permissions differently?

I'll merge this for now to get the updated action in, but let's address this in a follow-up if needed.

[derekmisler]

if you don't want secrets: inherit, you can specify the 4 required secrets:

name: PR Review
on:
  issue_comment: # Enables /review command in PR comments
    types: [created]
  pull_request_review_comment: # Captures feedback on review comments for learning
    types: [created]
  pull_request_target: # Triggers auto-review on PR open; uses base branch context so secrets work with forks
    types: [ready_for_review, opened]

permissions:
  contents: read # This is required to be a top-level permission to allow `issue_comment` events to inherit the secrets on _forked_ PRs.

jobs:
  review:
    uses: docker/cagent-action/.github/workflows/review-pr.yml@latest
    # Scoped to the job so other jobs in this workflow aren't over-permissioned
    permissions:
      contents: read # Read repository files and PR diffs
      pull-requests: write # Post review comments and approve/request changes
      issues: write # Create security incident issues if secrets are detected in output
    secrets:
      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
      CAGENT_ORG_MEMBERSHIP_TOKEN: ${{ secrets.CAGENT_ORG_MEMBERSHIP_TOKEN }} # PAT with read:org scope; gates auto-reviews to org members only
      CAGENT_REVIEWER_APP_ID: ${{ secrets.CAGENT_REVIEWER_APP_ID }} # GitHub App ID; reviews appear as your app instead of github-actions[bot]
      CAGENT_REVIEWER_APP_PRIVATE_KEY: ${{ secrets.CAGENT_REVIEWER_APP_PRIVATE_KEY }} # GitHub App private key; paired with App ID above

[derekmisler]

secrets: inherit is just so you don't have to manually include repo/org action secrets.