ci(platform): auto-regenerate helm-docs README on release-please PRs - #201
ci(platform): auto-regenerate helm-docs README on release-please PRs#201jp-ayyappan wants to merge 2 commits into
Conversation
release-please bumps chart versions in Chart.yaml but does not run helm-docs, so the README version badge goes stale on every release PR and the "Helm Lint -> Fail if docs are not up-to-date" gate fails (e.g. PR #200 for platform 0.16.0). Add a Release Docs Sync workflow that regenerates the helm-docs README on release-please PR branches and commits the result back, so the lint gate stays green without hand-editing the auto-generated release PR. Signed-off-by: Jp Ayyappan <108297634+jp-ayyappan@users.noreply.github.com> Co-authored-by: CoopAgent <coopagent@users.noreply.github.com>
|
Warning Review limit reached
Next review available in: 10 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe pull request adds a GitHub Actions workflow that detects release-please pull requests, generates a scoped token, checks out the release branch, runs verified ChangesRelease documentation synchronization
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant PullRequest
participant GitHubActions
participant GitHubApp
participant HelmDocs
participant ReleaseBranch
PullRequest->>GitHubActions: Trigger release documentation workflow
GitHubActions->>GitHubApp: Generate scoped token
GitHubActions->>ReleaseBranch: Checkout release branch
GitHubActions->>HelmDocs: Verify and run helm-docs
HelmDocs->>ReleaseBranch: Update chart READMEs
GitHubActions->>ReleaseBranch: Commit and push changes
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release-docs.yaml:
- Around line 60-70: Update the “Commit regenerated README(s)” step to pass
github.event.pull_request.head.ref through the step environment, then use the
quoted Bash environment variable in the git push command instead of embedding
the GitHub expression in the shell script. Preserve the existing checkout target
and commit flow.
- Around line 30-43: Update the Generate a token step using
actions/create-github-app-token to request only the contents write permission by
adding the appropriate permission-contents configuration. Keep the existing
app-id, private-key, and Checkout release branch token usage unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 34eb61e3-37f2-4c6a-879e-a195827bfde1
📒 Files selected for processing (1)
.github/workflows/release-docs.yaml
| uses: actions/create-github-app-token@f2acddfb5195534d487896a656232b016a682f3c # v1.9.0 | ||
| with: | ||
| app-id: "${{ secrets.APP_ID }}" | ||
| private-key: "${{ secrets.AUTOMATION_KEY }}" |
There was a problem hiding this comment.
scope permissions to only what you need
permission-contents: write
Address CodeRabbit + reviewer feedback on #201: - Fix template-injection (script injection) in the commit step: pass github.event.pull_request.head.ref through a HEAD_REF env var and use the quoted "${HEAD_REF}" in git push instead of inlining the GitHub expression in the shell script. - Scope the generated app token with permission-contents: write so it only holds the contents:write permission this workflow needs. Signed-off-by: olive <olive@virtru.com> Co-authored-by: CoopAgent <coopagent@users.noreply.github.com>
|
Thanks for the review @kalynnrhew77 / @coderabbitai. Both points addressed in 9a78bc3:
No functional change to the helm-docs regen/commit flow. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
workflow=".github/workflows/release-docs.yaml"
if [[ ! -f "$workflow" ]]; then
echo "Workflow file not found: $workflow" >&2
exit 1
fi
echo "== Current commit =="
git rev-parse HEAD
echo "== Workflow content =="
cat -n "$workflow"
echo "== Relevant security-sensitive references =="
rg -n -C 4 \
'permission-contents|HEAD_REF|github\.event\.pull_request\.head\.ref|git push|create-github-app-token' \
"$workflow"Length of output: 6316
The GitHub App token step sets 🐇 ✅ If you found this review helpful, would you consider giving us a shout-out on X? Thank you for using CodeRabbit! You are interacting with an AI system. |
2 participants
Summary
Durable fix for the recurring Helm Lint failure on release-please PRs (follow-up to the manual README regen on #200).
Root cause: release-please bumps the chart
versioninChart.yamlbut does not runhelm-docs. The README version badge is rendered by helm-docs fromChart.yaml, so on every release PR the badge goes stale (e.g.0.15.0whileChart.yamlsays0.16.0). The Helm Lint job runs helm-docs and then fails on the "Fail if docs are not up-to-date" step because the committed README differs from the regenerated one. This is exactly why PR #200 (platform0.16.0) failed lint.Fix: Add a
Release Docs Syncworkflow that:mainwhose head branch starts withrelease-please--,helm-docs(same pinned1.13.1version + SHA and--chart-search-root=chartsaslint.yaml, so output is byte-identical to what the lint gate expects),charts/*/README.mdback to the release branch only if it changed.The push uses the existing GitHub App token (
APP_ID/AUTOMATION_KEY, same app release-please uses), so the follow-up commit re-triggers the required checks and the lint gate goes green on its own. If the README is already current, the job is a no-op, so it self-heals when release-please force-updates its branch on the next release.Why a workflow and not release-please
extra-filesThe README badge is owned/generated by helm-docs. A release-please
extra-filesannotation comment placed inREADME.mdwould be stripped the next time helm-docs runs (in the lint gate), reintroducing a diff. Regenerating with helm-docs on the release branch keeps a single source of truth and matches how the repo already produces docs (lint + pre-commit).Notes
if, so it never runs on normal contributor PRs.github-actions[bot]identity to satisfy the DCO check.Test plan
Release Docs Syncruns, pushes a README regen commit, and thelintcheck goes green without manual edits.Summary by CodeRabbit