Revert "Fix SHA for go-runner manifest - bump version"

[listx]

This reverts commit 97278f1.

Here is the sequence of events. Originally, #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 #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 #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 #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 #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 #850's postsubmit
run about tag moves, and is still complaining about this even after
PR #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 #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 #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.

/cc @dims @justaugustus

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: listx

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:

• k8s.gcr.io/images/k8s-staging-build-image/OWNERS [listx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dims]

thanks @listx !! sorry

/lgtm

[dims]

+1 to "We should exit with an error on tag moves during dry runs"