You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Research: pre-flight facts for adopting chart-releaser-action #2
What pre-flight facts do we need before porting chart-releaser-action into taskmedia/helm?
Specifically:
How does chart-releaser-action (and the patched fork fty4/helm_chart-releaser-action@v1.8.1-rc1 used by helm-template) behave when gh-pages already contains packaged charts + an index.yaml built by a different mechanism (the legacy per-repo JamesIves push)? Does skip_existing dedupe safely, or does the first run need special handling (e.g. backfilling GitHub Releases for existing chart versions) to avoid clobbering or duplicating entries?
Does the taskmedia org / taskmedia/helm repo have Actions permissions set so the default GITHUB_TOKEN can push commits (contents: write) to create releases and update gh-pages, or does this need an org/repo settings change first?
1. Cutover safety — skip_existing checks the GitHub Releases API only (by tag), never index.yaml; the index update merges rather than regenerates, so legacy entries aren't dropped. But since taskmedia/helm has no GitHub Releases yet for already-published versions, a first run would treat all current versions as "new" and create redundant, index-unreferenced Releases for them. Recommendation: bump every chart's version before the first chart-releaser run, so it never touches the legacy versions at all. (Source: helm/chart-releaser's pkg/releaser/releaser.go / pkg/github/github.go.)
2. Token permissions — Job-level permissions: can only narrow the default GITHUB_TOKEN, never widen past an org/enterprise ceiling. Live check: GH_HOST=github.com gh api repos/taskmedia/helm/actions/permissions/workflow → default_workflow_permissions: "write". No Settings → Actions change needed; the existing permissions: contents: write in the workflow is sufficient. Side finding: confirmed taskmedia/helm's default_branch is still gh-pages (expected, matches the map's sequencing).
3. Fork currency — helm/chart-releaser#587 is still open/unmerged (live-checked). Stock chart-releaser v1.8.1 / chart-releaser-action v1.7.0 don't include the fix, and chart-releaser-action still defaults to pinning chart-releaser v1.7.0. The fty4 fork remains necessary — nothing to switch to yet.
Activity
fty4 commentedon Oct 5, 2026
Resolution
Findings written to
docs/research/chart-releaser-cutover.mdon branchresearch/chart-releaser-cutover.1. Cutover safety —
skip_existingchecks the GitHub Releases API only (by tag), neverindex.yaml; the index update merges rather than regenerates, so legacy entries aren't dropped. But sincetaskmedia/helmhas no GitHub Releases yet for already-published versions, a first run would treat all current versions as "new" and create redundant, index-unreferenced Releases for them. Recommendation: bump every chart's version before the first chart-releaser run, so it never touches the legacy versions at all. (Source:helm/chart-releaser'spkg/releaser/releaser.go/pkg/github/github.go.)2. Token permissions — Job-level
permissions:can only narrow the defaultGITHUB_TOKEN, never widen past an org/enterprise ceiling. Live check:GH_HOST=github.com gh api repos/taskmedia/helm/actions/permissions/workflow→default_workflow_permissions: "write". No Settings → Actions change needed; the existingpermissions: contents: writein the workflow is sufficient. Side finding: confirmedtaskmedia/helm'sdefault_branchis stillgh-pages(expected, matches the map's sequencing).3. Fork currency —
helm/chart-releaser#587is still open/unmerged (live-checked). Stockchart-releaser v1.8.1/chart-releaser-action v1.7.0don't include the fix, andchart-releaser-actionstill defaults to pinningchart-releaser v1.7.0. Thefty4fork remains necessary — nothing to switch to yet.feat: port chart-releaser release pipeline from helm-template