Make "Merge when ready" button always "work" about homebrew-core

[MikeMcQuaid]

I think having "this PR is ready to be added to the merge queue" indicated with 🟢 rather than 🟡 or 🔴 is a much nicer experience.

[Bo98]

Alternative thought: given merging requires approval, and approving itself triggers an automerge, we could make a status check that only passes once the bottle commit is added (or otherwise doesn't require a bottle commit) so that adding to the merge queue doesn't happen until that point.

Yes, @MikeMcQuaid had suggested this previously.

It's not my preferred solution since it makes status indicators on the PR list less informative. i.e. We don't know if a PR has an ❌ because it's failing or because it just has no bottles yet.

I would probably make it 🟡 rather than ❌ so failures show but yeah point noted for the ✅ case.

[Bo98]

Alternative thought: given merging requires approval, and approving itself triggers an automerge, we could make a status check that only passes once the bottle commit is added (or otherwise doesn't require a bottle commit) so that adding to the merge queue doesn't happen until that point.

[carlocab]

Alternative thought: given merging requires approval, and approving itself triggers an automerge, we could make a status check that only passes once the bottle commit is added (or otherwise doesn't require a bottle commit) so that adding to the merge queue doesn't happen until that point.

Yes, @MikeMcQuaid had suggested this previously.

It's not my preferred solution since it makes status indicators on the PR list less informative. i.e. We don't know if a PR has an ❌ because it's failing or because it just has no bottles yet.

[carlocab]

Yea, 🟡 is a lot more reasonable, and I would no longer opposed to it if we used 🟡. It would take some getting used to, though (but I can live with it if that's what others wanted to do).

[carlocab]

I think having "this PR is ready to be added to the merge queue" indicated with 🟢 rather than 🟡 or 🔴 is a much nicer experience.

This is ready to go at #173010. Just needs another review since I had to rework the approach.