kubernetes: [Failing Test] Release branch tests are failing to extract latest Kubernetes CI builds
Which jobs are failing: Release branch tests that require extracting a Kubernetes CI build. Examples include:
skew-cluster-latest-kubectl-stable1-gce (ci-kubernetes-e2e-gce-master-new-gci-kubectl-skew)- https://k8s-testgrid.appspot.com/sig-scalability-gce#gce-cos-1.16-scalability-100 - https://github.com/kubernetes/test-infra/issues/15580
- https://k8s-testgrid.appspot.com/sig-scalability-gce#gce-cos-1.15-scalability-100 - https://github.com/kubernetes/test-infra/issues/15580
- https://k8s-testgrid.appspot.com/sig-scalability-gce#gce-cos-1.14-scalability-100 - https://github.com/kubernetes/test-infra/issues/15580
pull-kubernetes-e2e-gce-device-plugin-gpu- https://github.com/kubernetes/kubernetes/issues/86197
Which test(s) are failing:
Overall / Extract
Since when has it been failing:
12-11 12:56 PST
Testgrid link: https://k8s-testgrid.appspot.com/sig-release-master-blocking#skew-cluster-latest-kubectl-stable1-gce
Reason for failure:
W1211 20:56:41.135] 2019/12/11 20:56:41 main.go:319: Something went wrong: failed to acquire k8s binaries: U=https://storage.googleapis.com/kubernetes-release-dev/ci R=v1.16.4-1+8aa1d9dd63e9a4 get-kube.sh failed: error during ./get-kube.sh: exit status 1
W1211 20:56:41.137] Traceback (most recent call last):
W1211 20:56:41.137] File "/workspace/./test-infra/jenkins/../scenarios/kubernetes_e2e.py", line 778, in <module>
W1211 20:56:41.137] main(parse_args())
W1211 20:56:41.137] File "/workspace/./test-infra/jenkins/../scenarios/kubernetes_e2e.py", line 626, in main
W1211 20:56:41.138] mode.start(runner_args)
W1211 20:56:41.138] File "/workspace/./test-infra/jenkins/../scenarios/kubernetes_e2e.py", line 262, in start
W1211 20:56:41.138] check_env(env, self.command, *args)
W1211 20:56:41.138] File "/workspace/./test-infra/jenkins/../scenarios/kubernetes_e2e.py", line 111, in check_env
W1211 20:56:41.138] subprocess.check_call(cmd, env=env)
W1211 20:56:41.138] File "/usr/lib/python2.7/subprocess.py", line 190, in check_call
W1211 20:56:41.138] raise CalledProcessError(retcode, cmd)
W1211 20:56:41.139] subprocess.CalledProcessError: Command '('kubetest', '--dump=/workspace/_artifacts', '--gcp-service-account=/etc/service-account/service-account.json', '--up', '--down', '--test', '--provider=gce', '--cluster=bootstrap-e2e', '--gcp-network=bootstrap-e2e', '--check-leaked-resources', '--check-version-skew=false', '--extract=ci/k8s-stable1', '--extract=ci/latest', '--gcp-node-image=gci', '--gcp-zone=us-west1-b', '--ginkgo-parallel=25', '--skew', '--test_args=--ginkgo.focus=Kubectl --ginkgo.skip=\\[Serial\\] --minStartupPods=8', '--timeout=120m')' returned non-zero exit status 1
Anything else we need to know: /cc @kubernetes/ci-signal /priority critical-urgent /milestone v1.18
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 39 (38 by maintainers)
Reporting back on the out of order releases. It seems the fixes I added in https://github.com/kubernetes/release/pull/1015 allow the releases to run in the right order.
I’ve successfully run mock stage/release steps for 1.16.5 and 1.15.8, as well as kicked off the official prod stages.
Below are links to the GCB for those with access to view:
1.16.5
./gcbmgr stage release-1.16 --buildversion=v1.16.5-beta.1.49+e7f962ba86f4ce--officialflag./gcbmgr release release-1.16 --buildversion=v1.16.5-beta.1.49+e7f962ba86f4ce--officialflagRELEASE_TOOL_REPO="https://github.com/justaugustus/release" RELEASE_TOOL_BRANCH="out-of-order-releases" ./gcbmgr stage release-1.16 --official --build-at-head(ref: https://github.com/kubernetes/kubernetes/issues/86182)RELEASE_TOOL_REPO="https://github.com/justaugustus/release" RELEASE_TOOL_BRANCH="out-of-order-releases" ./gcbmgr release --official release-1.16 --buildversion=v1.16.5-beta.1.51+e7f962ba86f4ce(ref: https://github.com/kubernetes/kubernetes/issues/86182)RELEASE_TOOL_REPO="https://github.com/justaugustus/release" RELEASE_TOOL_BRANCH="out-of-order-releases" ./gcbmgr stage release-1.16 --official --build-at-head --nomock1.15.8
./gcbmgr stage release-1.15 --official --build-at-head./gcbmgr release --official release-1.15 --buildversion=v1.15.8-beta.1.30+14ede42c4fe699RELEASE_TOOL_REPO="https://github.com/justaugustus/release" RELEASE_TOOL_BRANCH="out-of-order-releases" ./gcbmgr stage release-1.15 --official --build-at-headRELEASE_TOOL_REPO="https://github.com/justaugustus/release" RELEASE_TOOL_BRANCH="out-of-order-releases" ./gcbmgr release --official release-1.15 --buildversion=v1.15.8-beta.1.30+14ede42c4fe699RELEASE_TOOL_REPO="https://github.com/justaugustus/release" RELEASE_TOOL_BRANCH="out-of-order-releases" ./gcbmgr stage release-1.15 --official --build-at-head --nomockOnce that PR merges, we’ll proceed with the 1.16.5 and 1.15.8 releases.
@lachie83 opened https://github.com/kubernetes/release/issues/1020 to track the misversioned releases.
The Patch Release Team will be releasing new versions of Kubernetes (1.17.2, 1.16.6, 1.15.9) next week to fix this. We’re tentatively planning for Tuesday, January 21st, by EOD US PT, but given this week’s debugging of our build tools, it’s possible that this date may shift.
As of today, the build versions that we’re targeting are as follows:
Those commits represent essentially no-op PRs we used to trigger a new build version in CI:
The new releases will be functionally equivalent to this week’s releases, save the few commits we’ve added to fix the versioning issue:
When 1.17.2, 1.16.6, and 1.15.9 are released, please IMMEDIATELY use them instead of 1.17.1, 1.16.5, and 1.15.8.
Also sent to kubernetes-dev mailing list: https://groups.google.com/d/topic/kubernetes-dev/Mhpx-loSBns/discussion
Thanks, Stephen.
The commits after the tag are not a problem. This is expected, and typically happens between releases.
The issue seems to be that the release and then next
-beta.0tag were both applied to the same commit this time around, and git is using the release tag as its base ingit describe, rather than the pre-release-beta.0tag.Previously, these were separated by some number of commits, with the
-beta.0tag being more recent.Compare:
vs
Are we tagging the wrong commit for the release now, somehow?