Trigger Pipelines on New Helm Chart

Updated 2 days ago by Michael Cretzman

You can trigger Harness Pipelines in response to a new Helm chart version being added to an HTTP Helm repo.

For example, every time a new Helm chart is pushed to an HTTP Helm repo, it triggers a CD Pipeline that deploys it automatically.

Helm Chart Triggers simply listen to the repo where one or more of the Helm charts in your Pipeline are hosted.

You can set conditions on the Triggers, such as matching one or more chart versions.

This Trigger is a simple way to automate deployments for new Helm charts.

In this topic:

Before You Begin

  • You should be familiar with Harness CD Pipelines for Helm charts, such as the one you create in the Helm CD Quickstart.

Limitations

You can only use a Helm Chart Trigger if you have added Helm chart in the Stage's Service Definition, and the Chart Version setting in the HTTP Helm chart details in a Runtime Input (<+input>).

Here's the Helm Chart in the Stage's Service Definition:

And here is the Chart Version setting in the HTTP Helm store:

If the Chart Version is not a Runtime Input, you will not be able to select the Helm chart in the Helm Chart Trigger.

Visual Summary

This 4min video walks you through building a new Helm chart version and pushing it to Nexus using curl, and then having an On New Helm Chart Trigger execute a CD Pipeline to deploy the new version automatically.

Review: Chart Polling

Once you have created a Trigger to listen for new Helm chart versions, Harness will poll for new charts continuously.

Polling is immediate because Harness uses a perpetual task framework that constantly monitors for new versions.

Input Sets and Artifacts

When you create a Trigger, you can select Input Sets to apply to the Pipeline when the Trigger is executed.

If the Input Set you select has a Fixed Value for Chart Version (for example, 0.1.4), the Trigger will work, but it will not select the new chart version. Instead, Harness will select the chart version with the Chart Version value in the Input Set (0.1.4).

Instead, in the Input Set's Chart Version setting, use the expression <+trigger.manifest.build>.

The Input Set option is for settings other than the Chart Version setting of the chart you want to pull. For example, the Artifact Server.

Step 1: Create Trigger

Select a Harness Pipeline that includes a Helm Chart in the Stage's Service Definition.

See Helm CD Quickstart for details on adding Helm Charts to a Stage's Service Definition.

Click Triggers.

Click New Trigger.

Click the Helm Chart Trigger listed under Manifest.

In Configuration, in Name, enter a name for the Trigger.

Step 2: Select Helm Chart

In Listen on New Artifact, click Select Manifest. If this setting is not enabled, it is because the Chart Version setting is not a Runtime Input (<+input>).

In Select a Manifest Reference, select the Helm chart for this Trigger to listen for and click Select.

In Configure Manifest Runtime Inputs, provide values for any Runtime inputs you have in your Helm Chart settings, and click Apply. The Helm chart listener is added:

Click Continue.

Step 3: Set Conditions

In Conditions, enter any conditions that must be matched in order for the Trigger to execute. For example, the Helm version number.

Regex and Wildcards

You can use wildcards in the condition's value and you can select Regex.

For example, if the build is todolist-v2.0:

  • With Regex not selected, both todolist* or *olist* will match.
  • With Regex selected, the regex todolist-v\d.\d will match.

If the regex expression does not result in a match, Harness ignores the value.

Harness supports standard Java regex. For example, if Regex is enabled and the intent is to match filename, the wildcard should be .* instead of simply a wildcard *. If you wanted to match all of the files that end in -DEV.tgz you would enter .*-DEV\.tgz.

Step 4: Select Pipeline Inputs

If your Pipeline uses Input Sets, you can select the Input Set to use when the Trigger executes the Pipeline.

For example, here's an Input Set:

The <+trigger.manifest.build> is used for Chart Version to ensure that the new chart version that executed the Trigger is used for the deployment.

If you use a Fixed Value for Chart Version (for example, 0.1.2), the Trigger will work when a new chart appears, but it will not select the new chart version. Instead, Harness will select the version with the Chart Version value in the Input Set (0.1.2).

The Input Set option is for settings other than the Chart Version setting. For example, the Artifact Server.

Step 5: Test Trigger

Once your Trigger is set up, click Create Trigger. The new Trigger is listed.

Once the Pipeline is executed using the Trigger, in Deployments, you can see the Trigger and the user who initiated the deployment.

If you look at the Trigger in your Pipeline again you can see its activation records:

And these records are also in the Trigger details:

You can test the Trigger by pushing a new chart version to your Helm Chart registry.

You can build and push to your registry using Harness CIE. See CI Pipeline Quickstart.

Here's a simple curl example using a Nexus repo that works as a Helm chart HTTP server.

Add repo:

helm repo add nexus_http https://nexus3.dev.example.io/repository/<repo_name>/ --username '<username>' --password '<password>'

Fetch chart:

helm fetch nexus_http/<chart_name>

Next, update the version in your chart.

Package the chart:

helm package <filename>

Push the new version to the Helm HTTP Server:

curl -u <username>:<password> https://nexus3.dev.example.io/repository/<repo_name>/ --upload-file <chart_name>-<chart_version>.tgz -v

Now your Helm chart HTTP server should have the new version of the Helm chart.

Here's a simple CD Pipeline that deploys that new version to a Kubernetes cluster. You'll have to replace the Project name and the <+input> Runtime Input for some settings with your own Connectors and credentials.

CD Pipeline YAML
pipeline:
name: On Manifest Changes
identifier: On_Manifest_Changes
projectIdentifier: CD_Examples
orgIdentifier: default
tags: {}
stages:
- stage:
name: Deploy
identifier: Deploy
description: ""
type: Deployment
spec:
serviceConfig:
serviceRef: helmchart
serviceDefinition:
type: Kubernetes
spec:
variables: []
manifests:
- manifest:
identifier: helmtest
type: HelmChart
spec:
store:
type: Http
spec:
connectorRef: <+input>
chartName: <+input>
chartVersion: <+input>
helmVersion: V3
skipResourceVersioning: false
infrastructure:
infrastructureDefinition:
type: KubernetesDirect
spec:
connectorRef: <+input>
namespace: default
releaseName: release-<+INFRA_KEY>
allowSimultaneousDeployments: false
environmentRef: helmtest
execution:
steps:
- step:
name: Rollout Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec: {}
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback

Finally here's the Trigger in the CD Pipeline that executes the Pipeline when a new chart version is pushed to the repo. You'll have to replace the Project name and the <+input> Runtime Input for some settings with your own Connectors and credentials.

CD Pipeline Trigger YAML
trigger:
name: Chart Trigger
identifier: Chart_Trigger
enabled: true
orgIdentifier: default
projectIdentifier: CD_Examples
pipelineIdentifier: On_Manifest_Changes
source:
type: Manifest
spec:
stageIdentifier: Deploy
manifestRef: helmtest
type: HelmChart
spec:
store:
type: Http
spec:
connectorRef: <+input>
chartName: +input>
chartVersion: <+trigger.manifest.version>
helmVersion: V3
skipResourceVersioning: false
inputYaml: |
pipeline:
identifier: On_Manifest_Changes
stages:
- stage:
identifier: Deploy
type: Deployment
spec:
serviceConfig:
serviceDefinition:
type: Kubernetes
spec:
manifests:
- manifest:
identifier: +input>
type: HelmChart
spec:
store:
type: Http
spec:
connectorRef: <+input>
chartName: todolist
chartVersion: <+trigger.manifest.version>
helmVersion: V3
skipResourceVersioning: false
properties:
ci:
codebase:
build:
type: branch
spec:
branch: <+trigger.branch>

Option: Enable or Disable Trigger

You can enable or disable Triggers using the Enabled toggle:

Option: Reuse Trigger YAML to Create New Triggers

You can reuse Triggers by copying and pasting Trigger YAML. This can be helpful when you have advanced Conditions you don't want to set up each time.

See Also


Please Provide Feedback