Skip to content

Fix longstanding bug in git.next_deploy_tag()

Ahmon Dancy requested to merge master-I9fb05718a492b1137bd1d841199b51c51352f6b0 into master

git.next_deploy_tag() previously calculated the next tag to use by
counting the number of existing tags for the day. This approach leads
to a tag name being reused after git.clean_tags() has run (after the
configured tags_to_keep (default 20) number of deploys). Further,
the selected tag was created with the -f (force) flag, allowing it
to happily blast the existing tag on the deploy server. Then when
scap deploy-local runs on the targets, it fetches tags and the
operation fails with an error like:

deploy-local failed: <FailedCommand> {'exitcode': 1, 'stdout': '', 'stderr': 'From http://deploy/test-lfs/\n ! [rejected]        scap/sync/2024-02-23/0021 -> scap/sync/2024-02-23/0021  (would clobber existing tag)\n ! [rejected]        scap/sync/2024-02-23/0022 -> scap/sync/2024-02-23/0022  (would clobber existing tag)\n'}

I ran into this problem today while doing scap deploy development.

This commit changes git.next_deploy_tag() to get a sorted (by
version) list of today's tags and increment the sequence number of
the most recent.

git.tag_repo() has been changed to not pass the -f (force) flag.
This will result in earlier failure should git.next_deploy_tag()
regress in the future.

Bug: T311336

Related MRs:

Edited by Ahmon Dancy

Merge request reports