Releasing Minishift

Overview

The following sections describe how to release Minishift either via automated job or manually.

Preparing the GitHub Milestone

  1. Verify the milestone you want to release:

    • Move remaining open issues into the next milestone.

    • Review resolved/closed issues and make sure they are classified correctly.

    • Check and update the resolution of the issues. For example, issues with merged pull requests should be labeled as resolution/done.

  1. Close the milestone.

Automated Release

An automated release can be performed by triggering CI job as:

  1. $ make ci_release API_KEY=<api-key> RELEASE_VERSION=<version>

where

  • api-key : Minishift CentOS CI API key

  • version : The expected release version (without ‘v’). For example, 1.0.0.

Once triggered you can follow the release process here.

The automated release performs:

If the CI release job is failing for a known reason then you can skip the integration tests by changing the SKIP_INTEGRATION_TEST value to true in Makefile.

The systemtray bits needs to uploaded separately, which can be performed by triggering CI job as:

  1. $ make ci_release_systemtray CIRCLECI_API_KEY=<api-key> RELEASE_VERSION=<version>

where

  • api-key : Minishift Circle CI API key

  • version : The expected release version (without ‘v’). For example, 1.0.0.

Manual Release

Prerequisites

  • You must have a GitHub personal access token defined in your environment as GITHUB_ACCESS_TOKEN.

  • You must set environment variable GITHUB_USER as minishift.

  • To create the systemtray binaries, Xcode must be installed.

Cutting the Release

  1. Run the required checks:

    1. $ make prerelease

  2. Bump the Minishift version in the Makefile.

  3. Commit and push your changes with a message of the form cut v1.0.0.

  4. Create binaries and upload them to GitHub (this will also tag the release):

    1. $ make release

Triggering the Documentation Build

Use the following to trigger the documentation build:

  1. $ export API_KEY=<api-key>
  2. $ curl -H "$(curl --user minishift:$API_KEY 'https://ci.centos.org//crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)')" -X POST https://ci.centos.org/job/minishift-docs/build --user "minishift:$API_KEY"

This will build minishift-adoc.tar, which will be consumed by docs.okd.io during the next nightly build. For more information, see Writing and Publishing Minishift Documentation.

Post-Release Tasks

The systemtray bits also needs to be uploaded to the release in Github. Create Minishift binaries with systemtray and upload them to Github. The following command works only in macOS, please refer the Prerequisites for more information.

  1. $ make release_systemtray

As part of the release process we also send a release announcement and edit the GitHub release page.

For the latter we usually add a categorized list of closed issues as well as some release highlights (most often taken from the release announcement).

If you have jq installed on your machine, you can use the issue-list.sh script to generate the Markdown needed for adding the issue list. For example:

  1. $ cd scripts/release
  2. $ ./issue-list.sh -r minishift -m 9

Updating the brew cask

To update the Minishift cask manually, we need to do the following tasks:

  1. Fork the homebrew-cask repository and clone it locally if not already done.

  2. Update the minishift.rb file with latest version, sha256sum and checkpoint.

  3. Push the changes to the forked repository.

  4. And finally open a pull request in the homebrew-cask repository.

You can also use the brew-cask.sh script to update minishift.rb with latest version information. For example:

  1. $ cd scripts/release
  2. $ ./brew-cask.sh -r /path/to/homebrew-cask-repo -v 1.13.0