Skip to content

Latest commit

 

History

History
154 lines (112 loc) · 5.84 KB

release_setup.md

File metadata and controls

154 lines (112 loc) · 5.84 KB

Automating releases for a new Knative repository

Note: Throughout this document, MODULE is a Knative module name, e.g. serving or eventing.

By using the release automation already in place, a new Knative repository can get nightly and official releases with little effort. All automated releases are monitored through TestGrid.

  • Nightly releases are built every night between 2AM and 3 AM (PST), from HEAD on the default branch. They are referenced by a date/commit label, in the form vYYYYMMDD-<commit_short_hash>. The job status can be checked in the nightly tab in the corresponding repository dashboard in TestGrid. Images are published to the gcr.io/knative-nightly/MODULE registry and manifests to the knative-nightly/MODULE GCS bucket.

  • Versioned releases are usually built against a branch in the repository. They are referenced by a vX.Y.Z label, and published in the Releases page of the repository. Images are published to the gcr.io/knative-release/MODULE registry and manifests to the knative-releases/MODULE GCS bucket.

Versioned releases can be one of two kinds:

  • Major or minor releases are those with changes to the X or Y values in the version. They are cut only when a new release branch (which must be named release-X.Y) is created from the default branch of a repository. Within about 2 to 3 hours the new release will be built and published. The job status can be checked in the auto-release tab in the corresponding repository dashboard in TestGrid. The release notes published to GitHub are empty, so you must manually edit it and add the relevant markdown content.

  • Patch or dot releases are those with changes to the Z value in the version. They are cut automatically, every Tuesday night between 2AM and 3AM (PST). For example, if the latest release on release branch release-0.2 is v0.2.1, the next minor release will be named v0.2.2. A minor release is only created if there are new commits to the latest release branch of a repository. The job status can be checked in the dot-release tab in the corresponding repository dashboard in TestGrid. The release notes published to GitHub are a copy of the previous release notes, so you must manually edit it and adjust its content.

Setting up automated releases

  1. Have the /test/presubmit-tests.sh script added to your repo, as it's used as a release gateway. Alternatively, have some sort of validation and set $VALIDATION_TESTS in your release script (see below).

  2. Write your release script, which will publish your artifacts. For details, see the helper script documentation.

  3. Enable nightly, auto-release and dot-release jobs for your repo in the jobs_config file.

  4. Run ./hack/generate-configs.sh to regenerate config.yaml, otherwise the presubmit test will fail. Merge such pull request, within two hours the 3 new jobs (nightly, auto-release and dot-release) will appear on TestGrid.

    The jobs can also be found in the Prow status page under the names ci-knative-MODULE-nightly-release, ci-knative-MODULE-auto-release and ci-knative-MODULE-dot-release.

Creating a major version release

Starting the release from the GitHub UI

  1. Click the Branch dropdown.
  2. Type the desired release-X.Y branch name into the search box.
  3. Click the Create branch: release-X.Y from 'main' button. You must have write permissions to the repo to create a branch.

Starting the release from the Git CLI

  1. Fetch the upstream remote.

    git fetch upstream

  2. Create a release-X.Y branch from upstream/main.

    git branch --no-track release-X.Y upstream/main

  3. Push the branch to upstream.

    git push upstream release-X.Y

    You must have write permissions to the repo to create a branch.

Finishing the release

Within 2 hours, Prow will detect the new release branch and run the hack/release.sh script. If the build succeeds, a new tag vX.Y.0 will be created and a GitHub release published. If the build fails, logs can be retrieved from https://testgrid.knative.dev/MODULE#auto-release.

Write release notes and add them to the release at https://github.com/knative/MODULE/releases.

Adding a commit to the next minor version release

  1. Fetch the upstream remote.

    git fetch upstream

  2. Create a branch based on the desired (usually the latest) release-X.Y branch.

    git checkout -b my-backport-branch upstream/release-X.Y

  3. Cherry-pick desired commits from main into the new branch.

    git cherry-pick <commitid>

  4. Push the branch to your fork.

    git push origin

  5. Create a PR for your branch based on the release-X.Y branch.

  6. Once the PR is merged, it will be included in the next minor release, which is usually built Tuesday nights, between 2AM and 3AM.

Note: If a minor release is required for a release branch that's not the latest, the job must be started manually.

Finishing a minor release

When the minor release job runs, it will detect the new commits in the latest release branch and run the release.sh script. If the build succeeds, a new tag vX.Y.Z will be created (where Z is the current minor version number + 1) and a GitHub release published at https://github.com/knative/MODULE/releases. If the build fails, logs can be retrieved from https://testgrid.knative.dev/MODULE#dot-release.

Write release notes and add them to the release at https://github.com/knative/MODULE/releases.