Verify tag commit is reachable from master before release

[nanotaboada]

Summary

Add a runtime verification step to the CD workflow (.github/workflows/dotnet-cd.yml) that checks whether the tag's commit is reachable from master before proceeding with build and publish steps. This ensures the CD pipeline does not trigger on an unmerged commit if a tag is accidentally pushed from a release branch before the PR is merged.

Motivation

The CD workflow currently triggers on any tag matching v*.*.*-* with no safeguard that the tag points to a commit contained in master. The Pre-Release Checklist enforces process discipline (merge before tagging), but a runtime guard in the workflow would provide an additional safety net.

Proposed Approach

Add a step named "Verify tag commit is reachable from master" to the existing release job, placed immediately after Checkout repository. A separate job is not warranted here — the checkout already uses fetch-depth: 0 so full git history is available, and the check is lightweight enough that spinning up a second runner would be unnecessary overhead.

The step should verify that ${{ github.sha }} is reachable from refs/heads/master using either:

• git branch -r --contains ${{ github.sha }} and checking for origin/master in the output, or
• The GitHub API to confirm the commit is an ancestor of refs/heads/master

The job should fail with a clear error message if the check does not pass.

Acceptance Criteria

• Workflow fails early with a descriptive error if the tag commit is not reachable from master
• No regressions on valid release tags pushed from a merged commit
• Step is placed before any build, test, or publish steps

[coderabbitai]

🔗 Related PRs

#236 - chore(ci): limit container job to master branch pushes [merged]
#357 - feat: implement tag-based deployment with stadium release names (#356) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Add a single verification step using git merge-base --is-ancestor to check tag commit reachability from master
• Place the step immediately after checkout and before any validation, build, or publish steps
• Fail fast with a clear, actionable error message if the commit is not in master's history
• Follows existing workflow patterns: shell script run block with echo for error messaging

Design Choices

Design Choice 1: Which git command approach should be used for the reachability check?

Options Considered:

1. git branch -r --contains ${{ github.sha }} with grep for origin/master — requires output parsing, can be slow with many branches
2. GitHub API call to check commit ancestry — adds external dependency, requires token handling, more complex
3. git merge-base --is-ancestor ${{ github.sha }} origin/master — returns direct exit code, fast, standard git idiom for ancestry checks

Chosen Option: 3

Rationale: git merge-base --is-ancestor is the canonical git command for checking if one commit is an ancestor of another, returns a clean exit code without output parsing, and aligns with the existing pattern of using native git commands in this workflow.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Add Tag Commit Reachability Verification Step

Add a lightweight verification step to the release job that validates the tagged commit exists in master's history before any build or publish activity occurs. This ensures the CD pipeline fails fast with a clear message if someone accidentally tags an unmerged commit.

Insert Verification Step After Checkout

Add a new step to the release job in .github/workflows/dotnet-cd.yml that verifies the tag commit is reachable from master.

• Insert new step immediately after "Checkout repository" (before "Extract version from tag")
• Name the step "Verify tag commit is reachable from master" as specified in the ticket
• Use git merge-base --is-ancestor ${{ github.sha }} origin/master to check if the tagged commit is an ancestor of master
• On failure (non-zero exit), output a descriptive error message explaining that the tag points to a commit not yet merged to master, then exit with failure code
• On success, optionally echo a brief confirmation message for workflow logs (e.g., "Verified: commit is reachable from master")
• The step needs no special permissions or setup since fetch-depth: 0 on the checkout already provides full git history and all remote refs

🤖 Prompt for AI agents

Add a new verification step to the `release` job in
`.github/workflows/dotnet-cd.yml` to ensure the tagged commit is reachable from
`master` before any build or publish activity.

- Insert the new step immediately after the "Checkout repository" step and
before the "Extract version from tag" step
- Name the step: `"Verify tag commit is reachable from master"`
- Implement the step as a shell script `run` block using `git merge-base
--is-ancestor ${{ github.sha }} origin/master` to check ancestry
- If the command returns a non-zero exit code (failure), output a descriptive
error message indicating the tag points to a commit not yet merged to master,
then exit with a failure code
- If the command succeeds, optionally echo a brief confirmation message (e.g.,
`"Verified: commit is reachable from master"`) for workflow log visibility
- No additional permissions or setup are needed — the existing `fetch-depth: 0`
on the checkout step already ensures full git history and all remote refs are
available

Research

The project uses GitHub Actions for CI/CD, with the CD workflow defined in .github/workflows/dotnet-cd.yml. The workflow triggers on version tags matching v*.*.*-* and runs a single release job that checks out the repository (with fetch-depth: 0 for full history), validates the tag format, builds the .NET project, runs tests, and publishes a Docker image plus GitHub Release. The existing pattern for validation is shell script run blocks that fail with clear error messages, as seen in the "Extract version from tag" step.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Add a new verification step to the `release` job in
`.github/workflows/dotnet-cd.yml` to ensure the tagged commit is reachable from
`master` before any build or publish activity.

- Insert the new step immediately after the "Checkout repository" step and
before the "Extract version from tag" step
- Name the step: `"Verify tag commit is reachable from master"`
- Implement the step as a shell script `run` block using `git merge-base
--is-ancestor ${{ github.sha }} origin/master` to check ancestry
- If the command returns a non-zero exit code (failure), output a descriptive
error message indicating the tag points to a commit not yet merged to master,
then exit with a failure code
- If the command succeeds, optionally echo a brief confirmation message (e.g.,
`"Verified: commit is reachable from master"`) for workflow log visibility
- No additional permissions or setup are needed — the existing `fetch-depth: 0`
on the checkout step already ensures full git history and all remote refs are
available

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!