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>
Avoid printing the error message and stack when we fail to find the
commit. This will happen in several non-error states (e.g.,
when there is no repository checked out at the CWD). Move the
error message to a debug message so that it is still available
if someone really wants to see it.
Given that the GITHUB_REF is a protected variable, we want to prefer it to
CODE_SCANNING_REF. This should prevent accidentally overwriting these values.
The logic is a bit more involved, as I think it makes sense to raise the error
about GITHUB_REF not being set, rather than mentioning CODE_SCANNING_REF if
both are not set.
