Request new `github-bot` token for `nodejs/nodejs.org`

[MattIPv4]

👋 Looking for a new token to be added to nodejs/nodejs.org as AUTO_MERGE_GITHUB_TOKEN, with permissions to read + write Contents and 拉取请求.

Looks like the org sets a 1 year limit on tokens, so this will also need to be regenerated every year by admin, please.

[MattIPv4]

👋 If it is possible/acceptable, could the same token be extended to also include (and be added as a secret in):

• nodejs/doc-kit
• nodejs/learn
• nodejs/release-cloudflare-worker
• nodejs/discord-status-worker
• nodejs/website-cloudflare-worker
• nodejs/web-team

This 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 操作, 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.org per the initial request to confirm this works, and then create the other tokens after.

[avivkeller]

fyi @nodejs/TSC

[legendecas]

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]

Ah my bad, had completely missed that doc. Created #1066, ty!

[legendecas]

@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]

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]

Can this be achieved with one single workflow with a single token?

[MattIPv4]

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]

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]

🤔 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]

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]

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.