Auto-merge ruby-builder-bot PRs

[flavorjones]

This PR is trying to drive the conversation from https://bugs.ruby-lang.org/issues/21804.

I don't think that it's a good idea to auto-merge on a project so critical in the Ruby supply chain. For a foundational action that runs across thousands of CI pipelines, the blast radius of a bad merge is huge.

Auto-merge might be reasonable, but only if it’s tightly scoped to low-risk, mechanically generated changes with strong guardrails (which this PR has tried to do); but if ruby-builder-bot gets compromised then it's game over for the Ruby supply chain.

Pros:

• Faster propagation of routine updates (e.g., version lists, metadata bumps) without maintainer latency.
• Less maintainer toil on high-frequency bot PRs.
• More consistent update cadence and fewer stale PRs.

Cons:

• Single-point-of-failure risk: a compromised bot or supply-chain attack can push a bad change quickly to many downstream users.
• Reduced human review on changes that may have subtle security or correctness impacts.
• Harder to detect abuse if tests can be manipulated or if the update surface grows over time.

[p-linnane]

Thanks for taking the time to open this PR to move the discussion forward, even though you’re understandably skeptical of the approach. I share your concerns.

For context, I’m a lead maintainer for Homebrew, where we make extensive use of automerging across our repositories, but only with significant guardrails. Our merge process is more complex than setup-ruby, but automerge is never fully hands-off. It only occurs after explicit human review and approval.

Given the critical role setup-ruby plays in the Ruby supply chain, I think a better path forward is increasing the number of people involved in release management, rather than further reducing human oversight. Adding release managers, as @eregon suggested on the bug tracker, seems like a safer and more sustainable solution.

[eregon]

Suggested change

	--squash \
	--rebase \

Because I always use Rebase and merge in this repo

[eregon]

Adding release managers, as @eregon suggested on the bug tracker, seems like a safer and more sustainable solution.

To be clear, it's already the case since @hsbt released 4.0.0. It's up to him whether he is OK with that extra work mentioned in https://bugs.ruby-lang.org/issues/21804#note-2.

[eregon]

This looks good to me.
I would add automatically releasing after the PR is merged (would be nice if we can reuse https://github.com/ruby/setup-ruby/blob/master/.github/workflows/release.yml by "calling it"), otherwise it would still need a manual step.

I think the main downside I see is if master is somehow "broken" yet CI passes and some automated PR is made, merged & released then it can break @v1. But that should be very rare.
There can also be the problem that multiple automated PRs are made and they pass CI but then they are effectively not tested together.

Cons:

• Single-point-of-failure risk: a compromised bot or supply-chain attack can push a bad change quickly to many downstream users.

I'll check if ruby-builder-bot has 2FA and if not add it.
Assuming it's not possible to login as ruby-builder-bot illegitimately, what are other risks/example attacks?

• Reduced human review on changes that may have subtle security or correctness impacts.

I think it would be good to add a guard that only some files are modified, specifically:
Looking at https://github.com/ruby/setup-ruby/pull/844/files

• README.md
• ruby-builder-versions.json
• dist/index.js (which is checked in CI to be matching)

Those are very low risk, i.e. any attacker editing those AFAIK still couldn't do anything bad with it except making workflow fails (e.g. by removing a version). They are all metadata files (.json/.md), or checked generated files, no code.
We still need to validate the contents of ruby-builder-versions.json so it's only basenames and e.g. no /.

And for Windows:
Looking at https://github.com/ruby/setup-ruby/pull/847/files

• windows-toolchain-versions.json
• windows-versions.json

Those need some validation (or a refactor), because they contain URLs.
We could check these URLs start with https://github.com/ruby/setup-msys2-gcc/releases/ / https://github.com/oneclick/rubyinstaller2/releases/download/ in e.g. windows.js.
But that's prone to "URL injection" so we should also only have basenames there, and validate them.

@flavorjones Maybe you could amend the PR to check only those 5 files are modified?

• Harder to detect abuse if tests can be manipulated or if the update surface grows over time.

The check for modified files should address that. I don't expect the update surface to grow, it hasn't in a long time.

[flavorjones]

I would like to see where the conversation in https://bugs.ruby-lang.org/issues/21804 goes before investing more time in this PR. If it's determined that auto-merging and auto-releasing is an acceptable path, I would be happy to make some of the changes suggested.