fix: descriptive tag description on closed pull request.

[missionmike]

Description

Tests revised process for closed pull request tagging.

---

Important

Adds trigger for closed pull requests and prevents duplicate runs on merged PRs in tag-version.yml.

• Workflow Trigger:
  • Adds pull_request trigger with types: [closed] in .github/workflows/tag-version.yml.
  • Ensures workflow runs on closed pull requests.
• Conditional Execution:
  • Adds condition to tag-version job to prevent duplicate runs on merged PRs by checking commit message pattern in .github/workflows/tag-version.yml.

^{This description was created by for 1a9ece5. You can customize this summary. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ampdresume	🔄 Building (Inspect)	Visit Preview	💬 Add feedback	Aug 2, 2025 5:19am

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 1a9ece5 in 1 minute and 11 seconds. Click for details.

• Reviewed 22 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/tag-version.yml:4

• Draft comment:
  Consider filtering pull_request events to run only when the PR has been merged (e.g. using github.event.pull_request.merged) to avoid triggering version bumps on closed, unmerged PRs.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment suggests a change that would actually break the intended functionality. The workflow is deliberately set up to run on all PR closes and non-merge pushes. The if condition on line 15 handles the duplicate execution case. Running version bumps on unmerged PRs might be intentional - perhaps to track attempted but rejected changes. I could be wrong about the intention to run on unmerged PRs - maybe it really is an oversight that could cause unwanted version bumps. The careful conditional logic and comments in the code strongly suggest this behavior is intentional, not an oversight. The workflow has specific handling for PR vs non-PR cases throughout. The comment should be deleted as it suggests changing behavior that appears to be intentionally designed this way, with proper handling of edge cases already in place.

2. .github/workflows/tag-version.yml:15

• Draft comment:
  The job-level condition relies on commit messages starting with 'Merge pull request'. This may not cover all merge scenarios. Consider refining this check or using explicit event properties for more robust filtering.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is speculative - it says "may not cover" without providing specific scenarios or evidence. The current logic handles the standard GitHub PR merge commit format. While there could be edge cases, the comment doesn't identify any concrete issues. The code has a clear comment explaining its purpose of avoiding duplicate runs. The comment might have a point that there are other merge scenarios like squash merges or rebase merges that could behave differently. While true, the current logic handles the default GitHub merge commit case, and the comment doesn't provide actionable alternatives or specific scenarios where it would fail. Delete the comment as it's speculative and doesn't provide concrete evidence of an actual problem or actionable improvements.

Workflow ID: wflow_oqLM55Da8fKPDGMq

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}