Fix SHA for go-runner manifest #850
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
k8s-ci-robot
added
size/XS
k8s-ci-robot
added
area/release-eng
dims
force-pushed
the
fix-sha-for-go-runner
branch
from
f0c9dfb
to
3a0b5a3
Compare
dims
changed the title
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/hold |
k8s-ci-robot
added
the
do-not-merge/hold
my bad, i used the SHA for amd64 image :( Signed-off-by: Davanum Srinivas <davanum@gmail.com>
dims
force-pushed
the
fix-sha-for-go-runner
branch
from
3a0b5a3
to
97278f1
Compare
k8s-ci-robot
removed
the
lgtm
justaugustus
suggested changes
May 7, 2020
There was a problem hiding this comment.
@dims -- We can't manipulate prod tags, post-promo.
Can you add this as v0.1.1?
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder, dims The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
dims
changed the title
|
This PR was a NOP because the promoter rejects tag moves. We have to either (1) delete prod tag |
|
Ack thanks @listx |
|
@listx -- Discussing here: https://kubernetes.slack.com/archives/C2C40FMNF/p1588877251218300?thread_ts=1588868307.203500&cid=C2C40FMNF We're fixing with a |
listx
pushed a commit
to listx/k8s.io
that referenced
this pull request
May 8, 2020
This reverts commit 97278f1. Here is the sequence of events. Originally, kubernetes#849 incorrectly promoted sha256:536ab131b0d0e3b13eb83c985cc0ac9ba7e69e7dac9521e6cacd6a8b6019e0a6 to `v0.1.0`. This was in error because this digest was not the digest of the manifest list, but only for the amd64 image. Then, PR kubernetes#850 was created to fix this. Originally, that PR assigned the correct digest of the manifest list sha256:8ee20934e6c005a9ce8d6d8b7ed23698c3bb80e0b30a3d49e5aeca928cc69bf3 to a new tag, `v0.1.1`. This was OK for the promoter (it was what I LGTM'ed), because it assigned a new tag for a new digest; however it was NOT OK because the underlying image was really versioned as `v0.1.0` (kubernetes/kubernetes#90804). Later, PR kubernetes#850 *was changed* so that sha256:8ee20934e6c005a9ce8d6d8b7ed23698c3bb80e0b30a3d49e5aeca928cc69bf3 was tagged as `v0.1.0` while a new build of `v0.1.1` was created here kubernetes/kubernetes#90852. This change to promote sha256:8ee20934e6c005a9ce8d6d8b7ed23698c3bb80e0b30a3d49e5aeca928cc69bf3 into the __existing__ `v0.1.0` tag resullted in PR kubernetes#850 becoming a NOP. The promoter simply ignored this PR because tag moves are not supported. That is, in order to honor the intent of PR kubernetes#850, the promoter would have had to __delete__ the `v0.1.0` tag from the incorrect digest sha256:536ab131b0d0e3b13eb83c985cc0ac9ba7e69e7dac9521e6cacd6a8b6019e0a6 and reassign this tag to sha256:8ee20934e6c005a9ce8d6d8b7ed23698c3bb80e0b30a3d49e5aeca928cc69bf3. This is why the promoter complained about this in PR kubernetes#850's postsubmit run about tag moves, and is still complaining about this even after PR kubernetes#853 (promoting the newly-built `v0.1.1` image) was merged, like this: ``` ... tag 'v0.1.0' in dest points to sha256:536ab131b0d0e3b13eb83c985cc0ac9ba7e69e7dac9521e6cacd6a8b6019e0a6, not sha256:8ee20934e6c005a9ce8d6d8b7ed23698c3bb80e0b30a3d49e5aeca928cc69bf3 (as per the manifest), but tag moves are not supported; skipping ... ``` Our promoter manifests should be kept free of impossible-to-do intent. The solution is to either (1) delete the existing `v0.1.0` tag from production (making the intent not a tag move, but a tag add) and keep the promoter manifest as-is, or (2) revert PR kubernetes#850 and keep the incorrect digest for `v0.1.0` to silence the tag move warning. Because this is not a production emergency, (1) would be against policy. Hence this PR, which opts for option (2). That being said, the dry run of the promoter in PR kubernetes#850 did correctly detect the tag move as well, but exited without an error. We should exit with an error on tag moves during dry runs in the future, because tag moves result from prohibited manifest *intent*. This is tracked here: kubernetes-sigs/promo-tools#212.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
my bad, i used the SHA for amd64 image :(
Signed-off-by: Davanum Srinivas davanum@gmail.com