chore(master): release 1.5.0#15
Merged
Merged
Conversation
Contributor
Author
|
🤖 Created releases: 🌻 |
6 tasks
mlorentedev
added a commit
that referenced
this pull request
May 18, 2026
## Summary PRs opened by the default `GITHUB_TOKEN` do not trigger `pull_request` workflows — GitHub suppresses these events to prevent infinite recursion when one workflow creates a PR that would trigger another. With branch protection on `master` requiring `test` / `lint` / `security` status checks, the auto-generated `release-please` PR ends up in `BLOCKED` state with no CI ever running. This is what hit us today on PR #19 (v1.5.1). The previous release PR #15 (v1.5.0) silently dodged the issue because something retriggered CI manually 11 minutes after the PR opened (likely a UI "Update branch" click). ## Fix Pass an explicit PAT to `release-please-action` via the `token:` input. PRs created with a PAT appear as user-driven events to GitHub, so the `pull_request` trigger fires normally. ```yaml token: ${{ secrets.RELEASE_PLEASE_PAT || secrets.GITHUB_TOKEN }} ``` The `||` fallback to `GITHUB_TOKEN` means this PR is safe to merge **before** the secret is configured — the workflow keeps using the legacy behavior until the PAT is added. No disruption. ## Setup checklist (one-time, after merging this PR) - [x] Generate a [fine-grained PAT](https://github.com/settings/personal-access-tokens/new): - **Repository access:** Only select `mlorentedev/ts-bridge` - **Permissions:** - `Contents`: Read and write - `Pull requests`: Read and write - `Workflows`: Read and write *(only if a release PR ever changes a `.github/workflows/*` file — uncommon)* - **Expiration:** 1 year recommended, with calendar reminder - [x] Add it as repo secret `RELEASE_PLEASE_PAT` (Settings → Secrets and variables → Actions → New repository secret) - [x] On the next release PR, verify CI fires automatically (no close+reopen dance) ## Alternatives considered (rejected) | Option | Why rejected | |---|---| | Switch `ci.yml` to `pull_request_target` | Exposes base-branch secrets to PR code — unsafe surface for `test`/`lint` jobs | | Empty commit / close+reopen on each release | Manual toil per release; defeats the point of automation | | Drop branch protection on `master` | Loses the safety net for human PRs too | | Use a dedicated GitHub App | Heavier setup; PAT is sufficient for a single-maintainer repo | ## Test plan - [x] `go vet ./...` clean (no Go changes, just the workflow) - [x] CI on this PR runs the standard checks - [x] After merge + secret setup, manually run release.yml on master or wait for the next `fix:`/`feat:` to verify the next release PR has CI checks attached at creation time
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 I have created a release beep boop
1.5.0 (2026-03-08)
Features
This PR was generated with Release Please. See documentation.