Katib release process

[yanniszark]

/kind feature

Background:

Katib wants to release manifests, in its various releases. Now that manifests live inside upstream app repos, the final result should be committed in this repo, not kubeflow/manifests. In this issue, I will describe a procedure to release manifests and make sure that release changes don't affect master.

Describe the solution you'd like

Here is the procedure:
Suppose we have a repo with kustomizations under manifests.
Here are the steps that the upstream repository must take:

1. Create a new release branch:

VERSION="1.0"
git checkout -b release-$VERSION origin/master

2. Edit files under manifests (e.g., Deployments) to the release image tag. This can be done manually or with a sed command:

TAG=$VERSION
# Example with sed or manually
find manifests -type f | sed -i "s/<old_image_tag>/$TAG/g"

3. Commit changes to the release branch and tag commit as version:

git commit -s -a -m "Release $VERSION"
git tag $VERSION
git push -u origin release-$VERSION
git push $VERSION

4. Create GitHub release from existing tag and add desired release notes.

cc @andreyvelich

[andreyvelich]

Thank you for writing this @yanniszark.
My concern about this approach that the "master" branch will not have release tag in the history.
So by using git log on the master branch we can't see the generated tag.
Is it a good practice to have a such structure?

What do you think about it @gaocegege @johnugeorge @yanniszark ?

[yanniszark]

@andreyvelich from my side, I think that's ok. I see that other big projects, like Istio, also do this.
I.e., Istio has release branches and its tags don't correspond to master commits.
We do the same in kubeflow/manifests and kubeflow/kubeflow afaik.

[andreyvelich]

Got it @yanniszark .

Basically, if we want to release new patch (e.g. 0.11.1) to fix something in the release (e.g 0.11), we follow:

1. Merge all bug fixes to the master
2. Cherry Pick these commits to the release-0.11 branch.
3. Build and push new images from the latest commit (from the Cherry Pick PR) in release-0.11 branch. Also add 0.11.1 tag to that images.
4. Create new commit (X) on the release-0.11 branch where we update manifest image tags to the 0.11.1
5. Tag this (X) commit with 0.11.1.

Is that correct ?

cc @gaocegege @johnugeorge

[yanniszark]

@andreyvelich yes, it sounds right. Only nit, I would imagine that step (3) is last. I.e. create images after creating the tag. So that it can also be automate-able by CI in the future.

[gaocegege]

I have a question about how to use katib 0.11 in kubeflow 1.3, should we create release-1.3 for kubeflow 1.3 or release-0.11?

[andreyvelich]

I have a question about how to use katib 0.11 in kubeflow 1.3, should we create release-1.3 for kubeflow 1.3 or release-0.11?

We will run make release BRANCH=release-0.11 TAG=v0.11.0 for this release.
So the first Katib release for Kubeflow 1.3 will be v0.11.0