v1.20.0-alpha.2 is in stable.txt

[k-kinzal]

What happened:

https://storage.googleapis.com/kubernetes-release/release/stable.txt

v1.20.0-alpha.2

There seems to be an alpha version in stable.txt

What you expected to happen:

I think v1.19.2 should be in stable.txt.

How to reproduce it (as minimally and precisely as possible):

Go to https://storage.googleapis.com/kubernetes-release/release/stable.txt

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others:

[k-kinzal]

/sig release

[justaugustus]

/priority critical-urgent
/assign @hasheddan @saschagrunert

cc: @kubernetes/release-engineering
/triage accepted

Investigation thread on Slack: https://kubernetes.slack.com/archives/C2C40FMNF/p1602639142299800

[saschagrunert]

Thanks for the fix @hasheddan! 💚 I'm not sure if the v1.19.3 patch release from today should bring back the right version, because we compare the remote version (right now v1.20.0-alpha.2) to the new one (v1.19.3) on a semver basis:

https://github.com/kubernetes/release/blob/3e6255b8b86d1b43b8fcff67fd36d03f60495422/pkg/release/publish.go#L168-L190

Can we manually revert the markers back somehow?

[BoleynSu]

It would be better to require manual approval for releases to prevent issues like this. What if we introduce another label for non-releases? The current fix will still fail to react correctly.

If we really want to avoid manual approval, a allowlist would be better than a blocklist here, i.e., checking with if version in allowlist instead of if version not in blocklist. IIUC we can accept false negative while we really want to avoid false positive.

[saschagrunert]

It would be better to require manual approval for releases to prevent issues like this. What if we introduce another label for non-releases? The current fix will still fail to react correctly.

Not sure if I get this, how would manual approval work technically?

[BoleynSu]

It would be better to require manual approval for releases to prevent issues like this. What if we introduce another label for non-releases? The current fix will still fail to react correctly.

Not sure if I get this, how would manual approval work technically?

I mean adding a blocker that requires manual approval in the pipeline.

[BoleynSu]

It would be better to require manual approval for releases to prevent issues like this. What if we introduce another label for non-releases? The current fix will still fail to react correctly.

Not sure if I get this, how would manual approval work technically?

BTW, I updated my comment above to include

If we really want to avoid manual approval, a allowlist would be better than a blocklist here, i.e., checking with if version in allowlist instead of if version not in blocklist. IIUC we can accept false negative while we really want to avoid false positive.

[justaugustus]

Closed via kubernetes/release#1640 (comment).

$ for marker in stable stable-1 stable-1.20; do gsutil cat "gs://kubernetes-release/release/$marker.txt"; done
v1.19.2
v1.19.2
CommandException: No URLs matched: gs://kubernetes-release/release/stable-1.20.txt

/assign
/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

Closed via kubernetes/release#1640 (comment).

$ for marker in stable stable-1 stable-1.20; do gsutil cat "gs://kubernetes-release/release/$marker.txt"; done
v1.19.2
v1.19.2
CommandException: No URLs matched: gs://kubernetes-release/release/stable-1.20.txt

/assign
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.