chart-releaser-action is a GitHub Action that turns a GitHub repository into a self-hosted Helm chart repository by driving the helm/chart-releaser CLI tool, aimed at Kubernetes teams that publish Helm charts straight from GitHub Actions.

What it is

chart-releaser-action is a GitHub Action maintained under the helm organisation. On every run it inspects each chart in a repository, and whenever it finds a new chart version it creates a corresponding GitHub release named for that chart version, attaches the Helm chart artifacts to the release, and creates or updates an index.yaml file containing metadata about those releases. Together with a publishing branch such as gh-pages, that produces a Helm chart repository that users can add to their local Helm client, with GitHub Releases and GitHub Pages doing the hosting work instead of a dedicated chart server.

The concrete problem it solves is the manual bookkeeping that surrounds chart publishing inside the Helm and Kubernetes ecosystem. Instead of a maintainer packaging charts by hand, opening a release per version, uploading the .tgz artifacts, and hand-editing an index.yaml so clients see the new version, the action performs all three steps in CI. It replaces that hand-run sequence of the helm/chart-releaser CLI, which is the tool the action wraps and whose version the action pins.

Key capabilities

• Accepts a charts_dir input for repositories that keep charts somewhere other than the default /charts directory.
• Pins the underlying tool through the version input, which defaults to v1.7.0 of chart-releaser, and accepts an optional config file through the config input.
• Exposes skip_packaging, which stops at indexing and publishing so a preceding custom helm package step owns packaging.
• Exposes skip_upload for OCI-based repositories that do not use an index.yaml file.
• Exposes skip_existing to skip a package upload when the release or tag already exists, and packages_with_index to upload chart packages directly into the publishing branch.
• Sets the publishing branch through pages_branch, defaulting to gh-pages, and can mark a created GitHub release as not latest with mark_as_latest set to false.
• Emits the outputs changed_charts, a comma-separated list of charts released on the run, and chart_version, the version of the most recently generated chart.
• Requires the environment variable CR_TOKEN, normally supplied as the built-in GitHub token.

Who uses it and how

• Teams that trigger a release workflow on every push to main, using actions/checkout with fetch-depth: 0 so full history and tags are available.
• Repositories that keep charts under /charts and publish to a gh-pages branch, with Settings/Pages configured so the source branch is gh-pages.
• Workflows that grant contents: write to the GitHub token, because the action creates releases and pushes to the publishing branch.
• Pipelines with advanced packaging needs, which run helm package beforehand and then call the action with skip_packaging set so it only indexes and publishes.
• Publishing setups that target OCI-based registries and therefore set skip_upload, or that consume the changed_charts output to trigger follow-on jobs.

Getting started

Add a workflow file such as .github/workflows/release.yml and use helm/chart-releaser-action@v1.7.0 as a step, passing CR_TOKEN set to the repository's GITHUB_TOKEN secret and granting the job contents: write permissions.

How it compares

No paid products are listed as targets of this action, so the meaningful comparison is with the tools the facts already name. It sits alongside helm/chart-releaser as a GitHub Actions wrapper rather than a replacement, since the CLI does the packaging, indexing, and uploading work, and it sits alongside helm package and OCI-based repositories as one publishing route among the options those mechanisms support.

When to use it — and when not to

Choose it when charts live in a GitHub repository and GitHub Releases plus a publishing branch are an acceptable home for them, because the action depends on a gh-pages-style branch, a Pages source setting, and a token with write access. Do not choose it for non-GitHub forges or for teams that need a registry-native workflow, since skip_upload exists precisely because OCI-based repositories do not consume index.yaml. Note also that the project carries 79 open issues and delegates most behaviour to the chart-releaser version pinned in the version input, so upgrades of that tool are the place to look when publishing behaviour changes.

name: Release Charts

on:
  push:
    branches:
      - main

jobs:
  release:
    # depending on default permission settings for your org (contents being read-only or read-write for workloads), you will have to add permissions
    # see: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Configure Git
        run: |
          git config user.name "$GITHUB_ACTOR"
          git config user.email "$GITHUB_ACTOR@users.noreply.github.com"

      - name: Run chart-releaser
        uses: helm/chart-releaser-action@v1.7.0
        env:
          CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

- name: Run chart-releaser
  uses: helm/chart-releaser-action@v1.7.0
  with:
    charts_dir: charts
    config: cr.yaml
  env:
    CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

owner: myaccount
git-base-url: https://api.github.com/