Skip to content

ci: re-enable tag_release workflow #451

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tsivaprasad merged 1 commit into from
Aug 6, 2026
Merged

ci: re-enable tag_release workflow #451

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions .github/workflows/tag_release.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
name: tag_release

# Temporarily disabled: v0.10.0 was tagged manually, so this must not
# fire again when the release/v0.10.0 PR is merged. Revert this in a
# follow-up PR against main once that PR is merged.
on:
workflow_dispatch: {}
pull_request:
types:
- closed
branches:
- main
Comment on lines +4 to +8

@coderabbitai coderabbitai Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Confirm whether merged branches are automatically deleted.
gh api "repos/${GITHUB_REPOSITORY}" --jq '.delete_branch_on_merge'

# Inspect configured merge strategies before validating the tag target.
gh api "repos/${GITHUB_REPOSITORY}" \
  --jq '{allow_merge_commit, allow_squash_merge, allow_rebase_merge}'

Repository: pgEdge/control-plane

Length of output: 208

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "REMOTE_GITHUB_REPOSITORY: ${REMOTE_GITHUB_REPOSITORY:-<not set>}"
echo "GITHUB_REPOSITORY: ${GITHUB_REPOSITORY:-<not set>}"
fd -a 'tag_release\.yaml$|\.ya?ml$' .github/workflows 2>/dev/null | sed 's#^\./##'
echo '--- tag_release workflow ---'
cat -n .github/workflows/tag_release.yaml

echo '--- repo settings via gh if repo is set ---'
repo="${GITHUB_REPOSITORY:-}"
if [ -n "$repo" ]; then
  gh api "repos/$repo" --jq '{
    delete_branch_on_merge: .delete_branch_on_merge,
    allow_merge_commit: .allow_merge_commit,
    allow_squash_merge: .allow_squash_merge,
    allow_rebase_merge: .allow_rebase_merge
  }' --fallback='{}'
else
  echo "GITHUB_REPOSITORY is not set, cannot query repo settings"
fi

echo '--- GitHub docs relevant statements via local text if available ---'
if [ -x "$(command -v gh)" ]; then
  gh repo view $repo --json mergeable,allowMergeCommit,allowSquashMerge,allowRebaseMerge,autoMergeAllowed --jq '
    "merge_commit=true squash=true rebase=true"
  ' 2>/dev/null || true
fi

Repository: pgEdge/control-plane

Length of output: 1645

🌐 Web query:

GitHub Actions pull_request closed head ref source branch deleted after merge documentation

💡 Result:

When a pull request is merged, GitHub automatically closes it [1]. Whether the head branch is deleted after a merge depends on your repository settings, not the GitHub Actions event itself [2]. GitHub provides an "Automatically delete head branches" setting in repository general settings that, when enabled, will delete the source branch once the pull request is merged. Regarding GitHub Actions and GITHUB_REF during this event: 1. GITHUB_REF Behavior: When a pull request is closed (with or without a merge), you can use the pull_request event with the closed activity type to trigger a workflow [1]. It is important to note that the value of GITHUB_REF changes based on whether the pull request was merged [3][4][1]. - If the pull request is closed but not merged, GITHUB_REF is set to refs/pull/PULL_REQUEST_NUMBER/merge [3][4][1]. - If the pull request is merged, GITHUB_REF is set to the fully qualified ref of the branch it was merged into (e.g., refs/heads/main) [3][4][1]. 2. Accessing Source Branch Information: Because GITHUB_REF may not point to your source branch after a merge, relying on it to perform cleanup tasks can lead to errors [5]. To safely identify the pull request information or access the source branch (if it still exists), you should use the context object provided by the event payload, such as ${{ github.event.pull_request.head.sha }} or ${{ github.event.pull_request.number }} [5][6]. 3. Branch Deletion: If you are writing a workflow to handle post-merge cleanup, ensure your logic does not assume GITHUB_REF is the head branch [5]. If the branch has already been deleted by GitHub's automatic cleanup, attempting to check out the head branch by name may fail unless you use fallback mechanisms, such as accessing the ref via refs/pull/NUMBER/head, which GitHub may keep available for a period [7].

Citations:

🌐 Web query:

GitHub Actions pull_request closed event github.sha after merge squash rebase merge documentation

💡 Result:

In GitHub Actions, the value of github.sha (and the GITHUB_SHA environment variable) for a pull_request event is the SHA of the temporary merge commit created by GitHub to simulate the pull request merge [1][2]. This behavior applies to the closed event as well [2][3]. Key points regarding the behavior of github.sha: 1. Temporary Merge Commit: For pull_request events, GitHub creates a surrogate merge commit representing the state of the pull request's head branch merged into the base branch [4][5][6]. The github.sha variable points to this specific commit [1][2]. 2. Independence of Merge Strategy: Because github.sha points to this temporary test merge commit, its value is generally consistent regardless of whether you ultimately use squash, rebase, or standard merge strategies to complete the pull request [7]. However, the actual merge commit created on your target branch after a squash or rebase will be a different, permanent commit [7]. 3. Retrieving the Head Commit: If you need the SHA of the actual latest commit from the pull request's head branch (rather than the test merge commit), you should use the context variable: ${{ github.event.pull_request.head.sha }} [1][5][2]. 4. Behavior on Closed Event: When a pull request is closed, the github.sha continues to represent the last known merge commit of the pull request merge branch [1][2]. If the pull request was merged, GITHUB_REF will point to the fully qualified reference of the target branch (e.g., refs/heads/main), but github.sha will still correspond to that last temporary merge commit [1][2]. For workflows that need to perform operations based on the actual head of the feature branch, always prefer github.event.pull_request.head.sha to ensure accuracy [8][5][9].

Citations:

Use the merged branch ref instead of the PR source branch.

pull_request closed events run after the PR is merged, but github.sha still points to the PR’s temporary merge commit for squash and rebase merges. Check out github.ref so the tag points at the branch that received the merged changes instead of the PR source branch.

Proposed fix 
-          ref: ${{ github.event.pull_request.head.ref }}
+          ref: ${{ github.ref }}
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/tag_release.yaml around lines 4 - 8, Update the checkout
configuration in the tag release workflow to use github.ref rather than
github.sha for closed pull_request events, ensuring releases resolve the branch
that received the merged changes. Keep the existing trigger restricted to merged
pull requests targeting main.


jobs:
tag_release:
Expand Down