Include a force option to always publish

[brettmorien]

Include a force option to always publish

[drauschenbach]

It makes no sense to me that this chart releaser action would want to set a tag. CI+CD pipelines are DOWNSTREAM from Git actions such as the setting of a tag.

It also makes no sense to me that the examples for using this pipeline all show that it runs on merges to master. One of the largest value props of Git is that everything can be previewed and verified and peer reviewed in a merge request, and then all the gory details can be squash-committed before any merge to master. And so I've grown accustomed to setting tags on commits in a feature branch (eg 1.2.1-rc1), so that the merge request can show the CI+CD results.

[unguiculus]

Why do you create the tag in the first place? chart-releaser does that for you.

[RafalSkolasinski]

Just to add to discussion: ability to force re-publish would be great in case something goes wrong and the artifacts / metadata need fixing.

[brettmorien]

We would like to use the Github UI to create a release with version information and the likes. This is the trigger for a release pipeline which includes building the chart and publishing it. The Create Release UI does create a tag automatically, so it's redundant for the chart releaser to do that as well.

Since this post we've manually created a script step that builds the helm chart and pushes it to our GH hosting. If you are curious, you can find it here:
https://github.com/orbit/orbit/blob/master/.github/workflows/release_orbit.yml

[pete911]

@brettmorien @drauschenbach I ended up just using chart-releaser directly in the github workflow. I also needed to publish chart on every tag. This is my setup:

      - name: Package and upload helm chart
        run: |
          # donwload helm chart releaser
          curl -sSLo cr.tar.gz "https://github.com/helm/chart-releaser/releases/download/v1.2.1/chart-releaser_1.2.1_linux_amd64.tar.gz"
          tar -xzf cr.tar.gz
          rm -f cr.tar.gz
          owner=$(cut -d '/' -f 1 <<< "$GITHUB_REPOSITORY")
          repo=$(cut -d '/' -f 2 <<< "$GITHUB_REPOSITORY")
          # package chart
          ./cr package charts/$repo
          # upload chart to github relases
          ./cr upload \
              --owner "$owner" \
              --git-repo "$repo" \
              --token "${{ secrets.GITHUB_TOKEN }}" \
              --release-name-template "{{ .Version }}"
          # update index and push to github pages
          git config user.email "[email protected]"
          git config user.name "$owner"
          ./cr index \
              --owner "$owner" \
              --git-repo "$repo" \
              --token "${{ secrets.GITHUB_TOKEN }}" \
              --release-name-template "{{ .Version }}" \
              --index-path ./index.yaml \
              --charts-repo https://$owner.github.io/$repo \
              --push

[lukasmrtvy]

Another use case is relasing from remote repository:

This will not work:

jobs:
  repo-sync:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        repository: 'opendistro-for-elasticsearch/opendistro-build'

    - 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]
      with:
        charts_dir: helm/
      env:
        CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

[duyleekun]

I guess the concept of this action is for dedicated git project for storing helm charts and this shouldn't be used to mix charts with application. Therefore, the design decision kind of make sense if you think it that way

[GezimSejdiu]

Hi all,

I also see a need to have a possibility to enforce when to do always publish e..g if the version contains SNAPSHOT (that is the idea why we have SNAPSHOT in the first place so that the current version can be always tested e2e before a proper release). Let us take maven-deploy plugin: https://maven.apache.org/plugins/maven-deploy-plugin/usage.html as an example.

I did try somehow to simulate it (but a bit hacky and I do not like it a lot) by providing a filter mechanism that checks if the version contains SNAPSHOT to delete that specific tag/release and redeploy (release it). The challenge was to delete/remove the chart from the gh-pages (there may be a solution, but I didn't like the approach -- to hacky).

So, I would like to have something:

• check on specific fields e.g. version contains('SNAPSHOT) --> do (re-deploy) and also restrict it to be triggered only on SNAPSHOT.

Best regards,