All other platforms run codeQL as part of their regular build. This increases the time until artifacts are available, but avoids having to build each job twice. We should handle codeQL consistenly.

There was a reason for that, now I see it written out. Hm. It'll be explained somewhere - I think it was an answer to one of the points I raised.

• diff -u autobuild/mac/{artifacts,codeQL}/autobuild_mac_2_build.sh is empty.

Really? On latest master for me, they differ:

tony@pi:~/jamulus/autobuild/mac $ diff *
diff artifacts/autobuild_mac_2_build.sh codeQL/autobuild_mac_2_build.sh
1c1
< #!/bin/sh -e
---
> #!/bin/bash
10,14d9
< SIGN=$1
< if [ -n "${SIGN}" ]; then
<     shift
< fi
<
23d17
< echo "Run deploy script..."
25,50c19,26
< # If we have certificate details, then prepare the signing
< if [[ "${SIGN}" != "sign_if_possible" ||
<         -z "${MACOS_CERTIFICATE_PWD}" ||
<         -z "${MACOS_CERTIFICATE}" ||
<         -z "${MACOS_CERTIFICATE_ID}" ||
<         -z "${NOTARIZATION_PASSWORD}" ||
<         -z "${KEYCHAIN_PASSWORD}" ]]
< then
<     sh "${THIS_JAMULUS_PROJECT_PATH}"/mac/deploy_mac.sh
< else
<     echo "Setting up signing, as all credentials found"
<
<     # Get the cert to a file
<     echo ${MACOS_CERTIFICATE} | base64 --decode > certificate.p12
<
<     # Set up a keychain for the build
<     security create-keychain -p "${KEYCHAIN_PASSWORD}" build.keychain
<     security default-keychain -s build.keychain
<     security unlock-keychain -p "${KEYCHAIN_PASSWORD}" build.keychain
<     security import certificate.p12 -k build.keychain -P "${MACOS_CERTIFICATE_PWD}" -T /usr/bin/codesign
<     security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "${KEYCHAIN_PASSWORD}" build.keychain
<
<     sh "${THIS_JAMULUS_PROJECT_PATH}"/mac/deploy_mac.sh -s "${MACOS_CERTIFICATE_ID}"
<     # Set up the notarization and staple parts
<     echo "::set-output name=macos_signed::true"
< fi
---
> echo "Building... qmake"
> qmake
>
> echo "Building... make"
> make -j "$(sysctl -n hw.ncpu)"
>
>
> echo "Done"
Only in artifacts: autobuild_mac_3_copy_files.sh

I haven't yet looked at your changes...

All other platforms run codeQL as part of their regular build. This increases the time until artifacts are available, but avoids having to build each job twice. We should handle codeQL consistenly.

There was a reason for that, now I see it written out. Hm. It'll be explained somewhere - I think it was an answer to one of the points I raised.

I've found some history regarding the Mac CodeQL split: #978 (comment) #978 (comment)

BTW, the initial cause for splitting artifacts and codeql in some cases was, that for some unkonown reason the build of the installers did not trigger the codeql-inspection.

@softins Thanks for the hint, I'll re-check my history. That shouldn't happen. :(
Edit: Found the issue, I ran git diff instead of just diff. Will have to re-work this PR.

I made a comment recently somewhere about why we had separate CodeQL and Artifacts steps for Mac, but I can't find it now. It's not here, and probably buried in one of the relevant PRs or issues. I said that I had tried to combine CodeQL and Artifacts for Mac without success last year, by setting uses_codeql: true on the artifacts job. I found my branch, from May 2021, and can see in my Actions tab that the workflow failed consistently at the time. I have just re-run the same workflow on the same commit (4a736b0), and this time it succeeded! The log for the old failed run is no longer available, but I suspect that there has been some improvement to the run environment or to CodeQL itself since my first attempt.

So it looks like we are now safe to combine them as per this PR (using the build script from artifacts, as you have done, not from CodeQL).

The only other thing I wasn't sure of is that the Mac build script actually builds twice - once for client and once for server. I don't know how that affects the CodeQL part.

once for client and once for server.

I think it's the same for Debian (but it's gui and headless) there.

I do also think that we should track as issue that alternatives should be considered (in terms of not building basically the same binary twice). JamulusServer.app should just run Jamulus.app with the -s argument.

once for client and once for server.

I think it's the same for Debian (but it's gui and headless) there.

Yep, thought the same.

I do also think that we should track as issue that alternatives should be considered (in terms of not building basically the same binary twice). JamulusServer.app should just run Jamulus.app with the -s argument.

Running Jamulus.app with -s might be possible (I haven't investigated where this "starter" is defined). Right now it is being implemented with a define (SERVER_BUNDLE) which changes the behavior of the actual binary.
I think both this case and Linux (HEADLESS) is problematic for building in a single go. I don't think the build system can detect differences in defines, so we're required to run a clean build.
But yeah, if you could open an Issue to track this, this would be good.

@softins Thanks for your insights, tests and explanations!

I've just checked the diff again. Although I missed the differences initially, I think they are fine (especially now that we are no longer running a different job for CodeQL). I'm therefore removing the Draft status without any further changes. I've edited the PR description.

Rebased, confirmed that all targets are green and that MacOS Non-legacy properly runs Code-QL. Merging.