The name suggests that the function computes the merge base, which for
Git means specifically the best common ancestors between multiple
commits or branches (see `git merge-base`).
But what the function actually does is to calculate the HEAD commit of
the PR base branch, as derived from the PR merge commit that the action
analyzes. So even though the function has to do with "merge" and "base",
using the term "merge base" is still misleading at best.
This commit renames the function to determineBaseBranchHeadCommitOid(),
which more clearly indicates what the function does.
Refactor the existing classes of configuration errors into their own file; consolidate the place we check for configuration errors into `codeql.ts`, where the actual command invocations happen.
Also, rename the `UserError` type to `ConfigurationError` to standardize on a single term.
Avoid printing scary error messages to console when the current
directory is not a git repo. Instead provide a better reason for the git
failure and continue on.
* Refactor status report upload logic
Previously we had duplicated the logic to check `GITHUB_RUN_ID`. We now call the `getWorkflowRunID()` method for the status report upload method, and move the logic for the run attempt to `getWorkflowRunAttempt()`
* Add `workflow_run_attempt` to analysis payload
* Stop allowing `undefined` run IDs and attempts
Because we already throw an error if the ID or attempt aren't numbers, we don't have to allow `undefined` values into the payload.
- The `upload` input to the `analyze` Action now accepts the following values:
- `always` is the default value, which uploads the SARIF file to Code Scanning for successful and failed runs.
- `failure-only` is recommended for customers post-processing the SARIF file before uploading it to Code Scanning. This option uploads debugging information to Code Scanning for failed runs to improve the debugging experience.
- `never` avoids uploading the SARIF file to Code Scanning even if the code scanning run fails. This is not recommended for external users since it complicates debugging.
- The legacy `true` and `false` options will be interpreted as `always` and `failure-only` respectively.
---------
Co-authored-by: Henry Mercer <henry.mercer@me.com>
