This triggers a subset of the behavior of `CODEQL_ACTION_TEST_MODE`,
specifically just skipping the SARIF upload step. This is required for
our internal testing where we want the SARIF file (via
`CODEQL_ACTION_DUMP_SARIF_DIR`) but don't want to actually upload it,
but we don't want the rest of the behaviour of `CODEQL_ACTION_TEST_MODE`
that is specific for `codeql-action` own CI checks.
The name withTimeout() gives the impression that it would limit the
execution of the promise to the given time bound. But that is not the
case: it is only the _waiting_ that is limited, and the promise would
keep running beyond the time bound.
This commit renames withTimeout() to waitForResultWithTimeLimit() so
that developers are more likely to understand the actual behavior of
this function.
* Stop checking disk usage for MacOS ARM with SIP disabled
On MacOS ARM machines where SIP is disabled, after the build tracer is initialized in the `init` Action, we receive warnings when we run send status reports due to the `df` binary. This change will make it so that we no longer run `df` for those machines.
* PR Checks: use `macos-12` runners for CLI v. < 2.15.1
Prior to CLI v2.15.1, MacOS ARM runners were not supported by the build tracer. "macos-latest" is now an ARM runner, so we run these tests on the old CLIs on Intel runners instead.
* Log a warning if SIP is disabled and CLI is < 2.15.1
* Add changenote for SIP-disabled support on old CLI versions
* Set up Python 3.11 for all MacOS checks
Refactor the existing classes of configuration errors into their own file; consolidate the place we check for configuration errors into `codeql.ts`, where the actual command invocations happen.
Also, rename the `UserError` type to `ConfigurationError` to standardize on a single term.
We want to respect cgroup constraints so that when we run in a container, we respect the limits set for the container rather than use the host OS's number of cores.
We check both `/sys/fs/cgroup/cpuset.cpus.effective` (`cgroup v2`) and `/sys/fs/cgroup/cpuset.cpus` (`cgroup v1`) to find the number of cores available. We also check `sys/fs/cgroup/cpu.max` (v1, v2) to calculate the number of cores from the limits set in this file.
The max threads value is set to the minimum of these values, and if no values were found in these files, we default to the original value of the host OS.
