|
1 | 1 | # Steps to create a new release |
2 | 2 |
|
3 | | -## Step 0: Review the Release Milestone |
4 | | - |
5 | | -If the release you plan to create corresponds with an existing [milestone](https://github.com/operator-framework/operator-lifecycle-manager/milestones/), make sure that all features have been committed. If a feature will not be added to the release be sure to remove it from the milestone. |
6 | | - |
7 | | -## Step 1: Installing Requirements |
| 3 | +The OLM project uses [GoReleaser](https://goreleaser.com/) to automatically produce multi-arch container images and release artifacts during the release process. |
8 | 4 |
|
9 | | -Ensure you have `autoconf`, `automake`, and `libtool` installed. |
10 | | - |
11 | | -The following command can be used to install these packages on Fedora: |
12 | | - |
13 | | -```bash |
14 | | -dnf install autoconf automake libtool |
15 | | -``` |
| 5 | +In order to create a new minor version release, simply create a new tag locally, push that tag up to the upstream repository remote, and let automation handle the rest. |
16 | 6 |
|
17 | | -## Step 2: Verify Manifests |
| 7 | +The release automation will be responsible for producing manifest list container images, generating rendered Kubernetes manifests, and a draft release that will contain both of those attached as release artifacts. |
18 | 8 |
|
19 | | -* Make sure you have a clean workspace. `git status` should show no change(s) or untracked file. |
20 | | -* Make sure you pull the latest from `upstream`. |
21 | | -* Checkout `master` branch. |
22 | | -* Run `make release` |
| 9 | +## Step 0: Review the Release Milestone |
23 | 10 |
|
24 | | -## Step 3: Bump the Version |
| 11 | +If the release you plan to create corresponds with an existing [milestone](https://github.com/operator-framework/operator-lifecycle-manager/milestones/), make sure that all features have been committed. If a feature will not be added to the release be sure to remove it from the milestone. |
25 | 12 |
|
26 | | -* Bump the version in `OLM_VERSION` file. Make a new PR with this change only. |
27 | | -* Wait until the PR has been merged. |
| 13 | +## Step 1: Setup the Release Tag |
28 | 14 |
|
29 | | -## Step 4: Setup Tag |
| 15 | +In order to trigger the existing release automation, you need to first create a new tag locally, and push that tag up to the upstream repository remote. |
30 | 16 |
|
31 | | -If git `push` is disabled on `upstream` repository in your fork, then clone this repository so that you can push to `master` directly. |
| 17 | +**Note**: The following steps assume that remote is named `origin`. |
32 | 18 |
|
33 | 19 | * Pull the latest. |
34 | 20 | * Make sure you are on `master` branch. |
35 | 21 | * Make a new tag that matches the version. |
36 | 22 | * Push tag directly to this repository. |
37 | 23 |
|
38 | 24 | ```bash |
39 | | -# 0.11.0 is the bumped version. |
40 | | -git tag -a v0.18.0 -m "Version 0.18.0" |
| 25 | +# v0.20.0 is the bumped version. |
| 26 | +git tag -a v0.20.0 -m "Version 0.20.0" |
41 | 27 |
|
42 | 28 | # origin remote points to operator-framework/operator-lifecycle-manager |
43 | | -git push origin v0.18.0 |
| 29 | +git push origin v0.20.0 |
44 | 30 | ``` |
45 | 31 |
|
46 | | -* Confirm that new images have been built here: <https://quay.io/repository/operator-framework/olm?tab=builds>. |
47 | | - |
48 | | -## Step 5: Generate Manifests |
49 | | - |
50 | | -* Make sure you have a clean workspace. `git status` should show no change(s) or untracked file. |
51 | | -* Make sure you pull the latest from `upstream`. |
52 | | -* Run `make release` on `master` branch. |
53 | | -* Make a new PR and ensure all tests pass for merging. |
54 | | - |
55 | | -Verify the following: |
56 | | - |
57 | | -* The image digest in manifest file(s) matches the new tag in `quay.io`. |
58 | | - |
59 | | -## Step 6: Generate Changelog |
60 | | - |
61 | | -Changelogs for OLM are generated using [GitHub Changelog Generator](https://github.com/github-changelog-generator/github-changelog-generator). |
62 | | - |
63 | | -You need to have `gem` installed on your workstation. Execute the following command to install `github-changelog-generator`. |
64 | | - |
65 | | -```bash |
66 | | -gem install github_changelog_generator |
67 | | -``` |
68 | | - |
69 | | -Make sure you have a GitHub API access token. You can generate one from [tokens](https://github.com/settings/tokens) |
70 | | - |
71 | | -Run the following command to generate a changelog for this release: |
72 | | - |
73 | | -```bash |
74 | | -# <start-semver> is the previous version. |
75 | | -# <end-semver> is the new release you have made. |
76 | | -GITHUB_TOKEN="<github-api-token>" |
77 | | -github_changelog_generator \ |
78 | | - -u operator-framework \ |
79 | | - -p operator-lifecycle-manager \ |
80 | | - --token=${GITHUB_TOKEN} \ |
81 | | - --since-tag=<start-semver> \ |
82 | | - --future-release=<end-semver> \ |
83 | | - --pr-label="**Other changes:**" \ |
84 | | - -b CHANGELOG.md |
85 | | -``` |
86 | | - |
87 | | -**Note**: You may run into API rate limiting when attempting to generate the changelog. |
88 | | - |
89 | | -By default, all open and closed issues will be queried when running the above command, which can lead to API rate limiting. Lower the number of issues that will be queried by specifying the `--max-issues` flag (e.g. `--max-issues=100`) and re-run the above command with that flag provided. |
90 | | - |
91 | | -Ensure the `CHANGELOG.md` has been modified locally and open a PR with those generated changes. |
92 | | - |
93 | | -## Step 7: Create a New GitHub Release |
| 32 | +## Step 2: Verify that GoReleaser is Running |
94 | 33 |
|
95 | | -* Create a new GtiHub release [here](https://github.com/operator-framework/operator-lifecycle-manager/releases/new) |
96 | | -* Choose the new tag matching the version you created. |
97 | | -* You can set `Title` to the same value as the tag name. |
98 | | -* Add the generated `changelog` to the release description. |
99 | | -* Save `draft` of the release. |
| 34 | +Once a manual tag has been created, monitor the progress of the [release workflow action](https://github.com/operator-framework/operator-lifecycle-manager/actions/workflows/goreleaser.yaml) that was triggered when a new tag has been created to ensure a successful run. |
100 | 35 |
|
101 | | -## Step 8: QuickStart |
| 36 | +Once successful, navigate to the [quay.io/operator-framework/olm image repository](https://quay.io/repository/operator-framework/olm?tab=tags) and ensure that a new manifest list container image has been created. |
102 | 37 |
|
103 | | -Edit the GitHub Release: |
| 38 | +## Step 3: CHANGELOG Verification |
104 | 39 |
|
105 | | -* Upload the files `crds.yam`, `install.sh` and `olm.yaml` as release artifacts. These files are located in `deploy/upstream/quickstart` |
106 | | -* Add install instruction, see an [example here](https://github.com/operator-framework/operator-lifecycle-manager/releases/tag/0.10.0#Install). |
| 40 | +Navigate to the [releases](https://github.com/operator-framework/operator-lifecycle-manager/releases) tab for the OLM repository, and verify that a draft release has been produced and the generated CHANGELOG appears to be correct. GoReleaser is responsible for generating a CHANGELOG based on the diff between the latest tag, and the tag that was just created, excluding some commit(s) that have a `doc` or `test` prefix. |
107 | 41 |
|
108 | | -## Step 9: Publish Release |
| 42 | +## Step 4: Publish the Draft Release |
109 | 43 |
|
110 | 44 | * Ensure that all links are valid and works as expected. |
111 | | -* Publish the release! |
| 45 | +* Publish the draft release! |
0 commit comments