Orb version

circleci/[email protected] using helm 3
- install-helm-client: version: v3.0.0

What happened

On install-helm-chart when using helm v3+
Error: unknown flag: --name

Expected behavior

instead of using a --name flag the RELEASE_NAME should be inserted as an argument to helm install before the chart name. this is a change from helm 2 to helm 3:
helm2:
Usage: helm install [CHART] [flags]
helm3:
Usage: helm install [NAME] [CHART] [flags]
and --name is not a flag in helm 3

What would you like to be added

Helm 3 is now out of beta and the latest stable release. The current version of this orb works only with Helm 2 (especially with the init command)

Why is this needed

Helm 3 is now the standard version and Helm 2 will be less and less used

What would you like to be added

Ability to pass values files to install-helm-chart, similar to how helm install -f works. That allows environment-specific values files like values.production.yaml to be installed using this orb.

Why is this needed

We're currently able to override specific values using values-to-override, which works if you only want to override just a few values but doesn't scale well if you have separate values files for reach environment.

Orb version

3.0.1

What happened

I have many jobs using the orb [email protected] without any problem

orbs:
  helm: circleci/[email protected]

// ....step

      - helm/install-helm-client:
          version: v3.14.2
      - helm/upgrade-helm-chart:
            chart: ~/project/data-scheduler
            release-name: data-scheduler
            values-to-override: image.tag=${CIRCLE_BRANCH}-${CIRCLE_SHA1}
            namespace: scheduler-${CIRCLE_BRANCH}
            values: .circleci/environments/${CIRCLE_BRANCH}/values.yaml

I've tried to test with orb new version @3.0.1 to see if there is any differences

orbs:
  helm: circleci/[email protected]


// ...steps

      - helm/install_helm_client:
          version: v3.14.2
      - helm/upgrade-helm-chart:
            chart: ~/project/data-scheduler
            release_name:data-scheduler
            values_to_override: image.tag=${CIRCLE_BRANCH}-${CIRCLE_SHA1}
            namespace: scheduler-${CIRCLE_BRANCH}
            values: .circleci/environments/${CIRCLE_BRANCH}/values.yaml

then it returns error saying:

+ helm upgrade --install ******************** '~/project/********************' --namespace=scheduler-dev --values .circleci/environments/dev/values.yaml --set image.tag=dev-6ab48824e5762a0ccaa8c2f743fc9f79ce914fe6
Error: repo ~ not found

Exited with code exit status 1

I was curious so I re-ran into SSH job, to my surprise, I was able to issue the command manually successfully. However, it doesn't work with the job execution helm/upgrade-helm-chart.

Expected behavior

It should execute normally without any issue.

Comments

As I dig the script, it seems to be issue over here:

https://github.com/CircleCI-Public/helm-orb/blob/master/src/scripts/upgrade_helm_chart.sh

https://github.com/CircleCI-Public/helm-orb/blob/master/src/scripts/upgrade_helm_chart.sh#L66-L69

HELM_STR_ADD_REPO="$(echo "${HELM_STR_ADD_REPO}" | circleci env subst)"

if [ -n "${HELM_STR_ADD_REPO}" ]; then
  helm repo add "${HELM_STR_RELEASE_NAME}" "${HELM_STR_ADD_REPO}"
  helm repo update
fi

I do not think it is a good idea to put helm repo update before executing install or upgrade. They are for different purposes.

My suggestions is to break out and create a new job for adding multiple repos, ex:

helm/repo_update:
    - repos: "URL1","URL2"...

#55

Orb version

2.0.0

What happened

The parameter values-to-override can't handle environment variables anymore in the new orb version.

Expected behavior

I used to pass environment vars like this:
values-to-override: image.tag=0.0.${CIRCLE_SHA1},image.repository=${AWS_ECR_ACCOUNT_URL}/<< parameters.repository >>,
and get the following output in the chart:

image:
  repository: ACCOUNT.dkr.ecr.REGION.amazonaws.com/my_repo
  tag: 0.0.RANDOM_SHA1

What's broken

Instead, I'm getting this now:

image:
  repository: $AWS_ECR_ACCOUNT_URL/my_repo
  tag: 0.0.$CIRCLE_SHA1

I tried manipulating the strings in a lot of variations, and nothing helped.

I'd be glad to get a quick response, I can even contribute if needed.
This currently takes down my deployments and I will probably revert the orb version to 1.2.0 again until a fix will be available.

Orb version

3.0.0

What happened

When setting the option create_namespace in the upgrade_helm_chart command the build errors and never sets the option --create-namespace to create a new namespace:

+ '[' -n backstage ']'
+ '[' '' -eq 1 ']'
/bin/bash: line 14: [: : integer expression expected

I think the error is related to the fact that the environment variable in the command is set to HELM_BOOL_CREATE_NAMESPACE (See here) but when using it the script uses HELM_BOOL_CREATE_NAME_SPACE (Note the _ character between the NAME and SPACE See here).

I think the same happens with the install_helm_chart command here

Expected behaviour

Using the upgrade_helm_chart with the create_namespace option should add the --create-namespace option to the final helm command and should create a namespace if does not exists.

Orb version

0.2.3

What happened

It fails with Error: unknown flag: --purge

Expected behavior

It should not fail

Since the change:
d6dfabc

that sets this:

You can't use something like:

    steps:
      - helm/upgrade-helm-chart:
          add-repo: "https://charts.bitnami.com/bitnami"
          chart: charts/my-chart
          release-name: app
          values: "my-custom-values.yaml"

you get an error like:
my-custom-values.yaml: Permission denied

You are forced to do a "trick" like:

    environment:
      HELM_CHART_VALUES: "my-custom-values.yaml"
    steps:
      - helm/upgrade-helm-chart:
          add-repo: "https://charts.bitnami.com/bitnami"
          chart: charts/my-chart
          release-name: app
          values: "echo 'my-custom-values.yaml'"

NOTE: This is caused by the eval usage

What would you like to be added

When I use the command on the helm:
helm install --create-namespace --namespace
The helm takes care of creating the specified namespace and keeping its resources in that namespace.
But in this orb when I define the namespace it doesn't create and I get the following error
"Error: create: failed to create: namespaces "" not found"

Why is this needed

With this feature in the upgrade-helm-chart it would help a lot to keep the settings organized and properly separated

Orb version

circleci/[email protected]

What happened

On the last step: ERROR

Empty KUBERNETES_EXEC_INFO, defaulting to client.authentication.k8s.io/v1alpha1. This is likely a bug in your Kubernetes client. Please update your Kubernetes client.
Error: Kubernetes cluster unreachable: Get https://redacted*.*********.eks.amazonaws.com/version?timeout=32s: getting credentials: exec plugin is configured to use API version client.authentication.k8s.io/v1beta1, plugin returned version client.authentication.k8s.io/v1alpha1

Exited with code exit status 1
CircleCI received exit code 1

Expected behavior

The helm chart would update successfully if working as expected.
Authentication with client.authentication.k8s.io/v1alpha1 was not an issue before 5/9/2022
We are using AWS EKS v1.19.15.

Orb version: 0.2.3

What happened

With the job defined as

jobs:
  deploy:
    steps:
      - aws-eks/update-kubeconfig-with-authenticator:
          cluster-name: test-eks-cluster
          aws-region: "${AWS_REGION}"
      - helm/install-helm-client:
          version: v3.1.2
      - helm/upgrade-helm-chart:
          chart: kubernetes/helm_chart_name
          release-name: helm_chart_name

Results in the error on the helm/upgrade-helm-chart step:

helm repo update
Error: no repositories found. You must add one before updating

Expected behavior

Shouldn't error out

Current work around is adding this step just before the helm/upgrade-helm-chart step:

- run:
    name: "Add helm repo"
    command: |
      helm repo add stable https://kubernetes-charts.storage.googleapis.com

Orb version 1.0.1 (not fixed in newer versions)

Breaks on helm < v2.17 init due to deprecation of stable chart repo

I use this orb specifically for helm-install-client, and as of today, the repo for stable charts, which had been deprecated a while ago is no longer available. See blog post: https://helm.sh/blog/new-location-stable-incubator-charts/.

If you try and call helm init --client-only after installing helm <v2.17, it tries to add the old stable repo location, and you get a 403 code. The solution is to run helm init --client-only --stable-repo-url https://charts.helm.sh/stable

What would you like to be added

I would like the ability to have retires on the helm/install-helm-client orb. This can be defaulted to one, but the caller of the orb can optionally add the amount of retries.

Why is this needed

There is intermittent issues while trying to download helm from https://get.helm.sh. This is fixed by just doing a rerun in circleci, but it would much easier if we could just retry within the step, instead of having the workflow cancel.

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6666  100  6666    0     0   295k      0 --:--:-- --:--:-- --:--:--  295k
Downloading https://get.helm.sh/helm-v3.4.0-linux-amd64.tar.gz
curl: (7) Failed to connect to get.helm.sh port 443: Connection timed out

Orb version

1.0.1

What happened

I have an upgrade step defined:

- helm/upgrade-helm-chart:
    chart: ./helm
    release-name: frontend
    helm-version: v3.4.1

The chart is local, checked into the repository:

$ ls -la helm/
total 12
...

In CircleCI, this errors out:

helm upgrade --install frontend ./helm "$@"
Error: path "./helm" not found

Exited with code exit status 1
CircleCI received exit code 1

Expected behavior

Chart should upgrade without error.

What would you like to be added

Similarly to #41 it would be useful to be able pass multiple values files to the orb as an array:

    - helm/upgrade-helm-chart:
         atomic: true
         timeout: 10m
         helm-version: v3.7.0
         chart: ./helm
         namespace: << parameters.namespace >>
         release-name: << parameters.release-name >>
         values:
           - values-common.yaml
           - values-<<parameters.environment>>.yaml

Why is this needed

This would enable more flexible value files configuration, enabling deduplication amongst other things.

Orb version

2.0.1

What happened

Halfway through the logs I get a "/bin/bash: line 34: image.tag=[redacted-git-sha]: command not found". But then the task does continue on its merry way as if nothing happened.

At the end the new settings are not applied.

#!/bin/bash -eo pipefail
if [ -n "${ORB_PARAM_NAMESPACE}" ]; then
  set -- "$@" --namespace="${ORB_PARAM_NAMESPACE}"
fi
if [ -n "${TIMEOUT}" ]; then
  set -- "$@" --timeout "${TIMEOUT}"
fi
if [ -n "${NO_HOOKS}" ]; then
  set -- "$@" --no-hooks="${NO_HOOKS}"
fi
if [ "${RECREATE_PODS}"  == "true" ]; then
  set -- "$@" --recreate-pods
fi
if [ "${ATOMIC}" == "true" ]; then
  set -- "$@" --atomic
fi
if [ "${ORB_PARAM_WAIT}" == "true" ]; then
  set -- "$@" --wait
fi
if [ -n "${DEVEL}" ]; then
  set -- "$@" --devel "${DEVEL}"
fi
if [ "${DRY_RUN}" == "true" ]; then
  set -- "$@" --dry-run
fi
if [ "${RESET_VALUES}" == "true" ]; then
  set -- "$@" --reset-values
fi
if [ "${REUSE_VALUES}" == "true" ]; then
  set -- "$@" --reuse-values
fi
if [ -n "${VALUES}" ]; then
  set -- "$@" --values "$(eval ${VALUES})"
fi
if [ -n "${VALUES_TO_OVERRIDE}" ]; then
  set -- "$@" --set "$(eval ${VALUES_TO_OVERRIDE})"
fi
if [ -n "${VERSION}" ]; then
  set -- "$@" --version="${VERSION}"
fi

helm repo add "${ORB_PARAM_RELEASE_NAME}" "${ORB_PARAM_REPO}"
helm repo update

helm upgrade --install "${ORB_PARAM_RELEASE_NAME}" "${ORB_PARAM_CHART}" "$@"

/bin/bash: line 34: image.tag=[redacted-git-sha]: command not found
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/circleci/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/circleci/.kube/config
"keycloak" has been added to your repositories
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/circleci/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/circleci/.kube/config
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "keycloak" chart repository
Update Complete. ⎈Happy Helming!⎈
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/circleci/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/circleci/.kube/config
Release "keycloak" has been upgraded. Happy Helming!
NAME: keycloak
LAST DEPLOYED: Mon Mar  6 05:50:57 2023
NAMESPACE: keycloak-test
STATUS: deployed
REVISION: 202
TEST SUITE: None
NOTES:
***********************************************************************
*                                                                     *
*                Keycloak Helm Chart by codecentric AG                *
*                                                                     *
***********************************************************************

Keycloak was installed with an Ingress and can be reached at the following URL(s):

  - https://accounts.test.nqap.de/

CircleCI received exit code 0

The shortened version of the cci config:

jobs:
  deploy:
    parameters:
      env-name:
        description: Environment name
        type: string
    docker:
      - image: cimg/base:stable
    working_directory: ~/app
    steps:
      - checkout
      - kubernetes/install-kubectl:
          kubectl-version: "v1.21.3"
      - kubernetes/install-kubeconfig
      - helm/install-helm-client:
          version: v3.9.4
      - helm/upgrade-helm-chart:
          add-repo: https://codecentric.github.io/helm-charts
          namespace: << parameters.env-name >>
          release-name: keycloak
          chart: keycloak/keycloak
          reuse-values: true
          values-to-override: image.tag=<< pipeline.git.revision >>

orbs:
  helm: circleci/[email protected]
  kubernetes: circleci/[email protected]

workflows:
  build-master:
    jobs:
      - deploy:
          name: Deploy to Keycloak Test
          context: some-context
          env-name: keycloak-test

Expected behavior

1. If an error is encountered, the bash script should exit with a non-zero value.
2. There should not be an error with the given configuration.

Add parameter allowing to verify checksum

The download script using a raw GitHub URL to download an install script and execute it. It could be preferred to additionally control the checksum of the downloaded and then installed binary to ensure it has not been manipulated or corrupt.

What would you like to be added

Possibility to add an external repository. Something like:

jobs:
  install-helm-chart:
    executor: aws-eks/python
    parameters:
      cluster-name:
        description: Cluster name
        type: string
    steps:
      - aws-eks/update-kubeconfig-with-authenticator:
          cluster-name: << parameters.cluster-name >>
      - helm/add-helm-repository: # Just a suggestion
          name: grafana
          url: https://grafana.github.io/helm-charts
      - helm/install-helm-chart:
          chart: grafana/grafana
          helm-version: v3.2.4
          release-name: grafana-release
orbs:
  aws-eks: circleci/[email protected]
  helm: circleci/[email protected]
version: 2.1
workflows:
  deployment:
    jobs:
      - aws-eks/create-cluster:
          cluster-name: test-cluster
      - install-helm-chart:
          cluster-name: test-cluster
          requires:
            - aws-eks/create-cluster

Why is this needed

Since the stable repo is far beyond deprecation, it would be great with a command that could add and update a repository.

I'd be happy help out if this is something that should be implemented. 🙂

Orb version

0.2.1

What happened

we have a step in our workflow which install the helm client version v2.15.1
- helm/install-helm-client: version: "v2.15.1"
But on some of the builds the install of helm client fails with the following error

#!/bin/bash -eo pipefail
if which helm > /dev/null; then
  echo "helm is already installed"
  exit 0
fi
VERSION="v2.15.1"
if [ -n "${VERSION}" ]; then
  set -- "$@" --version "${VERSION}"
fi
INSTALL_SCRIPT="https://raw.githubusercontent.com/helm/helm/master/scripts/get"
curl "${INSTALL_SCRIPT}" > get_helm.sh
chmod 700 get_helm.sh
./get_helm.sh "$@"
helm init --client-only
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed

100    26  100    26    0     0      2      0  0:00:13  0:00:12  0:00:01     6
./get_helm.sh: line 1: 500:: command not found

Exited with code exit status 127

Expected behavior

Ideally and in most of the builds helm client is successfully installed on the kubernetes cluster

Orb version

2.0.1

What happened

You can pass a value to this but it does nothing. It looks like it's been this way since this was changed to use the install script from helm - nothing runs helm repo add anymore so the value of this parameter has no effect.

Expected behavior

Unused parameters are removed or documented as unused and set to be removed in the next major release.

Currently a default of 10 releases are stored in history, we want to be able to specify how many historical releases we need.

This orb has some tagging/release process that differs from the release used in the https://github.com/CircleCI-Public/Orb-Project-Template

This can lead to delayed releases for those that don't understand the release process.

What would you like to be added

CircleCI config files can be awkward to edit if there are even a few override values to specify. If the parameter was an array or perhaps a map, it would be easier to format these values.

Why is this needed

This would make working with overridden values much easier, from a readability point of view.

Orb version 2.0.1

What happened

Cannot do helm upgrade to a local chart (which is not in any repo) since add-repo variable is mandatory and forcing to do "helm repo add" with the same release name supplied to "helm install" - so I can't even work around it with just giving stable chart.

        helm repo add "${ORB_PARAM_RELEASE_NAME}" "${ORB_PARAM_REPO}"
        helm repo update
        helm upgrade --install "${ORB_PARAM_RELEASE_NAME}" "${ORB_PARAM_CHART}"

This behavior changed from v1.2.0 without considering the case of private chart without a repo.

Expected behavior

There should be a parameter which allow do disable the repo add/update command, and the add-repo param needs to be optional.

When updating from the version 1 to version 2 (1.2.0 -> 2.0.1), the command helm/upgrade-helm-chart is failing as it now needs the parameter add-repo.
We don't need that.

Do you expect users to set some unused value and set update-repositories to true?
Or can this parameter be optional?

Orb version

circleci/[email protected]

What happened

Hey there! Just wanted to notify you that the Helm Orb seems to have disappeared.
https://circleci.com/developer/orbs/orb/circleci/helm

GitHub webhooks failing with:

Expected behavior

Orb should be groovy and load proper. ✨

We want to continue using the current setup for storing helm charts and do not wish to specify the url here. Could you please make this optional? It was optional in older orb version.

Hi, I'm trying to use:

orbs:
  aws-cli: circleci/[email protected]
  aws-ecr: circleci/[email protected]
  helm: circleci/[email protected]

unfortunately the circleci/aws-cli doesn't have aws eks for some reason.. so how does one use this helm orb? are we suppose to setup the kube config before?

Thanks,

Phil

Orb version

0.2.3

What happened

The upgrade-helm-chart command timed out because it took longer than 10 minutes without any output. With wait=true, some charts can take a while to become ready.

Expected behavior

Ideally the no_output_timeout option should be exposed as a parameter, or the existing timeout parameter for helm should also be applied to no_output_timeout internally in the orb.