Ensure that this succeeds even if the legacy CLR tracer is not enabled.
The combination of the regular tracer and the SIP workaround within Actions
should be sufficient for this to pass.
Add the missing `$CODEQL_RUNNER` prefix to the autobuild command line.
This intermediate process works around System Integrity Protection,
allowing the tracer to start the C# extractor for the dotnet builds
within the autobuild process.
The test used to pass without this because the legacy CLR tracer bypassed SIP
while dotnet 5 was used on the Actions virtual environment.
Now that the virtual environment uses dotnet 6, the CLR tracer no longer works,
and we need to explicitly work around SIP.
This test will eventually be replaced by an internal integration test for the
equivalent functionality in the CLI. For now, this change makes the test
continue to pass.
Without this, the tracer will not be injected on MacOS, as we need the
runner to circumvent SIP.
Also add a test that tests the autobuild-action to exercise this code path.
The tracer is very good at preserving itself, so unsetting the tracing-specific
variables from within a process will not end tracing for children of
that process.
The way the actions process model works means that we're running inside
a process for the entire build step that was launched with the tracer
variables set, so we'll have the tracer injected into the entire build
step and its children.
If we unset the variables in end-tracing, we will get into an intermediate
state: Not all variables in there are preserved by the tracer,
but the tracer is still active.
Usually, that wouldn't be a problem, but the autobuilders called from
the finalize step will suddenly run under a half-configured tracer.
Particularly, this half-configured tracer is unable to execute the dotnet
CLI without hangs, as the environment variable that prevents hangs for
dotnet on MacOS has been unset, but the tracer is still active.
This is an issue for the the go autobuilder, that invokes
user-provided build scripts in the hope of installing dependencies.
If that build script then invokes dotnet, it will hang.
This is only of concern for the Lua tracer that now implements proper
multi-language tracing: Previously, when encountering the go autobuilder,
the tracer disabled itself entirely, thus side-stepping any hangs.
In the new, multi-language tracing world, the tracer will stay active
as long as there is at least one other language that's been set up
for tracing.
Thus, we also get hangs when invoking the dotnet CLI through the go
autobuilder.
This commit prints diagnostic messages to the Actions log when debug
logging is enabled by passing `debug: true` to `codeql-action/init` or
enabling Actions step debug logging.
This decorator enabled us to use the functionality of the Actions
toolcache within the runner too.
Now that we've deleted the runner we no longer need it.
