If a user explicitly includes java in their language inputs, always
make an api call to check for kotlin in the repo.
Also, add some suggestions from code reviews.
This works by moving the logic to check for toolcache bypass out of
creating the codeql instance. The logic now _may_ perform an API request
in order to check what languages are in the repository. This check is
redundant because the same call is being made later in the action when
the actual list of languages is calculated.
This commit centralizes how feature flags are handled. All feature flags
must now add an entry in the `featureFlagConfig` dictionary. This
dictionary associates the flag with an environment variable name and
optionally a minimum version for CodeQL.
The new logic is:
- if the environment variable is set to false: disabled
- if the minimum version requirement specified and met: disabled
- if the environment variable is set to true: enable
- Otherwise check feature flag enablement from the server
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.
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 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.
We now limit the cardinality of the ML-powered JS queries status report
field server-side. With no need for a limit on the cardinality of the
status report client-side, we can simplify how we produce it.
Some platforms that ingest this status report charge based on the
cardinality of the fields, so here we restrict the version strings we
support to a fixed set.
Turboscan only allows a single combination of tool name and automation
details id for testing category uniqueness.
Previously, the check in the action was not entirely correct since it
only looked at the _category_ and not the combination of the category
and the tool name.
It's even more precise now since it is looking at the actual, computed
value of the automation details id, rather than an inputted value of
the category.
This change also includes a refactoring where the action is now avoiding
multiple parsing/stringifying of the sarif files. Instead, sarif is
parsed once at the start of the process and stringified once, after
sarif processing is completely finished.
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`.
