when i was playing, i was trying to split. I left it at https://github.com/directionless/osquery/blob/master/.github/workflows/macos.yaml

From this, it looks like the github stuff is notable slower than the azure stuff. I guess we'll see if that's an issue.

From this, it looks like the github stuff is notable slower than the azure stuff. I guess we'll see if that's an issue.

I think there's something wrong going with ccache; the agent instances should be very similar if not identical to Azure Pipelines.
I'm saying this because without a ccache properly available, on Azure Pipelines too it would take > 1h to build Linux.
Also, the max job timeout is 6h or so, there's a property we have to set on the job to increase such timeout which by default is at 1h.

What if the individual platform builds don't depend on the check code style step? Then we might be able to split this up into separate files and also the run could complete quicker due to further parallelization.

The check_code_style job was implemented as a blocking prerequisite to make sure that an invalid PR (which could receive a burst of additional commits that attempts to fix formatting) will not cause valid PRs to starve for workers

I wonder if it's possible to have a new push to a branch cancel the runs of the existing jobs. That could resolve the starvation issue. Happy to go ahead with this.

That is what it happens already, you won't have more than a run worth of jobs occupied, but I guess what we're trying to avoid is to still occupy those jobs if the formatting is going to fail again and will require another change.
It often depends how soon the PR author notices that the build failed for formatting issues.