github/codeql-action/upload-sarif@v1 requires a git repository checked out

[peter-murray]

Hi,

I was looking at introducing the Anchore container scanning via GitHub Actions into a workflow that triggers the scanning and and uploading of the SARIF report to be triggered off the event of a registry package being uploaded.

The reason for wanting to do this outside of the standard pattern with respect to code scanning examples that currently exist, is that it can be an expensive operation and I want to scan every image that we publish to a registry asynchronously from the build/publish process.

The problem that I have hit in this regard is that the github/codeql-action/upload-sarif@v1 action is using git command line invocation, identified in the failed output of the action:

Automatically detected languages: ["java","javascript"]
Uploading results
  fatal: not a git repository (or any of the parent directories): .git
  ##[error]The process 'git' failed with exit code 128

It would be good to be able to provide a sarif report by providing the necessary details as input parameters on the action that this action invocation is trying to resolve from the underlying git repository.

[robertbrignull]

Yes, I can see that would be an issue when you're scanning a container instead of code from a repository. The information that the action is looking for is just the SHA of the commit being analysed. I agree it would be reasonable to be able to provide that so git is not needed.

If there was a way to provide that information would you be able to do that? If you know which commit to associate results with, then as a workaround would it be possible to checkout the repository at that commit? It may be redundant but it would get the action working for you now.

[peter-murray]

I have a workflow that is a little disconnected in that sense as I have a version number on a container image in a registry.

Currently I am just checking out the repo at master so I could get the results into the UI, but as you say I need to track back to the sha of the commit that the container was build against.

An improvement here would be to default an input for the sha you are given as part of the GitHub actions run, at least then it is configurable and correct if you have checked out and using this in a build workflow, and in a worst case scenario tied into the default sha of the of the event that triggered the workflow run.

With it being an input, then I can also work backwards from my image version and fine the sha in the commit history to register the result against that.

[robertbrignull]

I'm going to mark this issue as closed now because we've made the dependency on being able to run command line git optional. The action will now fall back to using the commit sha from the environment that is provided by actions. Therefore you shouldn't see any errors as that environment is always provided.

Admittedly this doesn't solve your other problem of alerts being reported on the wrong commit. However I think this is to a certain extent just how github actions works in that you have to trigger it on a commit. If this is still a large problem then feel free to reopen and we can discuss further.