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.
When the codescanning config is being used by the CLI, there is a
single query suite that is generated that contains all queries to be
run by the analysis. This is different from the traditional way, where
there are potentially three query suites: builtin, custom, and packs.
We need to ensure that when the codescanning config is being used,
only a single call to run queries is used, and this call uses the
single generated query suite.
Also, this commit changes the cutoff version for codescanning config to
2.10.1. Earlier versions work, but there were some bugs that are only
fixed in 2.10.1 and later.
`toolcache.extractTar` currently falls over when `ACTIONS_TEMP` contains
a symlink, and the runner no longer exists, so it's unlikely our
customers would be running with temporary directories that contain
symlinks.
This commit adds the packs and queries from the actions input to the
config file used by the CodeQL CLI.
When the `+` is used, the actions input value is combined with the
config value and when it is not used, the input value overrides the
config value.
This commit also adds a bunch of integration tests for this feature.
In order to avoid adding too many new jobs, all of the tests are
run sequentially in a single job (matrixed across relevant operating
systems and OSes).
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.
In theory, a scanned language will not setup the build tracer, and so
shouldn't care about lua versus legacy tracing. However, `go` is a
special case where the autobuilder runs under the build tracer, that
then gets disabled immediately again, unless a special environment
variable is used.
Therefore, we need to thread through the feature flag to this
`database trace-command` invocation. For other scanned languages,
this should be a no-op, as no tracing is ever set up.
Previously, we were being too strict about checking that a pack's
language was being scanned. It was a failure if a pack language
was specified for a language not being scanned.
This change adds a `query-filters` property to the codeql-config file.
This property is an array of `exclude`/`include` entries for a query
suite. These filters are appended to the generated query suite files
and used to filter queries after they are selected.
A related change is that now, all pack references are run in a single
query suite, which has the query filters appended to them.
