The default version feature flags will now always point to a CLI version
with a semantically versioned bundle, so we can find the GitHub
Release directly from the CLI version.
Previously, we made an API call to look up the CLI version to release
mapping when the default CLI version was requested on Dotcom and that
CLI wasn't in the toolcache.
Now we compute the tag name directly for semver bundles.
This changes adds default values to feature flags. These default values
will be used whenever the full set of feature flags are not available
(for example on GHES or if the flag request fails).
The goal is to enable cli config parsing on GHES without removing the
feature flag on dotcom.
- We can now use the default bundle version feature flags to remediate a
bad bundle update.
- Controlled switchover ensures that a repo consistently gets the same
bundle version, so we no longer have alert churn concerns with Kotlin
and Swift.
This commit does a few related things:
1. Bumps the minimum version for cli config parsing to 2.10.6
2. Ensures that if cli config parsing is enabled, then remove repos
are _not_ downloaded by the action. It happens in the CLI.
3. Passes the `--external-repository-token-stdin` option to the CLI
and passes the appropriate token via stdin if cli config parsing is
enabled.
This will allow feature flags to be shared across steps in the same job,
avoiding an error we saw earlier where the init action had the flag
enabled, but the analyze step had it disabled.
This uses the runner's temp folder to cache the flags file, which will
stick around until the job completes.
Avoid usage of "Feature Flag" unless we are talking specifically about
the response from github features api. Otherwise, use terms like
"Toggleable features".
Note both "toggleable" and "togglable" appear to be valid spellings of
the word. I chose the first for no good reason.
- Change env var name for `MlPoweredQueriesEnabled`
- Throw error if minimumVersion is specified, but CodeQL argument is not
supplied.
- Fix failing tests. Note that I removed a config-utils test because it
is no longer relevant since we handle codeql minimum versions in the
`getValue` function.
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
