lifecycle `v0.20.13` Git tag pointing at wrong commit

[edmorley]

The lifecycle v0.20.13 release was released twice, the second release being to include this fix: https://github.com/buildpacks/lifecycle/pull/1532

However, after the second release the automation didn't update the Git tag, so it's still pointing at the commit prior to that PR merging: https://github.com/buildpacks/lifecycle/commit/828680fd2d9f0f63c3a23bf60a015db74b6d162f

Whereas the v0.20.13 Git tag should be referencing this commit instead: https://github.com/buildpacks/lifecycle/commit/84bbd62a0502232d47f4af2eeb9eb2abcf5900d7

This discrepancy means that GitHub compare URLs like the following (which we have our "bump lifecycle version" automation use in its PR description to assist the PR reviewer) give the wrong list of commits in the new release: https://github.com/buildpacks/lifecycle/compare/v0.20.12...v0.20.13

cc @jabrown85

[jabrown85]

Thanks for the report @edmorley! I tried to find all the loose ends when I re-created the release during pre-release to release but missed the tag itself.

Tags in GitHub can't be deleted when they are associated with a release.

I can update the release briefly to a new v0.20.13-temp and then delete and re-create the expected tag. I'm not entirely sure what consequences await me here. I believe it is only metadata and won't affect the release notes or uploaded artifacts for the release. It might spam folks in slack/feeds that are listening though.

As a consumer of lifecycle, what would you like to see us do here? Want me to try it out?