Interesting it works. I tried it once and the CI ran out of resources. But if it works now that’s great (I.e the build time gets ok-ish time wise)

Interesting it works. I tried it once and the CI ran out of resources.

Maybe hardware specs have changed (Mac seems to use 3 cores, other platforms 2 cores) or another -j value had been chosen in the past? As said, the Mac builds already used this, so it didn't break anything at least.

But if it works now that’s great (I.e the build time gets ok-ish time wise).

The examples show an improvement, but there is lots of flakiness in build times, so it's hard to tell for sure and how much the benefit is. Anyway, some of the build scripts are also used locally and not only in autobuild, so it makes sense to add it anyway.

I think @pljones or I used plain -j

I think @pljones or I used plain -j

That's what I use locally as well. I thought it had some automatism for figuring out a good N value, but it seems like it would just start anything it could ("similar to a fork bomb" is what I read elsewhere). So that might explain it.

but I still get confused whether it's using the "to be merged" CI components when doing CI on CI components or whether it's using the existing ones

Pretty sure it's the to-be-merged ones. Besides .github/, Github has no way to figure out what else is "CI related". I think you might be referring to the logic that PRs (pull_request event) do not run in the security context of the target repo (jamulussoftware/jamulus). IOW, they do not have access to a GITHUB_SECRET with repo access. See https://securitylab.github.com/research/github-actions-preventing-pwn-requests/