Improve release docs #2736
Improve release docs #2736
Conversation
docs/developer/release-process.md
Outdated
|
|
||
| ## 1 - Send a PR to the bitnami/chart repository | ||
|
|
||
| Since the chart that we host in the Kubeapps repository is only intended for development purposes, we need to synchronize it with the official one in the [bitnami/charts repository](https://github.com/bitnami/charts/tree/master/bitnami/kubeapps). To this end, we need to send a PR with the changes to their repository and wait until it gets accepted. |
There was a problem hiding this comment.
Given that they're different repos with different directory structures, how did you create the PR (I guess if we branch the bitnami charts and copy our files over we could miss some removals etc., so did you delete all files then copy and compare?)
There was a problem hiding this comment.
Yep, even if there are proper ways to sync directories, I just ended up deleting and copying the files, TBH. For the automated PR, we should come up with better approaches here: git with multiple remotes (git subtree I meant), rsyncing dirs, etc
docs/developer/release-process.md
Outdated
|
|
||
| ## 2 - Create a new git tag | ||
|
|
||
| Once the dependencies have been updated and the chart changes merged, the next step is to tagging the latest commit in master and pushing it to the main branch. Please note that the tag name will be used as the release name. |
There was a problem hiding this comment.
| Once the dependencies have been updated and the chart changes merged, the next step is to tagging the latest commit in master and pushing it to the main branch. Please note that the tag name will be used as the release name. | |
| Once the dependencies have been updated and the chart changes merged, the next step is to tag the latest commit in master and pushing it to the main branch. Please note that the tag name will be used as the release name. |
Also, it's not necessarily the latest commit is it? If I happened to merge something while you were doing this process, you'd want to tag the specific commit that you've done some testing on no?
There was a problem hiding this comment.
Yes, that's true indeed! Generally, it is the latest commit, but it's better to make it explicit just in case. Thanks!
docs/developer/release-process.md
Outdated
|
|
||
| But before, we need to create and merge a PR with a chart version bump in `chart/kubeapps/Chart.yaml` ([example](https://github.com/kubeapps/kubeapps/pull/663/files)). This will trigger another CI job that will publish a new version of the chart pointing to the new Docker images built in the step 1. | ||
| You still must **add a high-level description with the release highlights**. Save the draft and **do not publish it yet**. Then, get these notes reviewed by another Kubeapps maintainer. |
There was a problem hiding this comment.
Might be worth mentioning to at least separate out all the version update commits?
Co-authored-by: Michael Nelson <absoludity@gmail.com>
Description of the change
As I am currently releasing a new Kubeapps version, it's a good opportunity to revisit our current docs and keeping it up to date as much as possible.
Benefits
Better docs!
Possible drawbacks
N/A
Applicable issues
Additional information
Marked as draft as I am still following each section before improving it :P