fix(ci): allow overwriting existing release tags on re-runs

[wuhuizuo]

No description provided.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[pingcap-cla-assistant]

All committers have signed the CLA.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Summary
This PR enhances the weekly release GitHub Actions workflow by allowing overwriting existing release tags on reruns. It switches the contents permission to write (necessary for tag creation), adds safety flags (set -euo pipefail), and implements logic to delete the local and remote tags if they already exist before creating and pushing new tags. The approach is straightforward and effectively addresses the problem of rerun failures due to existing tags. The changes are clear and mostly well-structured.

---

Critical Issues

• Incorrect tag existence check
  • File: .github/workflows/weekly-release.yaml, lines ~63-66
  • Issue: The command git tag -l "$TAG_NAME" > /dev/null 2>&1 always succeeds (exit code 0) even if the tag doesn't exist because git tag -l lists tags and returns success if the command runs correctly, not based on matching tags. This means the condition is always true, and the local tag will always be deleted even if it doesn't exist.
  • Suggested fix: Use git rev-parse or git show-ref to check for tag existence more reliably, e.g.:

    if git rev-parse "$TAG_NAME" >/dev/null 2>&1; then
      git tag -d "$TAG_NAME" || true
    fi

    or

    if git show-ref --tags --quiet --verify "refs/tags/$TAG_NAME"; then
      git tag -d "$TAG_NAME" || true
    fi

---

Code Improvements

• Add error handling for remote tag deletion

  • File: .github/workflows/weekly-release.yaml, lines ~70-72
  • Issue: The command git push origin :refs/tags/"$TAG_NAME" 2>/dev/null || true suppresses all errors silently. While this is intentional to allow the step to continue, it might mask genuine errors such as authentication failures or network issues.
  • Suggested fix: Consider logging the error output for visibility or handle failure cases separately. Example:

    if ! git push origin :refs/tags/"$TAG_NAME"; then
      echo "Warning: Failed to delete remote tag $TAG_NAME. It may not exist or there might be network issues."
    fi

• Use consistent quoting for shell variables

  • File: .github/workflows/weekly-release.yaml, multiple lines
  • Issue: Some variables are quoted while others are not ($TAG_NAME vs "$TAG_NAME"). Best practice is to always quote variables unless word splitting is desired.
  • Suggested fix: Ensure all variable references are quoted, e.g.:

    git tag -a "$TAG_NAME" -m "Weekly release $TAG_NAME"
    git push origin "$TAG_NAME"

• Consider adding a check before creating a release

  • File: .github/workflows/weekly-release.yaml, lines ~74-79
  • Issue: The gh release create command will fail if a release with the tag already exists (even though the tag is deleted and recreated). This could happen if the release was manually created or if there's a race condition.
  • Suggested fix: Add logic to delete or update existing release using gh release delete or gh release edit before creating, or use gh release upload with --prerelease or --draft flags as appropriate.

---

Best Practices

• Add comments explaining the tag deletion logic

  • File: .github/workflows/weekly-release.yaml, lines ~65-73
  • Issue: The new logic to delete local and remote tags is not commented in detail explaining why it's necessary (e.g., to support reruns).
  • Suggested fix: Add a brief comment for maintainers:

    # Delete local and remote tags if they exist to allow overwriting tags on workflow reruns

• Testing coverage / manual validation reminder

  • Since this is a workflow change affecting releases, ensure that this has been tested on a dry run or a non-critical repo to confirm that tag deletion and recreation works as intended without side effects.

---

Overall, the PR fixes the problem and improves the workflow, but the check for existing tags should be corrected to avoid unnecessary tag deletions. Adding better error visibility and comments will improve maintainability.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Summary:
This PR modifies the GitHub Actions workflow (weekly-release.yaml) to allow overwriting existing release tags on reruns of the workflow. It changes repository permissions to enable write access, adds logic to delete local and remote tags if they already exist before creating new ones, and improves shell script robustness by adding set -euo pipefail. Overall, the changes are straightforward and focused on fixing the release tagging process on repeated runs. The implementation is clean, but there are some minor issues related to tag existence checks and error handling that could be improved.

---

Critical Issues

• Incorrect tag existence check (line 66-69):

  if git tag -l "$TAG_NAME" > /dev/null 2>&1; then
    git tag -d "$TAG_NAME" || true
  fi

  The command git tag -l "$TAG_NAME" outputs the tag name if it exists, but it always returns exit code 0, even if no tags match. Therefore, this if condition will always be true and attempt to delete the tag whether it exists or not. This can cause unnecessary errors or confusion.

  Suggested fix:
  Use git rev-parse or test output length to reliably check for tag existence:

  if git rev-parse "$TAG_NAME" >/dev/null 2>&1; then
    git tag -d "$TAG_NAME" || true
  fi

---

Code Improvements

• Improve remote tag existence check before deletion (line 74):
  The command:

  git push origin :refs/tags/"$TAG_NAME" 2>/dev/null || true

  blindly attempts to delete the remote tag but hides all errors. While this works, it would be cleaner and safer to check if the remote tag exists before deleting to avoid unnecessary pushes or confusion.

  Suggested enhancement:

  if git ls-remote --tags origin | grep -q "refs/tags/$TAG_NAME$"; then
    git push origin :refs/tags/"$TAG_NAME"
  fi

• Add comments to explain the tag deletion logic:
  Adding brief comments explaining why tags are deleted locally and remotely will improve maintainability and clarity for future contributors.

• Consider using --force with gh release create or gh release upload:
  If rerunning the workflow, the release might already exist, causing gh release create to fail. Consider checking for existing releases and updating them or using gh release upload with --clobber to overwrite assets.

---

Best Practices

• Add a brief PR description:
  The PR description is empty. Adding a short explanation about the problem being solved (allowing overwriting tags on reruns) would improve context for reviewers and future reference.

• Consider adding tests or dry-run steps:
  Although testing GitHub Actions workflows can be complex, adding a dry-run or echo step to confirm tag names and deletion commands before execution can help avoid destructive mistakes.

• Permissions scope:
  The permission scope was changed from contents: read to contents: write. Confirm that this is the minimal required scope for tagging and releasing; otherwise, consider scoping permissions more tightly. Document this permission change in the PR description.

---

Summary of key actionable suggestions:

- if git tag -l "$TAG_NAME" > /dev/null 2>&1; then
+ if git rev-parse "$TAG_NAME" >/dev/null 2>&1; then
     git tag -d "$TAG_NAME" || true
   fi

- git push origin :refs/tags/"$TAG_NAME" 2>/dev/null || true
+ if git ls-remote --tags origin | grep -q "refs/tags/$TAG_NAME$"; then
+   git push origin :refs/tags/"$TAG_NAME"
+ fi

Add comments around these blocks explaining the rationale. Also, consider checking for existing GitHub releases before creating new ones to prevent errors on reruns.

[wuhuizuo]

/approve

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wuhuizuo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [wuhuizuo]

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