Commit sha unlinked from version

[blueprismo]

/kind bug

What happened?

Until recently, tag v2.3.1 pointed to commit 344390f5b7d562718bf4123f28353dc46d49991f.

Since yesterday, builds that rely on this tag started failing due to a mismatch between the expected commit SHA and the one currently referenced by the v2.3.1 tag.

Additionally, when inspecting commit 344390f5b7d562718bf4123f28353dc46d49991f, GitHub now shows it as associated with v3.0.0:
344390f

This suggests that release tags (v2.3.1, and possibly v2.3.0) were moved or recreated.

Example build log:

#182 clone github repository git+https://github.com/kubernetes-sigs/aws-efs-csi-driver.git#v2.3.1
#182 2.592 From https://github.com/kubernetes-sigs/aws-efs-csi-driver
#182 2.592  * [new tag]         v2.3.1     -> v2.3.1
#182 2.594 344390f5b7d562718bf4123f28353dc46d49991f
#182 2.595 344390f5b7d562718bf4123f28353dc46d49991f
#182 2.770 Initialized empty Git repository in /buildkit/data/runc-overlayfs/snapshots/snapshots/3565079/fs/.git/
#182 2.773 commit
#182 3.389 From file:///buildkit/data/runc-overlayfs/snapshots/snapshots/3565036/fs
#182 3.389  * [new tag]         v2.3.1     -> v2.3.1
#182 3.389  * [new tag]         v2.3.1     -> v2.3.1
#182 5.274 Note: switching to 'FETCH_HEAD'.
#182 5.274 
#182 5.274 You are in 'detached HEAD' state. You can look around, make experimental
#182 5.274 changes and commit them, and you can discard any commits you make in this
#182 5.274 state without impacting any branches by switching back to a branch.
#182 5.274 
#182 5.274 If you want to create a new branch to retain commits you create, you may
#182 5.274 do so (now or later) by using -c with the switch command. Example:
#182 5.274 
#182 5.274   git switch -c <new-branch-name>
#182 5.274 
#182 5.274 Or undo this operation with:
#182 5.274 
#182 5.274   git switch -
#182 5.274 
#182 5.274 Turn off this advice by setting config variable advice.detachedHead to false
#182 5.274 
#182 5.274 HEAD is now at 344390f Merge pull request #1811 from zmaguire/master
#182 DONE 5.8s

What you expected to happen?

Commits to be inmutable and bound to the tag they are associated to.

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

This is no longer reproducible because the tags appear to have already been modified, but:

Previously, v2.3.1 resolved to commit 344390f5b7d562718bf4123f28353dc46d49991f
Now, the tag appears to point to a different commit.

Anything else we need to know?:
n/a
Why the tags v2.3.1, v2.3.0 were re-tagged yesterday? Was this intentional?

This impacts build reproducibility and supply-chain guarantees

Thanks!!

[DavidXU12345]

@blueprismo yes we re-tagged v2.3.0 and v2.3.1 because they were previously pointing to the wrong commits. The version bump commits were missing due to a bug in the GitHub workflow which has been fixed (#1834). Before the re-tag, running following command would have installed v2.3.0 instead of v2.3.1.

kubectl apply -k github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable?ref=v2.3.1

This is now resolved.

Helm chart tags were not affected and remain accurate. You may consider to use Helm chart tags if the re-tagging is causing issues for you. Thanks