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.
This avoids creating a __pycache__ folder in the _actions folder, which
may cause file ownership problems on self-hosted runners
when run in a docker container.
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.
