* 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.
This decorator enabled us to use the functionality of the Actions
toolcache within the runner too.
Now that we've deleted the runner we no longer need it.
