-
Notifications
You must be signed in to change notification settings - Fork 1.3k
test: validate repository_dispatch for polish workflow #542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is a dry-run workflow to test repository_dispatch before modifying the release pipeline. Will be deleted after validation.
📝 WalkthroughWalkthroughA new GitHub Actions workflow is added that listens for repository_dispatch (type: test-polish-notes) or workflow_dispatch with tag_name input. The workflow fetches the current release body for a specified tag, passes it through the ClaudeCode action to transform the changelog into polished release notes with structured sections (What's New, New, Improved, Fixed), and displays the generated outputs. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Review CompleteYour review story is ready! Comment !reviewfast on this PR to re-generate the story. |
Greptile SummaryThis PR adds a temporary test workflow to validate that
Confidence Score: 5/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant Dev as Developer/Release System
participant GH as GitHub Actions
participant Dispatch as Test Workflow
participant Claude as Claude Code Action
participant Release as GitHub Release
alt Manual Test (workflow_dispatch)
Dev->>GH: Trigger workflow manually
GH->>Dispatch: Pass tag via inputs.tag_name
else API Test (repository_dispatch)
Dev->>GH: POST /repos/.../dispatches
GH->>Dispatch: Pass tag via client_payload.tag_name
end
Dispatch->>Dispatch: Resolve TAG_NAME from inputs or payload
Dispatch->>Dispatch: Debug context (event name, tag)
Dispatch->>Release: Fetch release notes via gh CLI
Release-->>Dispatch: Return current-notes.md
Dispatch->>Dispatch: Preview first 20 lines
Dispatch->>Claude: Transform notes with prompt
Claude-->>Dispatch: Generate release-title.txt & polished-notes.md
Dispatch->>Dispatch: Display results (DRY RUN - no update)
Dispatch->>Dev: Show transformed content for validation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.github/workflows/test-polish-dispatch.yml:
- Around line 20-21: The workflow currently sets GitHub Actions permissions to
"contents: write"; change this to "contents: read" to follow least-privilege
principles since the job only reads release data and writes local files, and
verify any action that might require write (e.g., the Claude-related action)
actually doesn't need push-level content permission; update the permissions
block to use "contents: read" and if you discover an action truly requires
write, scope that permission as narrowly as possible or add it only to the
specific job that needs it.
- Around line 16-18: The workflow currently sets TAG_NAME from client_payload or
inputs but lacks a guard when it's empty, causing `gh release view` to fail with
a confusing error; add an explicit guard step that checks the TAG_NAME
environment variable (TAG_NAME) before any `gh release view` or release-related
steps and fails fast with a clear message if TAG_NAME is undefined or empty so
CI prints a helpful error and stops early.
- Around line 46-52: The GitHub Actions step "Transform release notes with
Claude" currently uses the tag anthropics/claude-code-action@v1 while passing a
sensitive claude_code_oauth_token; replace the tag with the full commit SHA for
anthropics/claude-code-action (e.g.,
anthropics/claude-code-action@<full-commit-sha>) to pin the third‑party action,
keeping the step id "claude" and the same inputs (claude_code_oauth_token,
github_token, claude_args) unchanged.
| env: | ||
| # repository_dispatch passes tag via client_payload, workflow_dispatch via inputs | ||
| TAG_NAME: ${{ github.event.client_payload.tag_name || inputs.tag_name }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a guard when TAG_NAME is missing.
If neither payload nor input is set, gh release view fails with a confusing error. A fast, explicit check will make runs clearer.
🔧 Suggested guard step
+ - name: Validate tag input
+ run: |
+ if [ -z "${{ env.TAG_NAME }}" ]; then
+ echo "TAG_NAME is required via workflow_dispatch input or repository_dispatch payload"
+ exit 1
+ fi🤖 Prompt for AI Agents
In @.github/workflows/test-polish-dispatch.yml around lines 16 - 18, The
workflow currently sets TAG_NAME from client_payload or inputs but lacks a guard
when it's empty, causing `gh release view` to fail with a confusing error; add
an explicit guard step that checks the TAG_NAME environment variable (TAG_NAME)
before any `gh release view` or release-related steps and fails fast with a
clear message if TAG_NAME is undefined or empty so CI prints a helpful error and
stops early.
| permissions: | ||
| contents: write |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reduce token scope to least privilege.
This dry-run only reads release data and writes local files; contents: read should be sufficient unless the Claude action actually needs write.
🔒 Suggested permission tightening
permissions:
- contents: write
+ contents: read🤖 Prompt for AI Agents
In @.github/workflows/test-polish-dispatch.yml around lines 20 - 21, The
workflow currently sets GitHub Actions permissions to "contents: write"; change
this to "contents: read" to follow least-privilege principles since the job only
reads release data and writes local files, and verify any action that might
require write (e.g., the Claude-related action) actually doesn't need push-level
content permission; update the permissions block to use "contents: read" and if
you discover an action truly requires write, scope that permission as narrowly
as possible or add it only to the specific job that needs it.
| - name: Transform release notes with Claude | ||
| uses: anthropics/claude-code-action@v1 | ||
| id: claude | ||
| with: | ||
| claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} | ||
| claude_args: "--allowedTools Write,Read" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🌐 Web query:
anthropics/claude-code-action GitHub action
💡 Result:
anthropics/claude-code-action is Anthropic’s official GitHub Action for running Claude Code inside GitHub workflows. It can answer code questions, review and modify PRs, create PRs from prompts, and integrate with Anthropic API or cloud providers (Bedrock, Vertex AI, Foundry). Key points and quick setup:
- Repo & license: anthropics/claude-code-action (MIT). [1]
- Features: automatic mode detection, PR/issue integration, code implementation/review, structured JSON outputs, runs on your runner. [1]
- Docs & quickstart: Anthropic docs explain installing the Claude GitHub app, adding ANTHROPIC_API_KEY secret, or using the CLI
/install-github-app. Manual setup: install https://github.com/apps/claude, add secret, copy examples/claude.yml to .github/workflows. [2] - Marketplace listing and example usage (workflow snippet, outputs, and the dangerous skip-permissions flag info). [3]
If you want, I can:
- show an example workflow configured for Anthropic API or for AWS Bedrock/Google Vertex,
- or walk through installing the GitHub app and adding secrets step-by-step. Which do you want?
🌐 Web query:
GitHub Actions security best practices pinning commit SHA vs version tag
💡 Result:
Short answer
- Pin to a full commit SHA for maximum security (immutable, prevents tag/branch tampering). [1][2]
- Tags (version tags) are more convenient but mutable unless the project offers immutable releases — only use tags for actions you fully trust or when the author provides immutable/attested releases. [1][2]
- Automate safe updates (Dependabot/Renovate or tooling that updates SHAs and opens PRs) and enforce SHA pinning/org policy where practical. [1][2][3]
Why (brief)
- Commit SHA = exact Git object; cannot be changed without changing the SHA → strong protection against covert updates. [1]
- Tags/branches (v3, v3.1, main) can be moved or re-pointed if a repo is compromised, so workflows using them can pick up malicious changes. [1][2]
- Organizations can enforce SHA pinning via allowed-actions policies and block specific actions/versions. [2]
Practical recommendations
- Use commit SHAs in workflows: uses: owner/repo/path@, and add a comment with the human-friendly tag/version. [1][8]
- Run automation to keep SHAs up to date (Dependabot for Actions, Renovate, or pinning tools) so updates are reviewed before merging. [1][3]
- Avoid floating refs: no
@main,@latest, or bare major tags unless you accept the risk. [1][5] - Restrict/allowlist verified creators or specific repos; use the allowed-actions policy to block unapproved actions. [1][2]
- Audit action source code and limit workflow permissions & secrets to reduce blast radius even if an action is compromised. [1]
References
- GitHub Security hardening for Actions (pin to full-length commit SHA; tag guidance). [1]
- GitHub Changelog: allowed actions policy, blocklist and SHA pin enforcement features. [2]
- Example tooling & automation to enforce/update pins (Dependabot/third-party pinning actions). [3]
🏁 Script executed:
# Check if there are other actions used in the repository and their pinning practices
cd .github/workflows
find . -name "*.yml" -o -name "*.yaml" | head -10Repository: Fission-AI/OpenSpec
Length of output: 147
🏁 Script executed:
# Check action pinning patterns in other workflow files
cd .github/workflows
for file in *.yml; do
echo "=== $file ==="
grep -E "uses:" "$file" | head -5
doneRepository: Fission-AI/OpenSpec
Length of output: 697
Pin the third‑party action to a commit SHA.
This step uses a sensitive OAuth token; pinning to a commit SHA prevents tag tampering and supply-chain surprises. GitHub security guidance recommends committing full commit SHAs rather than version tags for third-party actions, particularly when handling credentials.
🔒 Suggested pinning
- - name: Transform release notes with Claude
- uses: anthropics/claude-code-action@v1
+ - name: Transform release notes with Claude
+ uses: anthropics/claude-code-action@<pinned-commit-sha>🤖 Prompt for AI Agents
In @.github/workflows/test-polish-dispatch.yml around lines 46 - 52, The GitHub
Actions step "Transform release notes with Claude" currently uses the tag
anthropics/claude-code-action@v1 while passing a sensitive
claude_code_oauth_token; replace the tag with the full commit SHA for
anthropics/claude-code-action (e.g.,
anthropics/claude-code-action@<full-commit-sha>) to pin the third‑party action,
keeping the step id "claude" and the same inputs (claude_code_oauth_token,
github_token, claude_args) unchanged.
The GitHub App token doesn't have actions:write permission, which is required for workflow_dispatch. Switch to repository_dispatch which works with existing contents:write permission. Changes: - release-prepare.yml: Use gh api to trigger repository_dispatch - polish-release-notes.yml: Add repository_dispatch trigger type - Delete test workflow (validation complete) Tested via PR #542 - both workflow_dispatch and repository_dispatch triggers work correctly with claude-code-action.
The GitHub App token doesn't have actions:write permission, which is required for workflow_dispatch. Switch to repository_dispatch which works with existing contents:write permission. Changes: - release-prepare.yml: Use gh api to trigger repository_dispatch - polish-release-notes.yml: Add repository_dispatch trigger type - Delete test workflow (validation complete) Tested via PR #542 - both workflow_dispatch and repository_dispatch triggers work correctly with claude-code-action.
Summary
Temporary test workflow to validate
repository_dispatchworks before modifying the release pipeline.Context
The release pipeline is failing because:
releaseevent is not supported by claude-code-actionworkflow_dispatchrequiresactions:writepermission (which the GitHub App doesn't have)repository_dispatchIS supported and works with existingcontents:writepermissionTest Plan
workflow_dispatch(manual trigger in Actions UI)repository_dispatch:Note
This is a dry-run workflow - it does NOT modify the release. Safe to merge and test.
🤖 Generated with Claude Code
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.