Skip to content

fix: use built-in token for rolling PR workflow #105

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
namastex888 merged 1 commit into from
May 31, 2026
Merged

fix: use built-in token for rolling PR workflow #105

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 17 additions & 8 deletions .github/workflows/rolling-pr.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,12 +20,24 @@ jobs:
steps:
- name: Check/Create Rolling PR
env:
GH_TOKEN: ${{ secrets.RELEASE_PLEASE_TOKEN }}
# Use the built-in workflow token. A stale custom token should not make
# the release-boundary helper fail with 401 on scheduled runs.
GH_TOKEN: ${{ github.token }}
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot May 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Use an app/PAT token so PR CI runs automatically

For the scheduled path that creates a new dev -> main PR, replacing the PAT with ${{ github.token }} means the repository's pull_request workflows (.github/workflows/ci.yml and commitlint.yml, both filtered to main/dev) will not run automatically; GitHub documents that PRs created/updated with GITHUB_TOKEN put resulting pull_request runs in an approval-required state, while a GitHub App token or PAT lets them run automatically (https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow#triggering-a-workflow-from-a-workflow). That breaks the rolling PR's intended unattended check/ready state after creation until someone manually approves the workflows.

Useful? React with 👍 / 👎.

run: |
PR=$(gh pr list --repo ${{ github.repository }} --base main --head dev --state open --json number --jq '.[0].number')
set -euo pipefail

if [ -z "$PR" ]; then
gh pr create --repo ${{ github.repository }} \
PR=$(gh pr list --repo ${{ github.repository }} --base main --head dev --state open --json number --jq '.[0].number // ""')
if [ -n "$PR" ]; then
echo "Rolling PR #$PR exists and is up to date"
exit 0
fi

if [ "$(gh api repos/${{ github.repository }}/compare/main...dev --jq '.ahead_by')" = "0" ]; then
echo "dev has no commits ahead of main; no rolling PR needed"
exit 0
fi

gh pr create --repo ${{ github.repository }} \
--base main --head dev \
--title "chore: rolling promotion dev -> main" \
--body "$(cat <<'BODY'
Expand All @@ -49,7 +61,4 @@ jobs:
> Human approval required for merge to production.
BODY
)"
echo "Created new rolling PR"
else
echo "Rolling PR #$PR exists and is up to date"
fi
echo "Created new rolling PR"
4 changes: 3 additions & 1 deletion docs/release-contract.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,9 @@ The npm package is SDK-only:

## Main release boundary

`main` is the canonical release branch.
`main` is the canonical release branch and the expected branch for long-lived production checkouts such as `/home/genie/prod/rlmx`.

Use short-lived `drogo/<topic>` branches for focused source changes, then return the production checkout to `main` after merge/dogfood. Do not keep a long-lived `drogo/prod-rlmx` branch as the install/update authority.

A release happens when a PR merges from `dev` to `main`:

Expand Down
Loading