GitHub Action
Validate Flux Helm Release
This project is no longer maintained, helm-operator users should migrate to Flux v2 and helm-controller.
This GitHub action validates a Flux Helm Release Kubernetes custom resources with kubeval.
Steps:
- installs kubectl, yq, kubeval, helm v2 and v3
- extracts the chart source with yq
- downloads the chart from the Helm or Git repository
- extracts the Helm Release values with yq
- runs helm template for the extracted values
- validates the YAMLs using kubeval strict mode
Validate Helm release custom resources:
name: CI
on: [push, pull_request]
jobs:
hrval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Validate Helm Releases in test dir
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/
- name: Validate Helm Release from Helm Repo
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/flagger.yaml
helmVersion: v2
kubernetesVersion: 1.17.0
- name: Validate Helm Release from Git Repo
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/podinfo.yaml
helmVersion: v3
kubernetesVersion: master
ignoreValues: trueOutput:
Processing test/flagger.yaml
Downloading to /tmp/tmp.TuA4QzCOG7
Extracting values to /tmp/tmp.TuA4QzCOG7/flagger.values.yaml
Writing Helm release to /tmp/tmp.TuA4QzCOG7/flagger.release.yaml
Validating Helm release flagger.flagger-system against Kubernetes 1.16.0
WARN - Set to ignore missing schemas
PASS - flagger/templates/psp.yaml contains a valid PodSecurityPolicy
PASS - flagger/templates/psp.yaml contains a valid ClusterRole
PASS - flagger/templates/psp.yaml contains a valid RoleBinding
PASS - flagger/templates/account.yaml contains a valid ServiceAccount
WARN - flagger/templates/crd.yaml containing a CustomResourceDefinition was not validated against a schema
PASS - flagger/templates/prometheus.yaml contains a valid ClusterRole
PASS - flagger/templates/prometheus.yaml contains a valid ClusterRoleBinding
PASS - flagger/templates/prometheus.yaml contains a valid ServiceAccount
PASS - flagger/templates/prometheus.yaml contains a valid ConfigMap
PASS - flagger/templates/prometheus.yaml contains a valid Deployment
PASS - flagger/templates/prometheus.yaml contains a valid Service
PASS - flagger/templates/rbac.yaml contains a valid ClusterRole
PASS - flagger/templates/rbac.yaml contains a valid ClusterRoleBinding
PASS - flagger/templates/deployment.yaml contains a valid Deployment
To allow the action to be able to clone charts from private GitHub repositories,
you must create a GitHub private access token
and add it as a secret to the target repository. NOTE: secret names cannot start with GITHUB_ as these are reserved.
You can then pass the secret (in this case, GH_TOKEN) into the action like so:
name: CI
on: [push, pull_request]
jobs:
hrval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Validate Helm Releases in test dir
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/
env:
GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}Gitlab CI Token is also possible using GITLAB_CI_TOKEN.
If you set awsS3Repo: true, make sure you set the appropriate environment variables for helm s3 plugin to work. Example:
name: CI
on: [push, pull_request]
jobs:
hrval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Validate Helm Releases in test dir
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/
awsS3Repo: true
awsS3RepoName: example-s3-helm-repo
awsS3Plugin: https://github.com/hypnoglow/helm-s3.git
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_DEFAULT_REGION: "us-east-1"
To allow fetching Helm charts from private Helm chart repositories you need to
pass a list of Helm repositories in HTTP_PRIVATE_CHART_REPOS environment variable as JSON.
{
"repositories": [
{
"url": "https://raw.githubusercontent.com/username/helm-chart-repository/master/",
"username": "YOUR_USERNAME",
"password": "YOUR_PASSWORD"
},
{
"url": "https://raw.githubusercontent.com/username/another-helm-chart-repository/master/",
"username": "YOUR_USERNAME",
"password": "YOUR_PASSWORD"
}
]
}It should be passed as a secret to keep credentials secure.
name: CI
on: [push, pull_request]
jobs:
hrval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Validate Helm Releases in test dir
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/
env:
HTTP_PRIVATE_CHART_REPOS: ${{ secrets.HTTP_PRIVATE_CHART_REPOS }}If a base repository branch of pull request is referenced in helm release,
you need to pass HRVAL_BASE_BRANCH and HRVAL_HEAD_BRANCH environment variables
to an action to make sure it will check out amended version of the chart
from a head repository branch.
name: CI
on: [pull_request]
jobs:
hrval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Validate Helm Releases in test dir
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/
env:
HRVAL_BASE_BRANCH: ${{ github.base_ref }}
HRVAL_HEAD_BRANCH: ${{ github.head_ref }}Sometimes single Helm release might be referenced multiple times in a single Flux repository,
for example if staging branch of Helm chart repository is used as a release ref across all staging releases.
A property named helmSourcesCacheEnabled enables caching for such releases,
so a single Helm repository chart version or Git repository ref
will be retrieved only once, and cached version will be used for validation of another releases which reuse same sources.
name: CI
on: [pull_request]
jobs:
hrval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Validate Helm Releases in test dir
uses: stefanprodan/hrval-action@master
with:
helmRelease: test/
helmSourcesCacheEnabled: trueThe validation scripts can be used in any CI system.
CircleCI example:
version: 2.1
jobs:
hrval:
docker:
- image: stefanprodan/hrval:latest
steps:
- checkout
- run:
name: Validate Helm Releases in test dir
command: |
IGNORE_VALUES=false
KUBE_VER=master
HELM_VER=v2
hrval test/ $IGNORE_VALUES $KUBE_VER $HELM_VER