Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

📖 update RELEASE doc to provide the info about how the releases are done #2662

Merged
merged 1 commit into from
May 11, 2022
Merged

📖 update RELEASE doc to provide the info about how the releases are done #2662

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
64 changes: 64 additions & 0 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,70 @@ The binaries releases for HEAD are available here:
- [kubebuilder-release-master-head-darwin-amd64.tar.gz](https://storage.googleapis.com/kubebuilder-release/kubebuilder-release-master-head-darwin-amd64.tar.gz)
- [kubebuilder-release-master-head-linux-amd64.tar.gz](https://storage.googleapis.com/kubebuilder-release/kubebuilder-release-master-head-linux-amd64.tar.gz)

## How the releases are configured

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.

### To build the Kubebuilder CLI binaries:

A trigger `build-kb-release` is configured to call [build/cloudbuild.yaml](build/cloudbuild.yaml).
This trigger will be executed when any new tag be published.
The tags must be built from the release branch (Currently, `release-3`).

Also, we have a trigger to generate snapshots builds from the master branch.
This trigger will call [build/cloudbuild_snapshot.yaml](build/cloudbuild_snapshot.yaml)
when any change needs to be performed on master.

### To build the Kubebuilder-tools: (Artifacts required to use ENV TEST)

Kubebuilder projects requires artifacts which are used to do test with ENV TEST (when we call `make test` target)
These artifacts can be checked in the service page: https://storage.googleapis.com/kubebuilder-tools

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
as argument the architecture and the SO that should be used, e.g:

<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">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this screenshot-png be part of the PR? I am not sure how images are handled in the docs. But could not find any existing references.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we click on the view, we can check that. This doc is not used in the books.
So that is fine. I mean, it works fine see:

Screenshot 2022-05-09 at 13 26 56

Screenshot 2022-05-09 at 13 27 03


For further information see the [README](https://github.com/kubernetes-sigs/kubebuilder/blob/tools-releases/README.md).

### To build the `kube-rbac-proxy` images:

These images are built from the project [brancz/kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy).
The projects built with Kubebuilder creates a side container with `kube-rbac-proxy` to protect the Manager.

These images are can be checked in the consolse, see [here](https://console.cloud.google.com/gcr/images/kubebuilder/GLOBAL/kube-rbac-proxy).

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,
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
by bumping the versions/tags released by `kube-rbac-proxy` on the branch
[kube-rbac-proxy-releases](https://github.com/kubernetes-sigs/kubebuilder/tree/kube-rbac-proxy-releases)
then the `build/cloudbuild_kube-rbac-proxy.yaml` will generate the images.

To check an example, see the pull request [#2578](https://github.com/kubernetes-sigs/kubebuilder/pull/2578).

**Note**: we cannot use the images produced by the project `kube-rbac-proxy` because we need to ensure
to Kubebuilder users that these images will be available.

### To build the `gcr.io/kubebuilder/pr-verifier` images:

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/).
In Kubebuilder, we have been using this project via the GitHub action [.github/workflows/verify.yml](.github/workflows/verify.yml)
and not the image, see:

```yaml
verify:
name: Verify PR contents
runs-on: ubuntu-latest
steps:
- name: Verifier action
id: verifier
uses: kubernetes-sigs/kubebuilder-release-tools@v0.1.1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
```

However, the image should still be built and maintained since other projects under the org might be using them.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this step need to be done for every Kubebuilder release?

I didn't see any steps for the proper way to build and verify that the pr-verifier images are built and in the right place. Is this an automated process that only occurs when changes are made to the pr-verifier?

Copy link
Member Author

@camilamacedo86 camilamacedo86 May 9, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. This step does need to be done for every KB release. This trigger is done for the repo: kubernetes-sigs/kubebuilder-release-tools and not in the Kubebuilder repo. This image is only used in the Kuebuilder CI to check the PR title and descriptions. We just need to re-gen new images when we have updates/changes there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since that is a separate repo, should release steps for that image be provided in that repo instead of the KB release steps?

How does this relate to a KB release other than that the pr-verifier action is used to verify KB PRs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Becuase it is maintained by us.
See that it is kubebuilder-tools-release and is under Kubebuilder project when we check the Google cloud triggers. So, I just want to make clear the info.

Any extra information should be checked in its repo. We can improve it afterwords. For now, my goal is we have the info at least in case someone need to check it out.


[kubebuilder-release-tools]: https://github.com/kubernetes-sigs/kubebuilder-release-tools
[release-notes-generation]: https://github.com/kubernetes-sigs/kubebuilder-release-tools/blob/master/README.md#release-notes-generation
[release-process]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/VERSIONING.md#releasing