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.
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 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.
4.4.2 introduces a breaking change that the variable in a catch clause
is now `unknown` type. So, we need to cast the `e`, `err`, or `error`
variables to type `Error`.
This commit adds a `packs` option to the codeql-config.yml file. Users
can specify a list of ql packs to include in the analysis.
For a single language analysis, the packs property looks like this:
```yaml
packs:
- pack-scope/pack-name1@1.2.3
- pack-scope/pack-name2 # no explicit version means download the latest
```
For multi-language analysis, you must key the packs block by lanaguage:
```yaml
packs:
cpp:
- pack-scope/pack-name1@1.2.3
- pack-scope/pack-name2
java:
- pack-scope/pack-name3@1.2.3
- pack-scope/pack-name4
```
This implementation adds a new analysis run (alongside custom and
builtin runs). The unit tests indicate that the correct commands are
being run, but I have not actually tried this with a real CLI.
Also, convert `instanceof Array` to `Array.isArray` since that is
sightly better in some situations. See:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray#instanceof_vs_isarray
Fix grouping of the analysis logs, so that custom query logs also get grouped.
Capture the stdout of codeql database analyze, which contains the analysis summary
from summary and diagnostic queries.
Log this output in its own group, along with the baseline computed in the Action.
Fixes a bug where we were looking for incorrect keys for metrics rules.
Previously, we were using full language names in the keys. Now, we use
the short language names in the metric ids. This is done through a
simplification of the code.
Also, this change does two smaller things:
1. Prints out the baseline count to the logs
2. Adds the `assertNever` function to ensure we never miss a case in
a switch statement. This function is borrowed from vscode-codeql.
The SARIF that we are interpreting has moved away from using `metric`
to the more general term, `rule`. We need to adapt our baseline lines of
code counting to use `rule` as well.
This change passes in a list of file types to the line counting
analysis. These are the languages for the databases being analyzed.
Line count analysis is restricted to these files.
This commit uses a third party library to estimate the lines of code in
a database that is to be analyzed by codeql.
The estimate uses the same includes and excludes globs for determining
which files should be counted.
The lines of code count is returned by language and injected into the
SARIF as `baseline` property in the `${language}/summary/lines-of-code`
metric.
