Helm Action

Deploys a helm chart using GitHub actions. Supports canary deployments and provides a built in helm chart for apps that listen over http to get your ramped up quickly.

View an example repository using this action at github.com/deliverybot/example-helm.

Parameters

Inputs

Inputs below are additionally loaded from the payload of the deployment event payload if the action was triggered by a deployment.

• release: Helm release name. Will be combined with track if set. (required)
• namespace: Kubernetes namespace name. (required)
• chart: Helm chart path. If set to "app" this will use the built in helm chart found in this repository. (required)
• chart-version: The version of the helm chart you want to deploy (distinct from app version)
• values: Helm chart values, expected to be a YAML or JSON string.
• track: Track for the deployment. If the track is not "stable" it activates the canary workflow described below.
• task: Task name. If the task is "remove" it will remove the configured helm release.
• dry-run: Helm dry-run option.
• token: Github repository token. If included and the event is a deployment then the deployment_status event will be fired.
• value-files: Additional value files to apply to the helm chart. Expects a JSON encoded array or a string.
• secrets: Secret variables to include in value file interpolation. Expects a JSON encoded map.
• helm: Helm binary to execute, one of: [helm, helm3].
• version: Version of the app, usually commit sha works here.
• timeout: specify a timeout for helm deployment
• repo: Helm chart repository to be added.
• repo-alias: Helm repository alias that will be used.
• repo-username: Helm repository username if authentication is needed.
• repo-password: Helm repository password if authentication is needed.
• atomic: If true, upgrade process rolls back changes made in case of failed upgrade. Defaults to true.

Additional parameters: If the action is being triggered by a deployment event and the task parameter in the deployment event is set to "remove" then this action will execute a helm delete $service

Versions

• helm: v2.17.0
• helm3: v3.8.1

Environment

• KUBECONFIG_FILE: Kubeconfig file for Kubernetes cluster access.

Value file interpolation

The following syntax allows variables to be used in value files:

• ${{ secrets.KEY }}: References secret variables passed in the secrets input.
• ${{ deployment }}: References the deployment event that triggered this action.

Example

# .github/workflows/deploy.yml
name: Deploy
on: ['deployment']

jobs:
  deployment:
    runs-on: 'ubuntu-latest'
    steps:
    - uses: actions/checkout@v1

    - name: 'Deploy'
      uses: 'deliverybot/helm@v1'
      with:
        release: 'nginx'
        namespace: 'default'
        chart: 'app'
        token: '${{ github.token }}'
        values: |
          name: foobar
        value-files: >-
        [
          "values.yaml", 
          "values.production.yaml"
        ]
      env:
        KUBECONFIG_FILE: '${{ secrets.KUBECONFIG }}'

Example canary

If a track is chosen that is equal to canary, this updates the helm chart in a few ways:

1. Release name is changed to {release}-{track} (eg. myapp-canary).
2. The service is disabled on the helm chart service.enabled=false
3. The ingress is disabled on the helm chart ingress.enabled=false

Not enabling the service or ingress allows the stable ingress and service resources to pick up the canary pods and route traffic to them.

# .github/workflows/deploy.yml
name: Deploy
on: ['deployment']

jobs:
  deployment:
    runs-on: 'ubuntu-latest'
    steps:
    - uses: actions/checkout@v1

    - name: 'Deploy'
      uses: 'deliverybot/helm@v1'
      with:
        release: 'nginx'
        track: canary
        namespace: 'default'
        chart: 'app'
        token: '${{ github.token }}'
        values: |
          name: foobar
      env:
        KUBECONFIG_FILE: '${{ secrets.KUBECONFIG }}'

Example pr cleanup

If you are creating an environment per pull request with Helm you may have the issue where pull request environments like pr123 sit around in your cluster. By using GitHub actions we can clean those up by listening for pull request close events.

# .github/workflows/pr-cleanup.yml
name: PRCleanup
on:
  pull_request:
    types: [closed]

jobs:
  deployment:
    runs-on: 'ubuntu-latest'
    steps:
    - name: 'Deploy'
      uses: 'deliverybot/helm@v1'
      with:
        # Task remove means to remove the helm release.
        task: 'remove'
        release: 'review-myapp-${{ github.event.pull_request.number }}'
        version: '${{ github.sha }}'
        track: 'stable'
        chart: 'app'
        namespace: 'example-helm'
        token: '${{ github.token }}'
      env:
        KUBECONFIG_FILE: '${{ secrets.KUBECONFIG }}'

Example add custom repository

Sometime you may want to add a custom repository, like chartmuseum. For th

# .github/workflows/pr-cleanup.yml
name: PRCleanup
on:
  pull_request:
    types: [closed]

jobs:
  deployment:
    runs-on: 'ubuntu-latest'
    steps:
    - name: 'Deploy'
      uses: 'deliverybot/helm@v1'
      with:
        release: 'nginx'
        namespace: 'default'
        chart: 'chartmuseum/app'
        token: '${{ github.token }}'
        repo: 'http://chartmuseum.example.com'
        repo-alias: chartmuseum
        repo-username: ${{ secrets.CHARTMUSEUM_USERNAME }}
        repo-password: ${{ secrets.CHARTMUSEUM_PASSWORD }}
      env:
        KUBECONFIG_FILE: '${{ secrets.KUBECONFIG }}'