-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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.
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
📖 update RELEASE doc to provide the info about how the releases are done #2662
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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"> | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Becuase it is maintained by us. 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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: