helm/chart-releaser-action

A GitHub Action to turn a GitHub project into a self-hosted Helm chart repo, using helm/chart-releaser CLI tool

Helm

Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources.

Use Helm to:

• Find and use popular software packaged as Helm Charts to run in Kubernetes
• Share your own applications as Helm Charts
• Create reproducible builds of your Kubernetes applications
• Intelligently manage your Kubernetes manifest files
• Manage releases of Helm packages

Helm in a Handbasket

Helm is a tool that streamlines installing and managing Kubernetes applications. Think of it like apt/yum/homebrew for Kubernetes.

• Helm renders your templates and communicates with the Kubernetes API
• Helm runs on your laptop, CI/CD, or wherever you want it to run.
• Charts are Helm packages that contain at least two things:
  • A description of the package (Chart.yaml)
  • One or more templates, which contain Kubernetes manifest files
• Charts can be stored on disk, or fetched from remote chart repositories (like Debian or RedHat packages)

Install

Binary downloads of the Helm client can be found on the Releases page.

Unpack the helm binary and add it to your PATH and you are good to go!

If you want to use a package manager:

• Homebrew users can use brew install helm.
• Chocolatey users can use choco install kubernetes-helm.
• Scoop users can use scoop install helm.
• Snapcraft users can use snap install helm --classic

To rapidly get Helm up and running, start with the Quick Start Guide.

See the installation guide for more options, including installing pre-releases.

Docs

Get started with the Quick Start guide or plunge into the complete documentation

Roadmap

The Helm roadmap uses GitHub milestones to track the progress of the project.

Community, discussion, contribution, and support

You can reach the Helm community and developers via the following channels:

• Kubernetes Slack:
  • #helm-users
  • #helm-dev
  • #charts
• Mailing List:
  • Helm Mailing List
• Developer Call: Thursdays at 9:30-10:00 Pacific (meeting details)

Contribution

If you're interested in contributing, please refer to the Contributing Guide before submitting a pull request.

Code of conduct

Participation in the Helm community is governed by the Code of Conduct.

chart-releaser-action's Issues

Node not ready for scheduling

Run chart-testing (install) step fails due to nodes not in the ready state. The test fails with the following logs.

Events:
  Type     Reason            Age               From               Message
  ----     ------            ----              ----               -------
  Warning  FailedScheduling  38s (x5 over 5m)  default-scheduler  0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.

Not need for the token anymore

The bug was fixed: https://github.community/t/github-action-not-triggering-gh-pages-upon-push/16096/6

allow overwrite of existing release?

occasionally, i will want to overwrite an existing release,
assuming this isn't an anti-pattern, subject to scorn and ridicule 😭,
would it be reasonable to allow that to happen with an opt-in flag instead of getting:

Error: error creating GitHub release: POST https://api.github.com/repos/my-org/my-repo/releases: 422 Validation Failed [{Resource:Release Field:tag_name Code:already_exists Message:}]

error creating GitHub release: 404 Not found

Been banging my head against a wall with this one. I've created my workflow according to the example

name: Release Charts

on:
  push:
    branches:
      - master

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Configure Git
        run: |
          git config user.name "$GITHUB_ACTOR"
          git config user.email "[email protected]"

      - name: Run chart-releaser
        uses: helm/[email protected]
        with:
          charts_repo_url: "https://schizoid90.github.io/krew-museum"
          charts_dir: "./charts"
        env:
          CR_TOKEN: "${{ secrets.CR_PAT }}"

When it runs I get the error

Successfully packaged chart and saved it to: .cr-release-packages/krew-museum-0.1.1.tgz
Releasing charts...
Error: error creating GitHub release: POST https://api.github.com/repos/schizoid90/krew-museum/releases: 404 Not Found []

When I hit that page in my browser i don't get a 404 error so it does exist.

My directory layout is as below

.
├── Dockerfile
├── LICENSE
├── README.md
├── charts
│   └── krew-museum
│       ├── Chart.yaml
│       ├── templates
│       │   ├── _helpers.tpl
│       │   ├── deployment.yaml
│       │   ├── ingress.yaml
│       │   ├── service.yaml
│       │   └── statefulset.yaml
│       └── values.yaml
└── src
    ├── handlers.go
    ├── helpers.go
    └── main.go

anyone able to point me where I'm going wrong?

Many thanks

Doesn't delete chart from GH Pages if deleted from the repository

I added a test chart to a repository to set things up and do some tests.

After I finished I delete the chart from the git repository.

I can though still see the chart in my index.yaml file and download it.

I don't have any suggestions, unfortunately, about how this process could work, because some release artefacts would have to be deleted. 🤔

Add support for --release-name-template flag

It would be really useful for the --release-name-template flag to be supported via the action. It might even be worth supporting flags in a generic way so new flags don't need changes to the action code.

helm/chart-releaser#74

deletes previous release from index.yaml

I'm currently running helm/[email protected] in a charts repo with great success.

However, during a time by which three actions were run in close succession to each-other, we observed that the charts releaser seemed to remove the previous committed chart from the index.yaml file (note the line with file changed, 21 insertions(+), 21 deletions(-)):

2020-05-23T13:25:41.5788332Z ##[group]Run helm/[email protected]
2020-05-23T13:25:41.5788473Z with:
2020-05-23T13:25:41.5788640Z   charts_repo_url: https://billimek.com/billimek-charts/
2020-05-23T13:25:41.5788792Z   charts_dir: charts
2020-05-23T13:25:41.5788903Z env:
2020-05-23T13:25:41.5789558Z   CR_TOKEN: ***
2020-05-23T13:25:41.5789670Z ##[endgroup]
2020-05-23T13:25:41.6300426Z billimek-charts
2020-05-23T13:25:41.6320399Z Looking up latest tag...
2020-05-23T13:25:42.4720086Z Discovering changed charts since 'radarr-4.0.0'...
2020-05-23T13:25:42.4734799Z Installing chart-releaser...
2020-05-23T13:25:42.8892617Z Packaging chart 'charts/lidarr'...
2020-05-23T13:25:42.9382193Z Successfully packaged chart and saved it to: .cr-release-packages/lidarr-2.0.0.tgz
2020-05-23T13:25:42.9392331Z Releasing charts...
2020-05-23T13:25:44.1104820Z Updating charts repo index...
2020-05-23T13:25:44.1110993Z + cr index -o billimek -r billimek-charts -c https://billimek.com/billimek-charts/
2020-05-23T13:25:44.3238776Z ====> Using existing index at .cr-index/index.yaml
2020-05-23T13:25:44.4878135Z ====> Found lidarr-2.0.0.tgz
2020-05-23T13:25:44.4878489Z ====> Extracting chart metadata from .cr-release-packages/lidarr-2.0.0.tgz
2020-05-23T13:25:44.4878878Z ====> Calculating Hash for .cr-release-packages/lidarr-2.0.0.tgz
2020-05-23T13:25:44.4879187Z --> Updating index .cr-index/index.yaml
2020-05-23T13:25:44.5058610Z ++ mktemp -d
2020-05-23T13:25:44.5072534Z + gh_pages_worktree=/tmp/tmp.T4QSvnjhtb
2020-05-23T13:25:44.5073302Z + git worktree add /tmp/tmp.T4QSvnjhtb gh-pages
2020-05-23T13:25:44.5087705Z Preparing worktree (new branch 'gh-pages')
2020-05-23T13:25:44.5114451Z Branch 'gh-pages' set up to track remote branch 'gh-pages' from 'origin'.
2020-05-23T13:25:44.5166384Z HEAD is now at e28bdda Update index.yaml
2020-05-23T13:25:44.5170743Z + cp --force .cr-index/index.yaml /tmp/tmp.T4QSvnjhtb/index.yaml
2020-05-23T13:25:44.5343822Z + pushd /tmp/tmp.T4QSvnjhtb
2020-05-23T13:25:44.5344597Z + git add index.yaml
2020-05-23T13:25:44.5383504Z + git commit '--message=Update index.yaml' --signoff
2020-05-23T13:25:44.5517227Z [gh-pages 1ec6cab] Update index.yaml
2020-05-23T13:25:44.5522664Z + local repo_url=***github.com/billimek/billimek-charts
2020-05-23T13:25:44.5523090Z  1 file changed, 21 insertions(+), 21 deletions(-)
2020-05-23T13:25:44.5530057Z + git push ***github.com/billimek/billimek-charts gh-pages
2020-05-23T13:25:47.3978005Z To https://github.com/billimek/billimek-charts
2020-05-23T13:25:47.3978701Z    e28bdda..1ec6cab  gh-pages -> gh-pages
2020-05-23T13:25:47.4089315Z + popd
2020-05-23T13:25:47.4089570Z + popd

Here are the operations that occurred to index.yaml:

• action to add chart radarr 4.0.0: https://github.com/billimek/billimek-charts/actions/runs/113248197 (I re-ran it in hopes that it would properly detect the release and re-add the missing details to the index.yaml (it did not))
• commit associated with the action: billimek/billimek-charts@e28bdda

The above were successful and good. Next the following action ran with associated commit by which the previous commit was removed for some reason:

• action to add chart lidarr 2.0.0 (different chart): https://github.com/billimek/billimek-charts/actions/runs/113248410
• commit associated with the action: billimek/billimek-charts@1ec6cab

The action to release the lidarr chart properly detected that it needed to look for changes since the previous release (Discovering changed charts since 'radarr-4.0.0'...) as well as identifying that only the chart it needed to act on was lidarr version 2.0.0.

It's interesting to note that the two action runs were close together with the commits to index.yaml being 26 seconds apart. Is it possible that there are issues when running the releaser actions too soon together?

Random 404 errors

https://github.com/brianmay/charts/runs/2899574615

Looking up latest tag...
Discovering changed charts since 'penguin-memories-0.0.2'...
Installing chart-releaser...
Adding cr directory to PATH...
Packaging chart 'charts/scrooge'...
Successfully packaged chart in /home/runner/work/charts/charts/charts/scrooge and saved it to: .cr-release-packages/scrooge-0.0.2.tgz
Releasing charts...
Updating charts repo index...
Using existing index at .cr-index/index.yaml
Error: GET https://api.github.com/repos/brianmay/charts/releases/tags/scrooge-0.0.2: 404 Not Found []

I suspect there might a race condition with github. We create the tag github, but github can't find it immediately, due to caching or something.

Have had this happen twice today.

Deploying resources to AKS cluster

Hi

Below is my workflow file. I am not able to deploy resources to Cluster, although new tags and releases are created in repo each time when I am running workflow.

Running helm/[email protected] because 1.2.0 not working for me, always, returning no changes detected.

on: [push]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
with:
fetch-depth: 0

- uses: azure/docker-login@v1
  with:
    login-server: bhupiregistery.azurecr.io
    username: ${{ secrets.acr_bhupiregistery_username }}
    password: ${{ secrets.acr_bhupiregistery_password }}

- name: Build and push image to ACR
  id: build-image
  run: |
    docker build "$GITHUB_WORKSPACE/HelloWorld" -f  "HelloWorld/Dockerfile" -t bhupiregistery.azurecr.io/testkbcluster:${{ github.sha }} --label dockerfile-path=HelloWorld/Dockerfile
    docker push bhupiregistery.azurecr.io/testkbcluster:${{ github.sha }}

- name: Configure Git
  run: |
    git config user.name "Bhupinder Singh"
    git config user.email "[email protected]"
    
- name: Install Helm
  uses: azure/setup-helm@v1
  with:
    version: v3.4.0

- name: Helm chart-releaser
  uses: helm/[email protected]
  env:
    CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
  with:
    charts_dir: HelloWorld/helloworld

Why do I have to nest my charts inside of the `charts/` subdirectory?

Lets say I have a Git repository structured like this:

github.com/myorg/helm-charts
    chart1/
        templates/
        Chart.yaml
    chart2/
        templates/
        Chart.yaml
    README.md

If I pass the chart_dir in my GitHub Workflow file as the current checked out working directory (e.g. .), it doesn't work. If I re-organize my repository structure so that it maps to:

github.com/myorg/helm-charts
    charts/
        chart1/
            templates/
            Chart.yaml
        chart2/
            templates/
            Chart.yaml
    README.md

it works just fine.

Having a top-level repository helm-charts and requiring a nested charts directory stutters and is completely unnecessary. Why was this design decision chosen and would you be willing to change it?

Error creating release with unaltered charts

I'm having an error every time I create a new release, with a chart that hasn't been modified tries to be released, and of course already exists.

The chart folder of my repo contains two charts, and I'm only want to modify and release one of them, but the second one is packaged and failing when releasing.

Packaging chart 'charts/geoserver'...
Successfully packaged chart and saved it to: .cr-release-packages/geoserver-0.1.1.tgz
Packaging chart 'charts/terria'...
Successfully packaged chart and saved it to: .cr-release-packages/terria-0.2.5.tgz
Releasing charts...
Error: error creating GitHub release: POST https://api.github.com/repos/Juanezm/csvs-charts/releases: 422 Validation Failed [{Resource:Release Field:tag_name Code:already_exists Message:}]
Usage:
  cr upload [flags]

Flags:
  -b, --git-base-url string     GitHub Base URL (only needed for private GitHub) (default "https://api.github.com/")
  -r, --git-repo string         GitHub repository
  -u, --git-upload-url string   GitHub Upload URL (only needed for private GitHub) (default "https://uploads.github.com/")
  -h, --help                    help for upload
  -o, --owner string            GitHub username or organization
  -p, --package-path string     Path to directory with chart packages (default ".cr-release-packages")
  -t, --token string            GitHub Auth Token

Global Flags:
      --config string   Config file (default is $HOME/.cr.yaml)

Is there any way to prevent this from happening without incrementing the unchanged chart's version?

Thanks

How to use with branch protection?

We have tried enabling this action in https://github.com/kubernetes-sigs/descheduler (see kubernetes-sigs/descheduler#298), but run into the problem that gh-pages has branch protection enabled (to verify the linuxfoundation CLA check).

This check is required for all Kubernetes repositories. Other projects have also hit this problem (kubernetes/autoscaler#3393 (comment)). As shown in that comment, this can be addressed by using 3rd party chart-releaser actions and taking steps like having them open PRs.

However given that this is the official chart-releaser action it should be usable by Kubernetes projects rather than having to rely on 3rd party scripts. Is there a way to configure this to work with branch protection?

If not, I believe one fix would be to update this action to optionally decouple the actual Git push (which is baked into the action) so that it can be replaced with a more configurable Pull Request action (like here, which is using a 3rd party action: https://github.com/kubernetes/dashboard/pull/5311/files#diff-29eba779142f216406df01a921ea49c3R59-R66)

Documentation misleading?!

Spent some time today fiddling around with your action.

I find the line

For more information on inputs, see the API Documentation

in the README.md a bit confusing.

For some reason I thought the inputs under the link could be used in a config file until I realized they are the options for the CLI.

Maybe the link can be removed? Or put in a different context?

Feature: Support appending an existing release

Problem
If a release already exists with the same tag then chart-releaser fails with the following error:

Error: error creating GitHub release: POST https://api.github.com/repos/my_org/actions-runner-controller-mirror/releases: 422 Validation Failed [{Resource:Release Field:tag_name Code:already_exists Message:}]

Proposed Soltuion
Check for a matching release beforehand and append to that release if the action is configured to do so.

      - name: Run chart-releaser
        uses: helm/[email protected]
        env:
          CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
          APPEND_TO_RELEASE: true

To retain compatibility make the default value false.

Error: unknown flag: --save

getting the below error:

2020-03-22T04:53:59.0640061Z helm-charts
2020-03-22T04:53:59.0694584Z Looking up latest tag...
2020-03-22T04:53:59.1785108Z Discovering changed charts since 'c967adfbf9ba2b295b5e80737220d28f27cc89b1'...
2020-03-22T04:53:59.1881729Z Installing chart-releaser...
2020-03-22T04:53:59.8399029Z Packaging chart 'charts/micro-service'...
2020-03-22T04:54:02.6547020Z Error: unknown flag: --save

anyone have any guidance as to what the issue might be?

disclaimer: my first action

Support decentralized repositories

I think the centralized chart repository is a great pattern and fits several use cases (if not most of them), but I can think of more than one occasions when I wished it was different.

In many cases, keeping the chart close to the source is desirable. For example:

• the chart changes often together with the source and updating out of tree charts is a hassle
• testing the chart with the source code changes is much harder
• sharing common resources (eg. CRDs) with charts requires a lot of copy-pasting

Keeping a chart repository on GitHub has a lot of benefits: it's easy and cheap, easy to understand and setup with this great tool. The "centralized" chart repo (with all the charts in a single repository) is supported well by this action and it works great.

It would be nice if it supported a "decentralized" model as well. External repositories could create GitHub releases, uploading the chart package which another action (or I should say this action in a different "mode") could react to and update the index.yaml.

I believe the chart-releaser tool itself already supports this use case (is that actually true?). The question is whether this action could/should support it, or maybe it should be an entirely different action/set of actions.

What do you think?

(This issue might be a duplicate of #22, but I thought explaining a use case would be a better start for a conversation.)

Add problem-matchers to help users

https://github.com/actions/toolkit/blob/master/docs/commands.md#problem-matchers

Error: error creating GitHub release: POST https://api.github.com/repos/jsoref/ssh-gateway-helm/releases: 422 Validation Failed [{Resource:Release Field:tag_name Code:already_exists Message:}]

With a problem matcher, errors like this are surfaced in a much friendlier way.

without them, one has to open the action log in search of interesting things (i.e. reading the entire log).

With them, you at least get something like this:

And if you do a bit more magic, you could even surface the error to the line that defined the tag in the chart:

---

Filing for now, I might try to implement this later. It bites me regularly.

Wrong release version

The code is expected to use tag v1.1.1

• https://github.com/helm/chart-releaser-action/blob/565e779/action.yml#L9
• https://github.com/helm/chart-releaser-action/blob/565e779/cr.sh#L21

But the release is tag v1.1.0 https://github.com/helm/chart-releaser-action/releases/tag/v1.1.0

Currently, I can't find the version/tag v1.1.1, could the release version be aligned?

Action removes untouched charts from index.yaml

Hi,

I found a weired behavior with this action. I use the following pipeline on a private repo. The action only writes those charts to the index.yaml file on the gh-pages branch which are updated in the current build. All charts which are untouched, are removed from the yaml and therefore cannot be installed anymore. The action log does not report those deletions (except the git-diff of deleted lines). Is there a solution for this?

name: Release Charts

on:
  push:
    branches:
      - master
  workflow_dispatch: {}

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Configure Git
        run: |
          git config user.name "$GITHUB_ACTOR"
          git config user.email "[email protected]"

      - name: Install Helm
        uses: azure/setup-helm@v1
        with:
          version: v3.4.0

      - name: Run chart-releaser
        uses: helm/[email protected]
        env:
          CR_TOKEN: "${{ secrets.CR_TOKEN }}"

Feature request: Provide a flag to disable publishing helm chart to gh-pages

Hi,
I have following use-case:
I would like to only create releases for helm charts repository.
I don't want to publish the charts to gh-pages because my charts reside in a private repo.

This Github action does create releases but Actions page shows release pipeline failure because the action isn't able to push to gh-pages branch. So it would be nice if there is a feature flag to disable the option to host helm charts in github pages.

Always fail to find changed charts with deeply nested (>2 levels) `charts_dir`

It looks as though this code will fail when the charts directory is nested below another directory:

chart-releaser-action/cr.sh

Lines 202 to 209 in 06d81fa

	local fields
	if [[ "$charts_dir" == '.' ]]; then
	fields='1'
	else
	fields='1,2'
	fi
	cut -d '/' -f "$fields" <<< "$changed_files" | uniq | filter_charts

For an example of this, see rook/rook, where charts_dir is cluster/charts:

• Structure
• Failed workflow

Would you accept a PR to fix this?

No changes detected

Hi, the action always returns no changes detected?

on:
  push:
    branches: [master]


jobs:

  release-chart:
    runs-on: ubuntu-latest
    steps:
    -
      uses: actions/checkout@v2
    -
      name: Configure Git
      run: |
        git config user.name "$GITHUB_ACTOR"
        git config user.email "[email protected]"
    -
      name: Install helm
      uses: azure/setup-helm@v1
    -
      name: Run chart-releaser
      uses: helm/[email protected]
      env:
        CR_TOKEN: "${{ secrets.MY_TOKEN }}"

Support for multiple charts_dirs?

Hey everyone,

I’m writing this to get some feedback on an idea I currently have.

TL;DR: How do you, especially the maintainers of the action, think about supporting multiple directories instead of just one charts_dir?

Longer explanation:

We’re currently managing multiple different parts of a software in seperate repositories. Charts are maintained in the same repository as the software they are written for to simplify lockstep releases.

The aim currently is to have one central charts repository to enable users to

• only need to use one chart repository
• not clutter the releases of the software with the chart releases

However, to prevent any possible conflicts between charts, we currently sync the charts into the following structure in the charts repository:

charts/
  source_repository_name/
    chart_1/
      Chart.yaml
      templates
    chart_2/
      Chart.yaml
      templates
  another_source_repository/
    chart_3/
      Chart.yaml
      templates

Uniqueness of the chart names can be assumed here, but syncing to one charts directory directly can’t be achieved due to some duplicate file names (of needed files for packaging) on the source_repository_name level.

I tried running the chart-releaser-action on charts/source_repository_name first and then on charts/another_source_repository, this leads to:

• charts are packaged and released correctly
• the index.yaml only contains the charts from the source repository for which the last release happened <- this is not what we want.

I think we can avoid that by allowing the specification of multiple charts_dir directories.

What do you think? Any feedback is welcome.

chart-releaser-action stops working after a precipitating failure

Description

I am running into a series of consistent errors on my self-hosted runner attempting to run the chart-releaser-action. What happens is that an initial run failure then seems to trigger the chart-releaser-action to stop working all together by not being able to run the ./cr.sh script any longer.

First Failure

Run helm/[email protected]
Looking up latest tag...
Discovering changed charts since 'test-0.0.4'...
Installing chart-releaser...
Adding cr directory to PATH...
Packaging chart 'charts/test'...
Successfully packaged chart in /mnt/c/Users/chart-releaser/actions-runner/_work/helm-charts/helm-charts/charts/test and saved it to: .cr-release-packages/test-0.0.6.tgz
Releasing charts...
Updating charts repo index...
Using existing index at .cr-index/index.yaml
Error: error loading .cr-index/index.yaml: error converting YAML to JSON: yaml: line 184: mapping values are not allowed in this context

Action stops working

After the first failure, every subsequent run concludes with cr: command not found until I stop the github actionrunner, reconfigure it, and then start it again.

Run helm/[email protected]
  with:
    charts_dir: charts
  env:
    CR_TOKEN: ***
Looking up latest tag...
Discovering changed charts since 'test-0.0.6'...
Packaging chart 'charts/test'...
/mnt/c/Users/chart-releaser/actions-runner/_work/_actions/helm/chart-releaser-action/v1.2.1/cr.sh: line 243: cr: command not found
Error: Process completed with exit code 127.

Git Directory

Simple Test Chart

name: test
description: Testing the chart releaser
version: 0.0.7
apiVersion: v1
keywords:
  - test
sources:
home:

Release Charts Workflow

name: Release Charts

on:
  push:
    branches:
      - main
    paths:
      -  "charts/**"

jobs:
  release:
    runs-on: self-hosted
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Configure Git
        run: |
          git config user.name "$GITHUB_ACTOR"
          git config user.email "[email protected]"
      - name: Install Helm
        uses: azure/setup-helm@v1
        with:
          version: v3.4.0

      - name: Run chart-releaser
        uses: helm/[email protected]
        env:
          CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

Cannot recover from failure scenario where the release was published in GH but index.yaml isn't updated

If for some reason the process of releasing a chart ends up in failure, changes might not be detected when rerunning the release action.

Scenario used to reproduce the problem: protected gh-pages branch

1. Protect your gh-pages branch to only allow code to be merged from PRs with reviews.
2. Push a chart update.
3. The Github Release with the archive files will be published.
4. The release action will fail on the push to gh-pages due to the protection configuration.
5. Remove branch protection from gh-pages.
6. Rerun the release action.

Outcome: it won't detect changes due to the presence of the the release and tag for the chart.

Workaround: manually delete the Github release and tag, then rerun the release action.

Expected outcome: the action detects that even though the Github release and tags are present, but my index.yaml file still needs to be updated. So it proceeds to update it and push the commit to gh-pages.

This currently happens with the latest release of this chart and chart-releaser (both on 1.2.1).

can't publish charts with semver build postfix (aka, cr breaks if + in chart version)

Issue

helm states that the version in Chart.yaml supports SemVer, which includes an option for a build section (+BUILD) (https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions).

But, when i try to use the chart releaser with a helm chart with a version of 0.1.0-edge1+SHA-abc123 it fails, if I drop the + to 0.1.0-edge1 it works. based on the error message it looks like some issues with escaping the +.

Logs

Run helm/[email protected]
tssc-tekton-cloud-resources
Looking up latest tag...
Discovering changed charts since 'ceed80e8ab27acbabccbbd21434b43ee19d0abfb'...
Installing chart-releaser...
Packaging chart 'charts/tssc-workflow-tekton-cluster-resources'...
Successfully packaged chart and saved it to: .cr-release-packages/tssc-workflow-tekton-cluster-resources-0.1.0-edge8+shaceed80e8.tgz
Packaging chart 'charts/tssc-workflow-tekton-pipeline'...
walk.go:74: found symbolic link in path: /home/runner/work/tssc-tekton-cloud-resources/tssc-tekton-cloud-resources/charts/tssc-workflow-tekton-pipeline/charts/tssc-workflow-tekton-shared-resources resolves to /home/runner/work/tssc-tekton-cloud-resources/tssc-tekton-cloud-resources/charts/tssc-workflow-tekton-shared-resources
walk.go:74: found symbolic link in path: /home/runner/work/tssc-tekton-cloud-resources/tssc-tekton-cloud-resources/charts/tssc-workflow-tekton-pipeline/charts/tssc-workflow-tekton-shared-resources resolves to /home/runner/work/tssc-tekton-cloud-resources/tssc-tekton-cloud-resources/charts/tssc-workflow-tekton-shared-resources
Successfully packaged chart and saved it to: .cr-release-packages/tssc-workflow-tekton-pipeline-0.1.0-edge8+shaceed80e8.tgz
Packaging chart 'charts/tssc-workflow-tekton-shared-resources'...
Successfully packaged chart and saved it to: .cr-release-packages/tssc-workflow-tekton-shared-resources-0.1.0-edge8+shaceed80e8.tgz
Releasing charts...
+ cr index -o itewk -r tssc-tekton-cloud-resources -c https://itewk.github.io/tssc-tekton-cloud-resources
Updating charts repo index...
====> UpdateIndexFile new index at .cr-index/index.yaml
Error: .cr-release-packages/tssc-workflow-tekton-cluster-resources-0.1.0-edge8%2Bshaceed80e8.tgz is not a helm chart package: stat .cr-release-packages/tssc-workflow-tekton-cluster-resources-0.1.0-edge8%2Bshaceed80e8.tgz: no such file or directory
====> Found tssc-workflow-tekton-cluster-resources-0.1.0-edge8+shaceed80e8.tgz
Usage:
  cr index [flags]

Add Support for Custom Index Page

As of now, index files are hosted in github pages. However, for some use case, those information shouldn't be in public mode.
So is it possible to provide an option to choose where the user wants to host index files on? It could be a s3 bucket which serve static website, or it could be a folder, where user freely to use their webserver.

Error dealing with charts with dependencies

Look at https://github.com/evryfs/helm-charts/commit/7758626b628d9b2a86d06f56709e0f72450360d0/checks?check_suite_id=351179142 - it seems the releaser has problems dealing with charts that have dependencies, as it fails with:

Run helm/[email protected]
helm-charts
Looking up latest tag...
Discovering changed charts since 'c7a9c284c1570187a269698c01d1821ac775917c'...
Installing chart-releaser...
Packaging chart 'charts/mcrouter'...
Error: Couldn't load repositories file (/home/runner/.helm/repository/repositories.yaml).
You might need to run `helm init` (or `helm init --client-only` if tiller is already installed)
##[error]Node run failed with exit code 1

Can I publish in another repo ?

Hi,
I am trying to use the action from one repo and actually publish in another.
I was trying with this option :

• name: Run chart-releaser
  uses: helm/[email protected]
  env:
  CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
  INPUT_CHARTS_REPO_URL: "https://Fab-T.github.io/test-helm-repo"

And it ends with Error : invalid references : gh-pages
Indeed it tries to release in my current repo: test-helm
Releasing charts...

• cr index -o Fab-T -r test-helm -c https://Fab-T.github.io/test-helm

Can you please confirm it's possible and what should I do to solve my problem ?
Thanks
Fabien

Action is incompatible with `actions/checkout@v2`

When running this action, it's checking for charts that have changed since the same commit. For instance the release workflow was triggered by commit da27374 and is checking for changes since the same commit da27374, which will always return no changes.

Source: https://github.com/jitterbit/charts/commit/da273746d48ce02e5c9e821a4e3d15da85c1755e/checks?check_suite_id=514791721#step:5:25

Logs:

> Run helm/[email protected]
  with:
    charts_dir: charts
  env:
    CR_TOKEN: ***
charts
Looking up latest tag...
Discovering changed charts since 'da273746d48ce02e5c9e821a4e3d15da85c1755e'...
Nothing to do. No chart changes detected.

Repo: https://github.com/jitterbit/charts

Workflow: https://github.com/jitterbit/charts/blob/master/.github/workflows/release.yml

Include a force option to always publish

I'm working to integrate the chart releaser action into our GitHub release pipeline and have hit an issue of conflicting assumptions. Our release pipeline is triggered off creating a new release, which creates a tag. The helm releaser action script checks for changed charts since the last tag, so you can see where the problem lies.

Run helm/[email protected]
  env:
    CR_TOKEN: ***
project
Looking up latest tag...
Discovering changed charts since 'v2.0.0a19.5'...
Nothing to do. No chart changes detected.

I propose something like a -force option for the case where the caller knows it wants to publish a new version of its charts.

Is there any way to provide package-path `-p` from chart-releaser?

I'm following the examples shown in helm/chart-releaser and tried to upload a helm chart package path using

1. Env var: CR_PACKAGE_PATH
2. Manually creating the directory .cr-release-packages/

But, my workflow job still exits with the message: Nothing to do. No chart changes detected.

Here's my workflow:

name: Release Charts

on:
  push:
    branches:
      - master

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v1
      - name: Configure Git
        run: |
          git config user.name "$GITHUB_ACTOR"
          git config user.email "[email protected]"
      - name: Run chart-releaser
        uses: helm/chart-releaser-action@master
        env:
          CR_TOKEN: '${{ secrets.CR_TOKEN }}'
          # CR_PACKAGE_PATH: 'pkgs'

Is this behavior currently supported in this action? Because I'm able to use chart-releaser successfully to upload my packages from a custom path. I'm using the GitHub enterprise account, not sure if that makes any difference. Any help or suggestions much appreciated! Thanks!

Detecting changed files is broken in v1.1.0

Hello,

because of the latest change in v1.1.0, now charts_dir doesn't work with "." (current working directory)

chart-releaser-action/cr.sh

Line 228 in c3d308d

local depth=$(( $(tr "/" "\n" <<< "$charts_dir" | wc -l) + 1 ))

This expression cannot be less than 2 that's why no changes detected in the current working directory.

$ echo $(( $(tr "/" "\n" <<< "." | wc -l) + 1 )) 
2

The + 1 should be removed.

apiVersion: v2 not being accepted

I have a chart which requires Helm3, but when I try to use the:
apiVersion: v2 in my Chart.yaml it fails with:

Error: apiVersion 'v2' is not valid. The value must be "v1"

request: ability to only push artifacts and update index in charts repo

Hi, it seems this plugin now can't deliver chart artifacts to the external charts repo. In our philosophy a chart lives in the repo next to the code. We don't understand the requirement to extract the chart to the external charts repo.

Why can't we just be given the option to only package the chart artifacts and push it to the external charts repo, letting the plugin just update the artifacts and the index there.

No changes detected is computed inside parent repository

Sorry for the strange title, but I will explain better.
I'm not sure if my procedure has sense and probably things could be done in better way:

Instead of having a gh-pages branch in every of my account projects in order to publish their helm charts (indeed, your github action works like a charm, congrats), I though about a new setup in order to simplify my life (at least temporarily):

What if I create my unique helm github project with helm publish workflow (and of course, the GH Pages enabled on gh-pages branch) and such workflow just checkout the other projects within this one (for example under './cloned' subdirectory), and then publish the charts within them (by mean charts_dir) once retrieved ?

Look at the workflow example below:

name: Package helm charts and publish them into gh-pages branch
on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      # Push events on master branch
      - master

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        #with:
        #  fetch-depth: 0

      - name: Checkout
        uses: actions/checkout@v2
        with:
          repository: testillano/h1mock
          ref: refs/heads/master
          path: cloned/h1mock

      - name: Configure Git
        run: |
          git config user.name "$GITHUB_ACTOR"
          git config user.email "[email protected]"

      - name: Install Helm
        uses: azure/setup-helm@v1
        with:
          version: v3.4.0

      - name: Run chart-releaser
        uses: helm/[email protected]
        env:
          CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
        with:
          charts_dir: cloned/h1mock/helm

Although I indicate the charts_dir = cloned/h1mock/helm it seems that the helm releaser action compares the changes in the main repository. Indeed, I'm quite sure that even looking for the "repository" which corresponds to the provided charts_dir, probably there is no way to have a history for that. So, I think a good alternative would be to have an action parameter to FORCE ANYWAY the helm release procedure. Finally, the responsability is for the user who dispatch the workflow (if actually there are no changes, the helm packages would be overwritten with the same content, as a "lesser evil").

Could it be possible ? I have seen other issues asking for the same (i.e. #8).

thank u in advance !

Chart release failing with error `no repository definition` for an existing repository added as a dependency

I am adding a dependency to my chart to the following repository: https://k8s.ory.sh/helm/charts
The documentation for all the charts in this repo is mentioned here and works as expected: http://k8s.ory.sh/helm/
The helm chart repo works fine locally when I add it with the following command: helm repo add ory https://k8s.ory.sh/helm/charts and when I install the charts separately using Helm.

I am getting an error Error: no repository definition for https://k8s.ory.sh/helm/charts when I am adding one of the charts from the above repo as a dependency to my helm chart https://github.com/factly/helm-charts/blob/main/charts/kavach/Chart.yaml#L54

Here is the error in my Github Actions: https://github.com/factly/helm-charts/runs/1886221330?check_suite_focus=true

A couple of other chart dependencies I added work fine. Any charts within this repo are failing with the above error. Any help is greatly appreciated.

Also, when I run helm template locally to test generated manifests, everything is working as expected. So, I don't think the issue is with the above repository.

Changelog in release description

I think it would be useful for the PR that triggered the release to be optionally added to the release description as a changelog item.

Ignore hidden folders when detecting charts or only package Charts with chart.yaml

If I have a charts repository, where the chart directories are in root instead of charts/ or stable/ etc, and I use

      with:
        charts_dir: .

then the Pipeline failes with:

Installing chart-releaser...
Packaging chart '.github'...
Error: chart metadata (Chart.yaml) missing

Obviously .github dir contains the workflow files and not any charts.

Possible solutions:

• Ignore hidden folders by default, but make it configurable to exclude additional folders (e.g. /docs)
• Skip folders that do not have Chart.yaml in it. If there's an (invalid) chart without this file, then people will notice anyway that something is wrong, since the chart does not get published

Warning: Unexpected input(s) 'config', valid inputs are ['version', 'charts_dir', 'charts_repo_url']

There seems to be a bug.

Documentation mentions the input config.

Setting it however results in Warning: Unexpected input(s) 'config', valid inputs are ['version', 'charts_dir', 'charts_repo_url'].

release fails if gh-pages branch doesn't yet exist

the cr.sh script creates the worktree for gh-pages branch fails when the gh-pages doesn't yet exist.

We should add some logic to check if it exists, and if not, add it, rather than fail

https://github.com/helm/chart-releaser-action/blob/master/cr.sh#L217

Nothing to do. No chart changes detected

Hi,

I'm having a bit of trouble getting this workflow to work.

You can find my workflow here

Basically when I run this and make some chart changes I end up with:

Run helm/[email protected]
netdata-helmchart
Looking up latest tag...
Discovering changed charts since '1fe4c3b8e1f1385caf11c17e422c832c711078d3'...
Nothing to do. No chart changes detected.

See sample run

I'm not really sure what I'm doing wrong. The only way I was able ot get this to work was to put things in a directory layout like charts/<name>/... but we don't really want to change our helm chart repo structure.

Thanks!

No changes detected.

Been having trouble getting this to work. I can't figure how to trigger this action to detect changes. I've commited changes under charts/<chart-name>/Chart.yml directly to main branch as well as make changes to the chart on another branch and merge. Either case yields "No changes deteced". The action, when looking for changes, looks to be performing the comparison against the latest commit and not a previous commit.

Helm 3 support

helm/[email protected] has helm 3 support and chart-releaser-action should be inline with it.

need a way to specify the package version

Use case

i want to publish my-chart-0.1.0-dev{{git commits since last release}} on every merge to master and then publish my-chart-0.1.0 when the repository is tagged with 0.1.0. Basically i want to ignore the version in the Chart.yaml and be able to use git operations to control the version workflow. the helm package command has the option to pass in the --version at runtime, need/want that same functionality in the cr tool.

How to work with private repositories?

The pipeline works fine but when I add the repo and try to use it, I get the following error:

Error: Failed to fetch https://github.com/{{org}}/{{repo}}/releases/download/{{version}}/{{version}}.tgz : 404 Not Found

I believe that is happening because helm can't authenticate.
I already tried to add the repository using my username and personal access token but it's not working.

That's how I added the repo:

helm repo add --username {{username}} --password {{personal_token}} {{org}} https://{{org}}.github.io/{{repo}}

Someone knows if does exists some trick to use it with private repos?

README on gh-pages is not updated

I assumed if I made a change to the chart README.md it'd be updated on the published gh-page, but that isn't the case. Expected?

CR no longer identifies chart changes when charts-dir is "." and charts live at the root level

In version 1.0.0, when charts-dir=. was supplied, the cr.sh set the fields=1.

chart-releaser-action/cr.sh

Lines 202 to 207 in 9723794

	local fields
	if [[ "$charts_dir" == '.' ]]; then
	fields='1'
	else
	fields='1,2'
	fi

This allowed the cut -d '/' to find changes in charts that were in a directory at the root level of the repo, something like this:

.
├── ci
├── data
├── edge
├── fabric
├── observables
├── secrets
├── sense
└── spire

as well as a second level directory like this:

.
├── fabric
│   ├── charts
│   ├── control
│   ├── control-api
│   ├── jwt
│   ├── jwt-gov
│   ├── redis
│   └── templates

In 1.2.0, the fields are determined by the calculated depth:

chart-releaser-action/cr.sh

Lines 228 to 231 in c25b74a

	local depth=$(( $(tr "/" "\n" <<< "$charts_dir" | wc -l) + 1 ))
	local fields="1-${depth}"
	cut -d '/' -f "$fields" <<< "$changed_files" | uniq | filter_charts

However, when charts_dir=., the calculated depth is 2, which leads fields to be 1-2 in the following cut command.

As we were investigating why this was failing for us, we found that the cut -d '/' -f 1-2 was returning edge/Chart.yaml rather than just edge. When edge/Chart.yaml gets passed to filter_charts() it get immediately dumped because it's not a directory.

In this case, cr 1.2.0 only finds updates in our repo when it's in a chart that is in a sub folder, like ./fabric/jwt.

Our remediation was to roll back to 1.0.0, but we'll continue to look at this and aim to get a change submitted.

This is our helm-charts repo where we run cr as part of the release process

Unable to release using tags

I'd like to release charts based on custom git tags (e.g. v1.0.0) but looks like the only supported method by chart-releaser-action is a release from a branch.

Let's assume we have a main branch, when I create a tag out of it, I get this in the chart-releaser-action step:

Looking up latest tag...
Discovering changed charts since 'v1.0.0'...
Nothing to do. No chart changes detected.

That's because, in cr.sh script, it checks the tag on the commit, and since the latest tag is actually the latest, it shows no changes.

Maybe providing an option to ignore a list of tags could be a good solution.

Please note, this is not only about using tags to release but also in case a tag is pushed to the repo it will miss up the whole release process.

Dry Run option

Allow a dry run option to test the creation of a release without actually creating the release.