release: properly change working dir if tmp location already exists

[ivanvc]

I identified this issue while working on #18649. Currently, if we follow the practice of testing the release script in the first step when doing a release with DRY=true and then rerun the script, the script won't change directories into the freshly cloned repository. Instead, it will use the current directory, which may be prone to unwanted changes accidentally being pushed as part of the release.

With this approach, running it after a DRY run will yield the error:

In workspace '/tmp/etcd-release-3.5.124/etcd' the branch: release-3.5 diverges from the origin.
Consider cleaning up / renaming this directory or (cd /tmp/etcd-release-3.5.124/etcd && git reset --hard origin/release-3.5)

However, I feel the best experience would be to replace:

    run git checkout "${BRANCH}" || exit 2
    run git pull origin

With a fetch and the hard reset to avoid manual intervention. But, I didn't want to implement it without alignment on this.

Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.72%. Comparing base (6883308) to head (67c42ac).

❗ Current head 67c42ac differs from pull request most recent head 4763cb1

Please upload reports for the commit 4763cb1 to get more accurate results.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

see 27 files with indirect coverage changes

@@            Coverage Diff             @@
##             main   #18812      +/-   ##
==========================================
- Coverage   68.75%   68.72%   -0.03%     
==========================================
  Files         420      420              
  Lines       35522    35522              
==========================================
- Hits        24422    24412      -10     
- Misses       9669     9680      +11     
+ Partials     1431     1430       -1     

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6883308...4763cb1. Read the comment docs.

[ahrtr]

With this approach, running it after a DRY run will yield the error:

In workspace '/tmp/etcd-release-3.5.124/etcd' the branch: release-3.5 diverges from the origin.
Consider cleaning up / renaming this directory or (cd /tmp/etcd-release-3.5.124/etcd && git reset --hard origin/release-3.5)

Probably I was missing something. Why we did not see this issue previously when we were releasing 3.5.x together?

However, I feel the best experience would be to replace:

    run git checkout "${BRANCH}" || exit 2
    run git pull origin

With a fetch and the hard reset to avoid manual intervention

Sounds good to me. But leave it to you and James to decide it.

[ivanvc]

Probably I was missing something. Why we did not see this issue previously when we were releasing 3.5.x together?

The issue is that instead of erroring out, it silently doesn't change the directory. The only way to catch it is by reading the log lines and noticing that it skips changing the directory. Given the number of log lines the release script generates, it is difficult to catch.

The temp directory it creates follows the pattern: /tmp/etcd-{release_version}. If we first run the release script with DRY=true, but a fictitious version (i.e., v3.5.99) as we've been doing, then running again with DRY=false and the actual version won't present the issue. It could be that maybe the team was aware of this limitation, and we were running it with an unreal version. cc. @jmhbnz.

/retest

[ahrtr]

The issue is that instead of erroring out, it silently doesn't change the directory. The only way to catch it is by reading the log lines and noticing that it skips changing the directory. Given the number of log lines the release script generates, it is difficult to catch.

Usually there isn't any issue as long as the tag was successfully created, because the release script will checkout the tag anyway (see code link below). But theoretically there is a potential issue if the /tmp/etcd-release-${VERSION} was created but the tag wasn't created (unlikely in practice), and the release process was somehow interrupted, then when running it again, it might update the version.go and create tag on the wrong branch.

Thanks for the good catch!

etcd/scripts/release.sh

Lines 107 to 110 in 98e53e5

	if [ "${remote_tag_exists}" -gt 0 ]; then
	log_callout "Release version tag exists on remote. Checking out refs/tags/${RELEASE_VERSION}"
	git checkout -q "tags/${RELEASE_VERSION}"
	fi

[ahrtr]

LGTM

Thank you!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahrtr, ivanvc

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:

• OWNERS [ahrtr]

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