3 ms·

I would love to use this at $daywork, but it has the unfortunate limitation that the merge group needs to pass the same checks as the branch itself, making it d

I would love to use this at $daywork, but it has the unfortunate limitation that the merge group needs to pass the same checks as the branch itself, making it doubly expensive (esp. with something like Chromatic that is susceptible to flakiness and might need manual approval). I would love to be able to set different sets of checks that need to pass to add a PR to a merge group, and to the merge group itself to be merged, so we can better manage speed and cost.

esprehn 3y ago
Where do you see that limitation? The docs say there's a separate event for merge_group which I assume means you can configure different checks. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions https://docs.github.com/en/repositories/configuring-branches...
- mfenniak 3y ago
  The branch protection rules that you apply are both used to determine if you can add a PR to the merge queue, and if the merged commit passes the merge queue checks and is OK. This isn't documented, but based upon experience using the beta.
  - masklinn 3y ago
    If the events triggering the jobs are different you can handle that there e.g. immediately succeed on a pr and actually validate on a queue or the reverse.
mnahkies 3y ago
Another option to workaround this could be to skip/noop checks based on the branch name prefix
mfenniak 3y ago
I was surprised by this weird limitation as well. However I found its easy to workaround -- I made my CI checks provide the skipped status when they run on the PR, and then provide the success/failure status when they run on the merge-queue branch. In a GitHub Action, this is was very easy: on: pull_request: merge_group: jobs: build: name: Whatever... if: github.event_name == 'merge_group' Then the task "Whatever" can be added as a required status check, and "skipped" is good enough to allow it to function on the PR side while it actually executes on the merge queue.
andrewaylett 3y ago
If you can cache heavily enough, the cost of a no-change re-run is effectively zero. Actually getting to that point can be quite hard. But it's definitely possible. But also, if there's any change then you want to re-run anything that depends on the change. Limiting the rebuild to only things that have changed also take effort. But it's really worth it for the benefits you reap, both in CI and in development -- if your edit-compile-test cycle is long enough that an extra CI run is annoying, it's long enough to be detrimental in every day development.

esprehn 3y ago

Where do you see that limitation? The docs say there's a separate event for merge_group which I assume means you can configure different checks. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions https://docs.github.com/en/repositories/configuring-branches...

mfenniak 3y ago
The branch protection rules that you apply are both used to determine if you can add a PR to the merge queue, and if the merged commit passes the merge queue checks and is OK. This isn't documented, but based upon experience using the beta.
- masklinn 3y ago
  If the events triggering the jobs are different you can handle that there e.g. immediately succeed on a pr and actually validate on a queue or the reverse.

mnahkies 3y ago

Another option to workaround this could be to skip/noop checks based on the branch name prefix

mfenniak 3y ago

I was surprised by this weird limitation as well. However I found its easy to workaround -- I made my CI checks provide the skipped status when they run on the PR, and then provide the success/failure status when they run on the merge-queue branch. In a GitHub Action, this is was very easy: on: pull_request: merge_group: jobs: build: name: Whatever... if: github.event_name == 'merge_group' Then the task "Whatever" can be added as a required status check, and "skipped" is good enough to allow it to function on the PR side while it actually executes on the merge queue.

andrewaylett 3y ago

If you can cache heavily enough, the cost of a no-change re-run is effectively zero. Actually getting to that point can be quite hard. But it's definitely possible. But also, if there's any change then you want to re-run anything that depends on the change. Limiting the rebuild to only things that have changed also take effort. But it's really worth it for the benefits you reap, both in CI and in development -- if your edit-compile-test cycle is long enough that an extra CI run is annoying, it's long enough to be detrimental in every day development.