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.
