bors-ng is being retired about wg HOT 11 OPEN

Hopefully there ends up being a neater way than the jq snippet though...

To add perspective: For the knurling-rs repositories we also did aggregate the multiple jobs into one for bors. But now we removed this check and just mark all checks as required in the branch protection rules.

from wg.

features we'd particularly miss include bors try

I don't think there is much to miss about bors try. CI should just run on every commit, GitHub Actions has a concurrency option to allow cancelling CI for previous commits (in case of long-running CI matrices).

and bors d+

You can have somewhat similar behaviour if you don't dismiss approvals when new commits are pushed. That would be the same as doing bors d+ on every approved PR though and probably not an option in combination with auto-merge.

from wg.

I don't think there is much to miss about bors try. CI should just run on every commit, GitHub Actions has a concurrency option to allow cancelling CI for previous commits (in case of long-running CI matrices).

The slight difference is that bors try runs CI on the merge commit to master, rather than on the PR branch commit. Still, I don't think this is usually an issue.

from wg.

The slight difference is that bors try runs CI on the merge commit to master, rather than on the PR branch commit. Still, I don't think this is usually an issue.

I believe GH Actions supports running CI on the resultant merge commit. See the original issue for it here: actions/checkout#15 The one limitation that I think exists is that it won't force a re-run if the target branch changes.

Note that I haven't used this feature since all the GH Actions I typically work on at day job enforce fast-forward merges only which removes this risk.

from wg.

The slight difference is that bors try runs CI on the merge commit to master

That's also the case when using the merge queue feature, which will catch this when actually trying to merge it, right?

from wg.

One thing when migrating I just encountered, bors interprets a skipped required check as failed, merge queue sees it as a success.

We aggregate the bunch of jobs needed into one check for bors to check, and if a need fails that check will be marked as skipped, hence merge queue will complete.

The way to fix this is to do

    if: always()
    steps:
      - run: jq --exit-status 'all(.result == "success")' <<< '${{ toJson(needs) }}'

to check that all needs are success

made a note here

from wg.

Thanks for catching that, good point. Hopefully there ends up being a neater way than the jq snippet though...

I've noticed another difference: currently we usually configure bors to not allow merging if certain labels (like needs-decision) are present, but afaict there's no way to do anything similar with GH branch protection or merge queues. The labels haven't been that important to us recently really so it's probably not a huge concern.

Edit: we were using bors to delete branches once they're merged, but GitHub now has a setting for this too.

from wg.

Did you have to check them one by one? I haven't found a "check all" button. Therefore, the "all in one" job is still handy.

Also, do you have optional checks? For instance, nightly builds or nightly clippy. For riscv, those checks are now allowed to fail.

from wg.

Did you have to check them one by one? I haven't found a "check all" button. Therefore, the "all in one" job is still handy.

That is true. I needed to check them individually, but in our case this isn't too much.

Also, do you have optional checks? For instance, nightly builds or nightly clippy. For riscv, those checks are now allowed to fail.

We don't. Are you saying that you decided that it is okay if they fail or that through the switch to the merge queue they are no allowed to fail?

from wg.

Maybe I'm wrong, but what I understand from here is that the matrix marks nightly-related jobs as experimental, so even if one or more of these fail, the workflow is allowed to "succeed". However, the stable and the MRSV builds MUST succeed.

from wg.

notriddle posted some more information here for the plan

There are a few things that I'd like to see happen, which means it's not scheduled, but it is planned:

• I'd like to see GitHub's built-in Merge Queue leave beta.
• I'd like to see GHMQ become available on personal repos.
• I'd like to see some of the bigger projects that use the public bors-ng instance switch to either self-hosting or GHMQ.
• I'd like to see someone launch a fork of this project (I'm not handing control of the public instance over to anybody, though; that would be irresponsible).

I'll be waiting for most of these things to happen, but not necessarily all of them.

from wg.