I like how Bors pushes the changes into a “staging” branch before merging. It makes it easy to run expensive integration tests only at that point. It also supports timeouts and it is open source.
Thanks for the answer! Those features are also supported by Mergify; we call that two-step CI: https://docs.mergify.com/merge-queue/two-step/. And it also supports timeouts for the record.
Thanks for posting this! It prompted me to write up what I learned working the GH merge queue at my previous job: https://boinkor.net/2023/11/neat-github-actions-patterns-for-github-merge-queues/ - in short, you can in fact have different sets of test jobs run at different times (on the queue and off). It’s annoying as hell to write all that YAML, but it is possible.
jq 'map(.result == "success" or .result == "skipped") | all'
[] and map operate on objects as well as arrays, producing all of the values and ignoring the keys, so there’s no need for a to_entries that only uses .value of each entry.
Also I’m 99% sure you could combine the “transform outcomes” and “check outcomes” steps (and simplify the shell stuff) using jq --exit-status. true and false as last output values get mapped to 0 and 1 exit codes respectively.
You absolutely can, but splitting the steps makes it easier to see the outcome yourself in the GitHub actions ui. If they’re combined, you have to rely on printing the value somehow (eg, via set -x), but split up, the value being worked with is in the step context’s list of environment variables.
I miss Bors-NG…
https://mergify.com/ is better than Github Merge Queue, but still not the same as Bors.
Just curious, what do you miss in Bors you don’t find in Mergify?
I like how Bors pushes the changes into a “staging” branch before merging. It makes it easy to run expensive integration tests only at that point. It also supports timeouts and it is open source.
GHMQs also use a temporary branch to do the testing and support timeouts.
Thanks for the answer! Those features are also supported by Mergify; we call that two-step CI: https://docs.mergify.com/merge-queue/two-step/. And it also supports timeouts for the record.
I’m trying to get my team on Gitlab to switch to merge queues. This is a helpful article, I bet we can get something similar to work.
Thanks for posting this! It prompted me to write up what I learned working the GH merge queue at my previous job: https://boinkor.net/2023/11/neat-github-actions-patterns-for-github-merge-queues/ - in short, you can in fact have different sets of test jobs run at different times (on the queue and off). It’s annoying as hell to write all that YAML, but it is possible.
It’s becoming even more clear that GHMQs could do with a few tweaks for usability sake!
How about this?
jq 'map(.result == "success" or .result == "skipped") | all'[]andmapoperate on objects as well as arrays, producing all of the values and ignoring the keys, so there’s no need for ato_entriesthat only uses.valueof each entry.For jq 1.6+ you can also do
jq 'map(.result | IN("success", "skipped")) | all'or
jq 'map(IN(.result; "success", "skipped")) | all'if you prefer (note that
INis a different operator fromin), but I think the version withorreads best when there are only two options.Also I’m 99% sure you could combine the “transform outcomes” and “check outcomes” steps (and simplify the shell stuff) using
jq --exit-status.trueandfalseas last output values get mapped to 0 and 1 exit codes respectively.You absolutely can, but splitting the steps makes it easier to see the outcome yourself in the GitHub actions ui. If they’re combined, you have to rely on printing the value somehow (eg, via
set -x), but split up, the value being worked with is in the step context’s list of environment variables.