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
And add a better error message.
By using `void` instead of `await`, any error thrown is not caught
by surrounding try-catch blocks.
I could continue to use `void` and explicitly handle any thrown errors
by using `.catch`, but most likely the time savings is minimal and
this makes the code more complex.
As suggested in review: The `GITHUB_REPOSITORY` environment variable is
only available on Actions. Passing it in explicitly avoids potentially
crashing if this code is called from the runner.
