sigs.k8s.io/kubebuilder/v3@v3.14.0/RELEASE.md (about)

     1  # Release Process
     2  
     3  The Kubebuilder Project is released on an as-needed basis. The process is as follows:
     4  
     5  **Note:** Releases are done from the `release-MAJOR.MINOR` branches. For PATCH releases it is not required
     6  to create a new branch. Instead, you will just need to ensure that all major fixes are cherry-picked into the respective
     7  `release-MAJOR.MINOR` branch. To know more about versioning check https://semver.org/.
     8  
     9  **Note:** Before `3.5.*` release this project was released based on `MAJOR`. A change to the
    10  process was done to ensure that we have an aligned process under the org (similar to `controller-runtime` and
    11  `controller-tools`) and to make it easier to produce patch releases.
    12  
    13  ## How to do a release
    14  
    15  ### Create the new branch and the release tag
    16  
    17  1. Create a new branch `git checkout -b release-<MAJOR.MINOR>` from master
    18  2. Push the new branch to the remote repository
    19  
    20  ### Now, let's generate the changelog
    21  
    22  1. Create the changelog from the new branch `release-<MAJOR.MINOR>` (`git checkout release-<MAJOR.MINOR>`).
    23     You will need to use the [kubebuilder-release-tools][kubebuilder-release-tools] to generate release notes. See [here][release-notes-generation]
    24  
    25  > **Note**
    26  > - You will need to have checkout locally from the remote repository the previous branch
    27  > - Also, ensure that you fetch all tags from the remote `git fetch --all --tags`
    28  > - Also, if you face issues to generate the release notes you might want to able to sort it out by running i.e.: 
    29  > `go run sigs.k8s.io/kubebuilder-release-tools/notes --use-upstream=false --from=v3.11.0 --branch=release-X`
    30  
    31  
    32  ### Draft a new release from GitHub
    33  
    34  1. Create a new tag with the correct version from the new `release-<MAJOR.MINOR>` branch
    35  2. Verify the Release Github Action. It should build the assets and publish in the draft release 
    36  3. You also need to manually add the changelog generated above on the release page and publish it. Now, the code source is released !
    37  
    38  ### Update the website docs (https://book.kubebuilder.io/quick-start.html)
    39  
    40  1. Push a PR to update the `book-v3` branch with the changes of the latest release branch created (`release-<MAJOR.MINOR>`)
    41  2. Ping in the [Kubebuilder Slack channel](https://kubernetes.slack.com/archives/CAR30FCJZ) and ask for reviews.
    42  
    43  ### When the release be done and the website update: Announce the new release:
    44  
    45  1. Announce the new release on the Slack channel, i.e:
    46  
    47  ````
    48  :announce: Kubebuilder v3.5.0 has been released!
    49  This release includes a Kubernetes dependency bump to v1.24.
    50  For more info, see the release page: https://github.com/kubernetes-sigs/kubebuilder/releases/tag/v3.5.0
    51   :tada:  Thanks to all our contributors!
    52  ````
    53  
    54  2. Announce the new release via email is sent to `kubebuilder@googlegroups.com` with the subject `[ANNOUNCE] Kubebuilder $VERSION is released`
    55  
    56  
    57  ## HEAD releases
    58  
    59  The binaries releases for HEAD are available here:
    60  
    61  - [kubebuilder-release-master-head-darwin-amd64.tar.gz](https://storage.googleapis.com/kubebuilder-release/kubebuilder-release-master-head-darwin-amd64.tar.gz)
    62  - [kubebuilder-release-master-head-linux-amd64.tar.gz](https://storage.googleapis.com/kubebuilder-release/kubebuilder-release-master-head-linux-amd64.tar.gz)
    63  
    64  ## How the releases are configured
    65  
    66  The releases occur in an account in the Google Cloud (See [here](https://console.cloud.google.com/cloud-build/builds?project=kubebuilder)) using Cloud Build.
    67  
    68  ### To build the Kubebuilder CLI binaries:
    69  
    70  A trigger GitHub action [release](.github/workflows/release.yml) is trigged when a new tag is pushed.
    71  This action will caall the job [./build/.goreleaser.yml](./build/.goreleaser.yml).
    72  
    73  ### To build the Kubebuilder-tools: (Artifacts required to use ENV TEST)
    74  
    75  Kubebuilder projects requires artifacts which are used to do test with ENV TEST (when we call `make test` target)
    76  These artifacts can be checked in the service page: https://storage.googleapis.com/kubebuilder-tools
    77  
    78  The build is made from the branch [tools-releases](https://github.com/kubernetes-sigs/kubebuilder/tree/tools-releases) and the trigger will call the `build/cloudbuild_tools.yaml` passing 
    79  as argument the architecture and the SO that should be used, e.g:
    80  
    81  <img width="553" alt="Screenshot 2022-04-30 at 10 15 41" src="https://user-images.githubusercontent.com/7708031/166099666-ae9cd2df-73fe-47f6-a987-464f63df9a19.png">
    82  
    83  For further information see the [README](https://github.com/kubernetes-sigs/kubebuilder/blob/tools-releases/README.md).
    84  
    85  ### To build the `kube-rbac-proxy` images:
    86  
    87  These images are built from the project [brancz/kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy).
    88  The projects built with Kubebuilder creates a side container with `kube-rbac-proxy` to protect the Manager.
    89  
    90  These images are can be checked in the consolse, see [here](https://console.cloud.google.com/gcr/images/kubebuilder/GLOBAL/kube-rbac-proxy).
    91  
    92  The project `kube-rbac-proxy` is in the process to be donated to the k8s org. However, it is going on for a long time and then,
    93  we have no ETA for that to occur. When that occurs we can automate this process. But until there we need to generate these images
    94  by bumping the versions/tags released by `kube-rbac-proxy` on the branch 
    95  [kube-rbac-proxy-releases](https://github.com/kubernetes-sigs/kubebuilder/tree/kube-rbac-proxy-releases)
    96  then the `build/cloudbuild_kube-rbac-proxy.yaml` will generate the images.
    97  
    98  To check an example, see the pull request [#2578](https://github.com/kubernetes-sigs/kubebuilder/pull/2578).
    99  
   100  **Note**: we cannot use the images produced by the project `kube-rbac-proxy` because we need to ensure
   101  to Kubebuilder users that these images will be available.
   102  
   103  ### To build the `gcr.io/kubebuilder/pr-verifier` images:
   104  
   105  These images are used to verify the PR title and description. They are built from [kubernetes-sigs/kubebuilder-release-tools](https://github.com/kubernetes-sigs/kubebuilder-release-tools/).
   106  In Kubebuilder, we have been using this project via the GitHub action [.github/workflows/verify.yml](.github/workflows/verify.yml)
   107  and not the image, see:
   108  
   109  ```yaml
   110    verify:
   111      name: Verify PR contents
   112      runs-on: ubuntu-latest
   113      steps:
   114      - name: Verifier action
   115        id: verifier
   116        uses: kubernetes-sigs/kubebuilder-release-tools@v0.1.1
   117        with:
   118          github_token: ${{ secrets.GITHUB_TOKEN }}
   119  ```
   120  
   121  However, the image should still be built and maintained since other projects under the org might be using them. 
   122  
   123  [kubebuilder-release-tools]: https://github.com/kubernetes-sigs/kubebuilder-release-tools
   124  [release-notes-generation]: https://github.com/kubernetes-sigs/kubebuilder-release-tools/blob/master/README.md#release-notes-generation
   125  [release-process]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/VERSIONING.md#releasing