Repository navigation
Request new github-bot token for nodejs/nodejs.org聽#1049
Description
馃憢 Looking for a new token to be added to nodejs/nodejs.org as AUTO_MERGE_GITHUB_TOKEN, with permissions to read + write Contents and Pull requests.
Looks like the org sets a 1 year limit on tokens, so this will also need to be regenerated every year by admin, please.
Activity
MattIPv4 commentedon Apr 5, 2026
馃憢 If it is possible/acceptable, could the same token be extended to also include (and be added as a secret in):
nodejs/doc-kitnodejs/learnnodejs/release-cloudflare-workernodejs/discord-status-workernodejs/website-cloudflare-workernodejs/web-teamThis is to support the auto-merge automation we're using in all of these repositories, to ensure that the actor for the merging is not GitHub Actions, so that it can trigger CI for merge queues, and once merged to the default branch.
If not, we'll need to request/create fine-grained tokens for each of these repositories -- if this is the desired route, we can start with just
nodejs/nodejs.orgper the initial request to confirm this works, and then create the other tokens after.avivkeller commentedon Apr 5, 2026
fyi @nodejs/TSC
legendecas commentedon May 22, 2026
I didn't see any concerns. Would you mind opening a PR following the guide https://github.com/nodejs/admin/blob/main/request-an-access-token.md?
MattIPv4 commentedon May 23, 2026
Ah my bad, had completely missed that doc. Created #1066, ty!
legendecas commentedon May 23, 2026
@MattIPv4 Sorry I misunderstood the motivation of this request. It seems the intention is using a bot to manage an automatic merge queue?
Have https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue been considered to be an option?
MattIPv4 commentedon May 23, 2026
We use a merge queue, but have a policy that PRs must be open for 48hrs before being merged -- this automation handles adding the PRs to the queue to be merged after they've been open for 48hrs, assuming they are approved.
legendecas commentedon May 23, 2026
Can this be achieved with one single workflow with a single token?
MattIPv4 commentedon May 23, 2026
I don't think it can easily be done with a single workflow, as some of our repos need the workflow to direct merge and others need it to add to a merge queue -- I think it could be a single token that has access to all the repos though as I noted above, which all the workflows in each repo use.
legendecas commentedon May 23, 2026
Could all auto-merge workflows like https://github.com/nodejs/nodejs.org/blob/main/.github/workflows/auto-merge.yml be hosted in https://github.com/nodejs/web-team/, using a single cron job? I don't think managing a single token being used across multiple repos would be a security good practice. Also I'm concerning about creating a bunch of tokens with
content: write.MattIPv4 commentedon May 23, 2026
馃 Hm, I think that would be possible, but quite confusing to have an action that is acting cross-repo -- my gut is that I'd prefer to keep things isolated to each repo, and agree on having a single token across multiple repos not being great, so keeping the workflows in each repo each with its own token keeps things much more isolated if one were to be leaked.
legendecas commentedon May 24, 2026
The maintenance of 7 tokens across 7 repos for merging PRs automatically is not trivial though. If these tokens are for releases, I would be more open to it as it's necessary. But I don't think an automatic PR merger justifies the cost here.
MattIPv4 commentedon May 24, 2026
I'd disagree there, we often end up with security fixes and dependency updates not being merged because folks approve the PRs and then forget about merging them multiple days later -- I really don't see how there is a significant "cost" to the 5-10 minutes it will take to create + save these tokens once per year?
The more I've considered the suggestion of a single workflow for this, the more I do not think it is a good idea. That makes the blast radius rather significant if that were to be compromised, including both the website + the worker that serves all downloads -- I really think this should be individual tokens for individual workflows to keep things isolated.