Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

paths / paths-ignore DOES seem to work for Go, yet annotation says is doesnt #2094

Open
erzz opened this issue Jan 21, 2024 · 6 comments
Open

Comments

@erzz
Copy link

erzz commented Jan 21, 2024

I battled for a while to get the action to only run for Go and a specific directory in a multi-language mono-repo.

I seemed to successful with the following:

- name: Initialize CodeQL
  uses: github/codeql-action/init@v3
  with:
    languages: go
    config: |
      paths:
        - ${{ inputs.path }}

By successful I mean that I can see in the SARIF reports that I am only getting locations related to the go part of the repository (before I was seeing everything from all languages in the reports).

So, the evidence suggests that this combination does what I needed - yet I get the annoying annotation below on every run:

image

Is it a faulty annotation?

@ginsbach
Copy link

Hi @erzz,

Thank you for the question! The annotation is not faulty (cf. our documentation here). The paths array only has an effect on interpreted languages. For compiled languages (such as Go), you can either rely on autobuild or provide explicit build steps. You can use the following documentation as a guide: https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#adding-build-steps-for-a-compiled-language

@erzz
Copy link
Author

erzz commented Feb 7, 2024

Thanks @ginsbach

Hmmm then perhaps the issue is more that without that input, the SARIF report is polluted with non-Go related locations

e.g.s

"invocations" : [ {
      "toolExecutionNotifications" : [ {
        "locations" : [ {
          "physicalLocation" : {
            "artifactLocation" : {
              "uri" : "tests/node-sample-app/index.html",
              "uriBaseId" : "%SRCROOT%",
              "index" : 0
            }
          }
        } ],
        "message" : {
          "text" : ""
        },
        "level" : "none",
        "descriptor" : {
          "id" : "go/diagnostics/successfully-extracted-files",
          "index" : 1,
          "toolComponent" : {
            "index" : 0
          }
        },
        "properties" : {
          "formattedMessage" : {
            "text" : ""
          }
        }
      },

...

{
        "locations" : [ {
          "physicalLocation" : {
            "artifactLocation" : {
              "uri" : "src/components/OutputList/index.js",
              "uriBaseId" : "%SRCROOT%",
              "index" : 5
            }
          }
        } ],
        "message" : {
          "text" : ""
        },
        "level" : "none",
        "descriptor" : {
          "id" : "cli/expected-extracted-files/javascript",
          "index" : 0
        },
        "properties" : {
          "formattedMessage" : {
            "text" : ""
          }
        }
      }, {
        "locations" : [ {
          "physicalLocation" : {
            "artifactLocation" : {
              "uri" : "sidebars.js",
              "uriBaseId" : "%SRCROOT%",
              "index" : 6
            }
          }
        } ],
        "message" : {
          "text" : ""
        },
        "level" : "none",
        "descriptor" : {
          "id" : "cli/expected-extracted-files/javascript",
          "index" : 0
        },
        "properties" : {
          "formattedMessage" : {
            "text" : ""
          }
        }
      },

...

Its nothing breaking or anything - just hard work when debugging or trying to interpret the SARIF with human eyes. With the config we get a much shorter and cleaner output only on the intended resources.

@ginsbach
Copy link

ginsbach commented Feb 7, 2024

I have asked the Go team for a clarification.

@smowton
Copy link
Contributor

smowton commented Feb 7, 2024

Can you post or link to your whole codeql action yaml file?

@erzz
Copy link
Author

erzz commented Feb 14, 2024

Hi - sure! Its actually a resusable with a bunch of security related jobs... but here is the relevant parts at least

jobs:
  # <---------------------- CODEQL ----------------------->
  codeql:
    if: ${{ inputs.codeql-enable }}
    name: CodeQL
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Source
        uses: actions/checkout@v4

      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version-file: "${{ inputs.path }}/${{ inputs.go-version-file }}"
          check-latest: ${{ inputs.go-check-latest }}
          cache: ${{ inputs.go-cache }}
          cache-dependency-path: "${{ inputs.path }}/${{ inputs.go-cache-path }}"
          architecture: ${{ inputs.go-architecture }}

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: go

      - name: Run build
        run: |
          cd "$GITHUB_WORKSPACE/${{ inputs.path }}"
          ${{ inputs.build-command }}

      - name: Perform CodeQL Analysis
        id: codeql
        uses: github/codeql-action/analyze@v3

      - name: Upload Reports
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: CodeQL Reports
          path: ${{ steps.codeql.outputs.sarif-output }}

@smowton
Copy link
Contributor

smowton commented Feb 14, 2024

Ah sorry, @ginsbach is right; this is expected behaviour. The various "expected-extracted-file" reports serve to inform the UI that it could be useful to enable languages other than golang if they are not already being analysed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants