Skip to main content

ngrok Kubernetes Operator Release Process

Artifacts​

The ngrok kubernetes operator has 2 main artifacts, a docker image and a helm chart. While the helm chart is the recommended way to install the operator, the docker image can be used to run the operator in a Kubernetes cluster without helm.

Docker Image​

The Docker image contains the ngrok Kubernetes operator binary and is available on Docker Hub here. We currently support amd64 and arm64 architectures, with future plans to build for other architectures.

Helm Chart​

The helm chart is packaged and published to its own helm repository

Semantic Versioning​

This project uses semantic versioning for both the the docker image and helm chart.

From the semver spec:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

That said, we will treat changes in "y" as major releases and changes in "z" as minor releases until version 1.0 is reached.

Release Process​

The Docker Image and Helm chart are released independently since a feature or bug fix in one may not require a release in the other. Sometimes a change will require a version bump and release in both.

Tagging​

There is a different git tag pattern for each artifact.

Helm Chart​

Releases of the helm chart will be tagged with a prefix of helm-chart-. For example, version 0.17.0 of the helm chart will have a git tag of helm-chart-0.17.0 which contains the code used to package and publish version 0.17.0 of the helm chart.

When changes are made to the helm chart's Chart.yaml file, a github workflow will trigger upon merging the PR to the main branch. The workflow will package and publish the helm chart for consumption. The workflow will also create a git tag as described above.

When changing version in the helm chart's Chart.yaml file, the version should be bumped according to the semantic versioning spec as described above.

Operator​

Releases of the operator will be tagged with a prefix of ngrok-operator-. For example, version 0.15.0 of the docker image will have a git tag of ngrok-operator-0.15.0 which contains the code used to build the docker image ngrok/ngrok-operator:0.15.0.

When changes that would affect the operator's docker image are pushed to main, a github workflow will trigger. The workflow will build and publish the docker image with the versioned tag.

If the VERSION file at the root of the repo is changed, the workflow will also create a git tag for the operator as described above and publish a tagged docker image. For instance when the VERSION is changed to 0.15.0, the workflow will create a git tag of ngrok-operator-0.15.0 and publish the docker image ngrok/ngrok-operator:0.15.0.