Merge pull request #3227 from tstromberg/better_release_docs
Update release docs to reflect the state in 2018 (Jenkins!)pull/3268/head
Thomas Strömberg
GitHub
commit
07e7a1eef3
|
|
@ -1,89 +1,80 @@
|
|||
# Steps to Release Minikube
|
||||
|
||||
## Create a Release Notes PR
|
||||
## Build a new ISO
|
||||
|
||||
Collect the release notes, and edit them as necessary:
|
||||
You only need to build the minikube ISO when the there are changes in the `deploy/iso` folder.
|
||||
Note: you can build the ISO using the `hack/jenkins/build_iso.sh` script locally.
|
||||
|
||||
* navigate to the minikube ISO jenkins job
|
||||
* Ensure that you are logged in (top right)
|
||||
* For `ISO_VERSION`, type in the intended release version (same as the minikube binary's version)
|
||||
* For `ISO_BUCKET`, type in `minikube/iso`
|
||||
* Click *Build*
|
||||
|
||||
The build will take roughly 50 minutes.
|
||||
|
||||
## Update Makefile
|
||||
|
||||
Edit the minikube `Makefile`, updating the version number values at the top:
|
||||
|
||||
* `VERSION_MINOR` (and `VERSION_MAJOR`, `VERSION_BUILD` as necessary)
|
||||
* `ISO_VERSION` (only update this if there is a new ISO release)
|
||||
|
||||
## Run Local Integration Test
|
||||
|
||||
With the updated Makefile, run the integration tests and ensure that all tests pass:
|
||||
|
||||
```shell
|
||||
hack/release_notes.sh
|
||||
env TEST_ARGS="-minikube-start-args=--vm-driver=kvm2" make integration
|
||||
```
|
||||
|
||||
Then merge into the CHANGELOG.md file. See [this PR](https://github.com/kubernetes/minikube/pull/164) for an example.
|
||||
## Ad-Hoc testing of other platforms
|
||||
|
||||
## Build and Release a New ISO
|
||||
|
||||
This step isn't always required. Check if there were changes in the deploy directory.
|
||||
If you do this, bump the ISO URL to point to the new ISO, and send a PR.
|
||||
To do this, build the new ISO by running:
|
||||
```shell
|
||||
deploy/iso/build.sh
|
||||
```
|
||||
This will generate a new ISO at 'deploy/iso/minikube.iso'. Then upload the ISO and shasum using the following command:
|
||||
```shell
|
||||
gsutil cp deploy/iso/minikube.iso gs://minikube/minikube-<increment.version>.iso
|
||||
gsutil cp deploy/iso/minikube.iso.sha256 gs://minikube/minikube-<increment.version>.iso.sha256
|
||||
```
|
||||
|
||||
## Run integration tests
|
||||
|
||||
Run this command:
|
||||
```shell
|
||||
make integration
|
||||
```
|
||||
Investigate and fix any failures.
|
||||
|
||||
## Bump the version in the Makefile and Update Docs to reflect this
|
||||
|
||||
See [this PR](https://github.com/kubernetes/minikube/pull/165) for an example.
|
||||
|
||||
##Send an initial commit with the Makefile change:
|
||||
|
||||
Send a PR for the Makefile change and wait until it is merged. Once the commit is merged, continue.
|
||||
|
||||
## Build the Release
|
||||
|
||||
Run this command:
|
||||
If there are supported platforms which do not have functioning Jenkins workers (Windows), you may use the following to build a sanity check:
|
||||
|
||||
```shell
|
||||
BUILD_IN_DOCKER=y make cross checksum
|
||||
```
|
||||
|
||||
## Add the version to the releases.json file
|
||||
## Send out Makefile PR
|
||||
|
||||
Add an entry **to the top** of deploy/minikube/releases.json with the **version** and **checksums**.
|
||||
Send a PR.
|
||||
This file controls the auto update notifications in minikube.
|
||||
Only add entries to this file that should be released to all users (no pre-release, alpha or beta releases).
|
||||
The file must be uploaded to GCS before notifications will go out. That step comes at the end.
|
||||
This will update users of HEAD to the new ISO.
|
||||
|
||||
The schema for this file can be found in deploy/minikube/schema.json.
|
||||
Please pay attention to test failures, as this is our integration test across platforms. If there are known acceptable failures, please add a PR comment linking to the appropriate issue.
|
||||
|
||||
An automated test to verify the schema runs in Travis before each submit.
|
||||
## Update Release Notes
|
||||
|
||||
## Upload to GCS:
|
||||
Run the following script to update the release notes:
|
||||
|
||||
```shell
|
||||
gsutil cp out/minikube-linux-amd64 gs://minikube/releases/$RELEASE/
|
||||
gsutil cp out/minikube-linux-amd64.sha256 gs://minikube/releases/$RELEASE/
|
||||
gsutil cp out/minikube-darwin-amd64 gs://minikube/releases/$RELEASE/
|
||||
gsutil cp out/minikube-darwin-amd64.sha256 gs://minikube/releases/$RELEASE/
|
||||
gsutil cp out/minikube-windows-amd64.exe gs://minikube/releases/$RELEASE/
|
||||
gsutil cp out/minikube-windows-amd64.exe.sha256 gs://minikube/releases/$RELEASE/
|
||||
hack/release_notes.sh
|
||||
```
|
||||
|
||||
Merge the output into CHANGELOG.md. See [PR#3175](https://github.com/kubernetes/minikube/pull/3175) as an example. Then get the PR submitted.
|
||||
|
||||
## Tag the Release
|
||||
|
||||
Run a command like this to tag it locally: `git tag -a v0.2.0 -m "0.2.0 Release"`.
|
||||
Run a command like this to tag it locally: `git tag -a v<version> -m "<version> Release"`.
|
||||
|
||||
And run a command like this to push the tag: `git push upstream v0.2.0`.
|
||||
And run a command like this to push the tag: `git push upstream v<version>`.
|
||||
|
||||
## Create a Release in Github
|
||||
## Build the Release
|
||||
|
||||
Create a new release based on your tag, like [this one](https://github.com/kubernetes/minikube/releases/tag/v0.2.0).
|
||||
This step uses the git tag to publish new binaries to GCS and create a github release:
|
||||
|
||||
Upload the files, and calculated checksums.
|
||||
* navigate to the minikube "Release" jenkins job
|
||||
* Ensure that you are logged in (top right)
|
||||
* `VERSION_MAJOR`, `VERSION_MINOR`, and `VERSION_BUILD` should reflect the values in your Makefile
|
||||
* For `ISO_SHA256`, run: `gsutil cat gs://minikube/iso/minikube-v<version>.iso.sha256
|
||||
* Click *Build*
|
||||
|
||||
## Upload the releases.json file to GCS
|
||||
## Update releases.json
|
||||
|
||||
minikube-bot will send out a PR to update the release checksums at the top of `deploy/minikube/releases.json`. Make sure it is submitted, or hack one together yourself.
|
||||
|
||||
This file is used for auto-update notifications, but is not active until releases.json is copied to GCS.
|
||||
|
||||
## Upload releases.json to GCS
|
||||
|
||||
This step makes the new release trigger update notifications in old versions of Minikube.
|
||||
Use this command from a clean git repo:
|
||||
|
|
@ -95,7 +86,7 @@ gsutil cp deploy/minikube/releases.json gs://minikube/releases.json
|
|||
## Mark the release as `latest` in GCS:
|
||||
|
||||
```shell
|
||||
gsutil cp -r gs://minikube/releases/$RELEASE/* gs://minikube/releases/latest/
|
||||
gsutil cp -r 'gs://minikube/releases/$RELEASE/*' gs://minikube/releases/latest/
|
||||
```
|
||||
|
||||
## Package managers which include minikube
|
||||
|
|
@ -116,11 +107,11 @@ The repository is tracked in this repo under a submodule `installers/linux/arch_
|
|||
|
||||
To actually update the package, you should bump the version and update the sha512 checksum. You should also run `makepkg --printsrcinfo > .SRCINFO` to update the srcinfo file. You can edit this manually if you don't have `makepkg` on your machine.
|
||||
|
||||
## Release Verification
|
||||
## Verification
|
||||
|
||||
After you've finished the release, run this command from the release commit to verify the release was done correctly:
|
||||
`make check-release`.
|
||||
|
||||
## Update kubernetes.io docs
|
||||
|
||||
If there are major changes, please send a PR upstream for this file https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/getting-started-guides/minikube.md in order to keep the getting started guide up to date.
|
||||
If there are major changes, please send a PR to update the official setup guide: [Running Kubernetes Locally via Minikube](https://kubernetes.io/docs/setup/minikube/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue