ci: delete testing fork pre-releases using upstream tag names

[zimeg]

Summary

This PR uses either an upstream or fork PR branch when deleting a pre-release after a pull request is merged.

Fixes an issue where upstream tag names use different convention from forks and also where this workflow runs.

Requirements

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 62.89%. Comparing base (a1bcf9e) to head (3b01cd6).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #48   +/-   ##
=======================================
  Coverage   62.89%   62.89%           
=======================================
  Files         210      210           
  Lines       22147    22147           
=======================================
  Hits        13930    13930           
  Misses       7129     7129           
  Partials     1088     1088           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zimeg]

📝 Commit 7593a1b logs the REF from a pull request on the upstream as expected:

REF=zimeg-ci-delete-fork-prereleases-2

https://github.com/slackapi/slack-cli/actions/runs/14526446447/job/40758810974?pr=48

[zimeg]

📝 Commit e4dce67 logs the REF from a pull request on a fork branch as expected:

REF=pull-44-head

https://github.com/slackapi/slack-cli/actions/runs/14526503952/job/40758962739?pr=44

[zimeg]

📝 For reference of both above changes, existing prereleases follow similar patterns that'd be matched using semver prefixes:

• v3.0.4-zimeg-ci-delete-fork-prereleases-2
• v3.0.4-pull-46-head

[zimeg]

📣 A note on changes and findings in tests are included in comments both above and below for the kind reviewers.

[zimeg]

🔗 Attached is a link on running after PR merge:

https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#running-your-pull_request-workflow-when-a-pull-request-merges

[zimeg]

📝 An update removed the check that the PR merged since we're wanting to delete these pre-releases after any PR closes I believe

[mwbrooks]

✅ Nice and great approach to bringing both branch names into alignment!

[zimeg]

@mwbrooks Thanks so much. 🎁

I'm not so thrilled with the added lines here, but I believe this now lets us test branches from forks using pre-releases and clean things up afterwards. Let's test this in a few PRs soon though!

[zimeg]

📣 This PR pre-release was found and deleted!

Identified pre-release tagname to 🔪: v3.0.4-zimeg-ci-delete-fork-prereleases-2
...
Successfully deleted v3.0.4-zimeg-ci-delete-fork-prereleases-2

[zimeg]

🤔 A deleted PR from a forked branch failed:

Identified pre-release tagname to 🔪: v3.0.4-pull-42-head
...
HTTP 403: Resource not accessible by integration (https://api.github.com/repos/slackapi/slack-cli/releases/212933814)
Failed to find v3.0.4-pull-42-head, trying next...

Which might be due to the pull_request existing in the context of a forked PR. I believe pull_request_target is the ideal choice for a follow up:

This event runs in the context of the base of the pull request, rather than in the context of the merge commit, as the pull_request event does.