Minikube: Target of git tag v1.13.0 changed

[SMillerDev]

Is the retag of 1.13 intentional? The homebrew maintainers would like to know before we point to the new commit.

---

Steps to reproduce the issue:

1. Check the defined commit belonging to the 1.13 tag in homebrew
2. See that it differs from the current commit in the 1.13 tag
3. ???
4. profit

Full output of failed command:
Not applicable

Full output of minikube start command used, if not already included:
Not applicable

[afbjorklund]

https://github.com/Homebrew/linuxbrew-core/commit/2ffb4e70d7398fae18cb8d66105e7e3204fc19de

https://github.com/kubernetes/minikube/commit/eeb05350f8ba6ff3a12791fcce350c131cb2ff44

https://github.com/kubernetes/minikube/commit/0c5e9de4ca6f9c55147ae7f90af97eff5befef5f

@sharifelgamal : do you know how this could have happened, glitch in the release script ?

 git diff eeb0535 0c5e9de
diff --git a/hack/jenkins/release_build_and_upload.sh b/hack/jenkins/release_build_and_upload.sh
index 9b5f437cb..d07b25753 100755
--- a/hack/jenkins/release_build_and_upload.sh
+++ b/hack/jenkins/release_build_and_upload.sh
@@ -66,8 +66,8 @@ if ! [[ ${VERSION_BUILD} =~ ^[0-9]+$ ]]; then
   exit 0
 fi

-echo "Updating Docker images ..."
-make push-gvisor-addon-image push-storage-provisioner-image
+#echo "Updating Docker images ..."
+#make push-gvisor-addon-image push-storage-provisioner-image

 echo "Updating latest bucket for ${VERSION} release ..."
 gsutil cp -r "gs://${BUCKET}/releases/${TAGNAME}/*" "gs://${BUCKET}/releases/latest/"

https://github.com/kubernetes/minikube/pull/9182/commits/d0f17a4886906481c610746a49f3e55385bcef02

[SMillerDev]

That's the commit where it was merged into linuxbrew and at the time the tag still pointed to that commit (Otherwise CI would fail and we won't merge)

[afbjorklund]

We have some other issues with the release scripts (#9074), so this could be related to the same underlying process problem...

https://github.com/kubernetes/minikube/blob/master/hack/tag_release.sh

[SMillerDev]

Unless the release script creates and deletes the git tags I don't think that's related. Brew will just check out the repo during the build and doesn't actually use the provided releases.

[afbjorklund]

I'm guessing human error, but probably a README somewhere that could need some updating. Doesn't look like any code changes, when comparing the commits (above).

https://minikube.sigs.k8s.io/docs/contrib/releasing/binaries/

[afbjorklund]

More info: https://git-scm.com/docs/git-tag#_on_re_tagging

[noelleleigh]

Also, will there be release notes written for v1.13.0?

[sharifelgamal]

The release script had a bug in it (indeed, the change @afbjorklund pointed out above) that caused the release process to halt midway. I did my best to clean everything up, but yeah, the newest commit should be the one we point at. Fortunately, there should be no functional change between the two commits.

I'll get the release notes fixed up today.

[afbjorklund]

@SMillerDev : hopefully that explanation was good enough ? https://github.com/kubernetes/minikube/releases/tag/v1.13.0

[SMillerDev]

Yeah, just wanted to make sure it wasn't malicious.

[afbjorklund]

Revision was fixed in https://github.com/Homebrew/homebrew-core/commit/d6268ceecdc42392a10339f3c62e019a9de94168
(which will be available in https://github.com/Homebrew/linuxbrew-core too, soon enough)

[noelleleigh]

So, can this issue be closed now?

[SMillerDev]

From my perspective, yes.