Weave GitOps Automation for Helm and GitHub Actions

June 23, 2022

The latest release of Weave GitOps enhances automation for Helm and GitHub actions.

Related posts

What is the Enterprise Market Perspective of GitOps?

Getting Started With Weave GitOps

Weave Policy Library: Introducing HIPAA Policies

Weaveworks donated Flux to the CNCF and still plays a significant role in its continued development and maintenance. Flux and Flagger are core components of the Weave GitOps solution.

Weave GitOps is powered by Flux therefore new Flux features are also available in Weave GitOps. Flux recently released 0.31.0 with some exciting new features, check them out below.

Helm OCI Registries

With the release of Helm 3.8.0, Charts can be stored in OCI registries, just like Docker images. Sharing common storage across technologies results in lower maintenance overhead for your DevOps team. There’s no longer a requirement to host your Helm Charts on a web server, just use your existing container image registry.

Publishing a Helm Chart to a OCI registry is easy, it’s just like a Docker image.

$ helm push == docker push

To install a chart from a registry.

$ helm install myapp oci://registry.acme.com/helm-charts/myapp –version 1.0.0

With the latest release of Flux, OCI registries are supported for the HelmRepository resource.

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: myrepo
  namespace: flux-system
spec:
  type: oci
  interval: 30m
  url: oci://registry.acme.com/helm-charts

Once the Helm OCI chart registry has been defined, a Helm Chart release is defined using the registry.

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: myapp
  namespace: flux-system
spec:
  chart:
    spec:
      sourceRef:
        kind: HelmRepository
        name: myrepo
      chart: myapp
      version: ‘1.0.x’
  interval: 30m
  targetNamespace: mynamespace

Flux supports the use of semver for Helm Chart versions. With the above manifest, Flux will check the registry every 30 minutes and install the latest version matching the semver. For example, if version 1.0.3 is currently installed then version 1.0.6 is pushed to the registry it will be automatically installed. Flux automation means that your CI/CD pipelines are less complex and easier to maintain.

Trigger GitHub Actions

The Flux Notification Controller already has a rich set of integrations such as: Slack, MS Teams, Google Chat, generic webhook, etc. The latest release of Flux adds a new integration to GitHub Actions, which will trigger an action with a repository_dispatch event.

To configure the new Provider, you’ll need a GitHub personal access token stored in a Kubernetes Secret.

$ kubectl create secret generic github-token \
    –from-literal=token=$GITHUB_TOKEN

An example Provider manifest:

apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: github-displatch
  namespace: flux-system
spec:
  type: githubdispatch
  address: https://github.com/steveww/pypodinfo
  secretRef:
    name: github-token

Configure an Alert to send events to the Provider:

apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: github-dispatch
  namespace: flux-system
spec:
  summary: “staging eu-west-2”
  providerRef:
    name: github-dispatch
  eventSeverity: info
  eventSources:
kind: Kustomization
name: pypodinfo

Finally you’ll need to define an action in your repository that will be triggered:

name: flux-githubdispatch
on:
  repository_dispatch:
    types: [Kustomization/pypodinfo.flux-system]
jobs:
  run-tests:
    if: github.event.client_payload.metadata.summary == ‘staging eu-west-2’
    runs-on: ubuntu-latest
    steps:
name: Run Tests
run: echo “Starting tests”

With the above example configuration, when a reconciliation happens for the pypodinfo Kustomization, the Alert will send the event to GitHub via the repository_dispatch event type. Notice that the summary field from the Alert is passed in the client metadata and can be referenced in the GitHub Action.

The uses of this new functionality are only limited by your imagination. One example is to prove an automatic rollback of a change if it fails. We can all make a typo that can also be easily missed during review and approval. A typo could cause the deployment of the change to fail. Using the Flux notification to call a GitHub Action, which would then check the status of the application component, detecting the failure and then reverting the commit. The previous good configuration would then be applied to the cluster. Additionally it could go on to create an Issue or Pull Request to notify of the failure. If the change was deployed successfully the action could run a number of tests which, if successful, would create a pull request for promotion to production deployment. The status of all application components is easy to see with Weave GitOps, both the dashboard and the VS Code plugin provide status information for all Flux components.

Weave_GitOps_Automation_for_Helm_and_GitHub_Actions.png

I’m sure there are many other use cases, why not install Weave GitOps on your cluster and have a play?


Related posts

What is the Enterprise Market Perspective of GitOps?

Getting Started With Weave GitOps

Weave Policy Library: Introducing HIPAA Policies

Whitepaper: How GitOps Enables A Continuous Application Lifecycle

Discover what you need to start building a GitOps pipeline today.

Download your Copy