ci(release): bump toolkit pin for merge-subject fix + add validate recovery dispatch#293
Conversation
…covery dispatch Pins the shared workflows to d7dad49 (v3), which restores the 2.18.1-era acceptance of the bare generated title as a squash-merge subject - the check that failed 2.19.3's post-merge validation after the release PR was merged with the repo's default 'pull request title' squash message. Adds workflow_dispatch (pr-number) to the trigger stub so an already- merged release PR can be re-validated after such a fix. The reusable workflow re-derives everything from the PR number and fails closed.
Deploying podnotes with
|
| Latest commit: |
0619ee3
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d0b5a9ac.podnotes.pages.dev |
| Branch Preview URL: | https://ci-toolkit-pin-d7dad49.podnotes.pages.dev |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0619ee38c1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| validate: | ||
| if: >- | ||
| github.event.pull_request.merged == true && | ||
| github.event_name == 'workflow_dispatch' || |
There was a problem hiding this comment.
When this manual path is used to recover an already-merged release PR after a workflow fix, the run starts from the selected workflow ref (normally the new master HEAD containing this change). The pinned release-validate.yml@d7dad49... workflow still receives EVENT_SHA=${{ github.sha }} and rejects the run unless it exactly equals that PR's merge_commit_sha; because this workflow_dispatch addition must land after the failed release merge, master HEAD cannot be the old release PR merge commit. As a result, the documented gh workflow run release-trigger.yml -f pr-number=291 recovery path fails before it can dispatch the release.
Useful? React with 👍 / 👎.
1 participant
Two things to recover release 2.19.3 (PR #291, merged but failed post-merge validation):
obsidian-plugin-workflows@d7dad49(v3), restoring the bare-generated-title acceptance this repo already had at 2.18.1 (b2a1ea6) and lost in the shared-pipeline extraction. Upstream fix: fix: accept the bare generated title as a release merge subject obsidian-plugin-workflows#8.workflow_dispatchwith apr-numberinput, so the already-merged release(version): Release 2.19.3 #291 can be re-validated. The reusable validate workflow re-derives all provenance from the PR number and fails closed, so this adds no authority a merged-PR event didn't have.After merge:
gh workflow run release-trigger.yml -f pr-number=291resumes 2.19.3.