Using GitLab As Helm Chart Registry | by Hayk Davtyan | May, 2022

Code, construct, and deploy!

Picture from

Since GitLab 14.1 the Bundle Registry permits customers to construct, publish, set up, and share Helm charts.

Helm makes use of a packaging format known as charts. A chart is a group of information that describe a associated set of Kubernetes assets. A single chart may be used to deploy one thing easy, like a memcached pod, or one thing advanced, like a full net app stack with HTTP servers, databases, caches, and so forth.

Making a easy Helm chart

On this story, we’re going to create a Helm chart, push it to the GitLab undertaking, package deal it, and publish it to GitLab Bundle Registry.

At first, we have to create a undertaking on GitLab, the place we’ll retailer templates of the chart.

Creating a personal undertaking

As we created the undertaking on GitLab, let’s create a easy Helm chart on the native pc by executing the next command:

$ helm create example-chart

Be sure to have put in Helm in your pc. In any other case, that command received’t execute.

The helm create creates a chart listing together with the widespread information and directories utilized in a chart.

Making a easy Helm chart

The output of the ls command reveals that crucial information have been created and we simply have to push them to the helm-chart-example undertaking on GitLab.

Pushing information to GitLab

As soon as information are efficiently pushed, we have to package deal the listing as a Helm chart for storing within the package deal registry. At this level, it may be applied by way of the helm package deal command in your pc, and it may be applied with the CI pipeline that GitLab gives. I like to recommend packaging and pushing your Helm charts with GitLab CI as a substitute of doing it by way of the command line in your pc.

Creating CI pipeline on GitLab

Earlier than making a pipeline, make it possible for the Packages button is enabled from the undertaking’s Settings→Normal→Visibility, undertaking options, permissions tab, as you possibly can see under:

Mission’s settings on GitLab

Essentially the most fascinating half is right here! Now, we’re going to create a pipeline on GitLab for packaging and publishing our Helm chart. It’s simple to do from the undertaking’s CI/CD→Editor part. In the event you’re not accustomed to GitLab CI/CD, you possibly can try the Get began information here.

The pipeline will look one thing like this:

Making a pipeline on GitLab

The pipeline’s code is offered right here. Let’s go line by line to know it.


On the prime of the file, we’ve outlined the stage identify known as package-publish , which we’ll use within the helm-package job. The tags key phrase is chargeable for the gitlab-runners. Since I take advantage of a self-hosted gitlab-runner on my minikube surroundings, I’ll use the corresponding tag of that runner on this undertaking.

* Please notice that you must use different tags in your pipeline.

As you seen, there’s the CHART variable whose worth is identical as our Helm chart identify that we’ve created. The variable is only for consolation, to keep away from utilizing the identical identify a number of occasions within the code.

Within the before_script part, we set up some dependencies just like the git and helm-push plugin. The following vital half is the authentication with the registry by way of helm repo add command that may add the Helm repository within the shell of the gitlab-runner. The CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_API_V4_URL and CI_PROJECT_ID variables are GitLab’s CI/CD particular variables.

  • CI_REGISTRY_USER — The username to push containers/charts to the undertaking’s GitLab container/package deal registry. Solely out there if the container/package deal registry is enabled for the undertaking.
  • CI_REGISTRY_PASSWORD — The password to push containers/helm-charts to the undertaking’s GitLab container/package deal registry. Solely out there if the container/package deal registry is enabled for the undertaking.
  • CI_API_V4_URL — The GitLab API v4 root URL.
  • CI_PROJECT_ID — The ID of the present undertaking. This ID is exclusive throughout all tasks on the GitLab occasion.

You’ll find them right here for extra about GitLab CI/CD predefined variables.

We just do two actions within the script part: packaging and pushing. That two actions shall be completed by way of applicable instructions of the Helm. The helm package deal command packages a chart right into a versioned chart archive file, and the helm push command uploads a chart to a registry.

The final part is about when the GitLab job will set off. The solely.refs key phrase signifies that job shall be created in case of any decide to the principle department. The solely.modifications key phrase means the job shall be created and can routinely run when there are any modifications to the information contained in the example-chart listing.

Since we lined all particulars, it’s time to run our pipeline. For triggering the pipeline, we simply want to alter any of the information within the example-chart listing.

Elevating the chart model

As soon as we’ve efficiently dedicated our modifications, we are able to leap to CI/CD tab and see the standing of the job.

Triggered job helm-package

And at last, let’s verify the Helm chart, which has been pushed to the package deal registry underneath the 0.1.1 model.

example-chart saved on GitLab package deal registry

Now you understand how to make use of GitLab Bundle Registry as a Helm chart registry; it enables you to retailer, publish, and use the charts subsequent to your Kubernetes manifests.

Completely satisfied Helming!

Thanks for studying. I hope this story was useful. If you’re , try my other Medium articles.

More Posts