Skip to content

Latest commit

 

History

History
105 lines (75 loc) · 4.22 KB

releasing.md

File metadata and controls

105 lines (75 loc) · 4.22 KB

Releases

Release Steps

tl;dr Run: $ make release

Manual Steps

Overview:

  1. Create a new branch like release-ngrok-operator-<version>
  2. Update versions and changelogs
  3. Submit a PR to main
  4. Merge PR (triggers .github/workflows to publish the new release)

Determine:

  • The Helm Chart version: helm/ingress-operator/Chart.yaml
  • The ngrok-op App version: VERSION

Steps:

  • App Version Bump
    1. Update VERSION to new version
    2. Write a new section in CHANGELOG
      • Note: Use the expected tag ngrok-operator-<VERSION> for the full changelog (this tag will be created for you when your release PR is merged)
      • Note: Find the new commits using a link, such as https://github.com/ngrok/ngrok-operator/compare/ngrok-operator-<version>...main
  • Helm Chart Version Bump
    1. Update version to new version
    2. Update the appVersion to the desired VERSION
    3. Write a new section in CHANGELOG
    4. Run $ make helm-update-snapshots helm-test

Artifacts

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

Docker Image

The Docker image contains the ngrok Ingress Controller 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 and can be installed by following the instructions in the chart's README.

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 1.2.0 of the helm chart will have a git tag of helm-chart-1.2.0 which contains the code used to package and publish version 1.2.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.

Controller

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

When changes that would affect the controller's docker image are pushed to main, a github workflow will trigger. The workflow will build and publish the ngrok/ngrok-operator:latest docker image.

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