Create codeql.yml

[peternewman]

No description provided.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[DaAwesomeP]

For easier maintainability (since it is just a normal build with an extra step or two at the end) should it go in lint.yaml? We already have a pipline for building once and then running the last step in separate actions. That way we aren't maintaining build steps in more places.

I think this should be as simple as:

codeql:
  name: CodeQL
  if: github.ref == 'refs/heads/master' || github.ref == 'refs/heads/0.10'
  runs-on: ${{ (matrix.language == 'swift' && 'macos-latest') || 'ubuntu-latest' }}
  timeout-minutes: ${{ (matrix.language == 'swift' && 120) || 360 }}
  permissions:
    actions: read
    contents: read
    security-events: write
  strategy:
    fail-fast: false
    matrix:
      language: [ 'cpp', 'java', 'javascript', 'python' ]
  needs: build
  steps:
    - name: Download built source tree archive
      uses: actions/download-artifact@v3
      with:
        name: ola-debian-stable-built-source-tree
        path: .
    - name: SHA256 artifact archive
      run: sha256sum ola-debian-stable-built-source-tree.tar.gz
    - name: Unarchive artifacts and delete archive
      shell: bash
      run: |
        tar -xvzf ola-debian-stable-built-source-tree.tar.gz .
        rm ola-debian-stable-built-source-tree.tar.gz
    - name: Display structure of extracted files
      if: env.ACTIONS_STEP_DEBUG == 'true'
      run: ls -alR
    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v2
      with:
        category: "/language:${{matrix.language}}"

Also related to #1862, but the race condition there is caused by the test suite, so running lint on a schedule should be fine.

[DaAwesomeP]

Ah, I missed the github/codeql-action/init@v2 step, so maybe this isn't possible. Or maybe it can be initialized no matter what in the initial lint build step.

[peternewman]

For easier maintainability (since it is just a normal build with an extra step or two at the end) should it go in lint.yaml? We already have a pipline for building once and then running the last step in separate actions. That way we aren't maintaining build steps in more places.

I think this should be as simple as:

Yeah I was just trying hacking something in when I came across it, initially just by taking their template, then trying to make minimal fixes to it...

Merging it into an existing workflow would probably be my intention if it worked. Currently Javascript works fine, Java/Maven throws an error claiming it's too old (see #1881 ) and C++ compiles fine by says it didn't find any compiled code.

Feel free to have a go yourself with some workflows if you want, they're fairly easy as you can see...

Ah, I missed the github/codeql-action/init@v2 step, so maybe this isn't possible. Or maybe it can be initialized no matter what in the initial lint build step.

What do you think would be the issue with initing beforehand?

From a bit of reading of their docs it just looks at all the compilation that happens between init and analyse, so if they're split into a pre-build/cached compilation and the analysis then indeed that probably won't work. 😢

[peternewman]

Well it works fine with no containers involved, despite them saying they shouldn't be an issue:
#1882

It found a small handful of problems but nothing too exciting IMHO. Most should be fairly easily fixed though too, which is good.

[DaAwesomeP]

From a bit of reading of their docs it just looks at all the compilation that happens between init and analyse, so if they're split into a pre-build/cached compilation and the analysis then indeed that probably won't work. 😢

Yeah, exactly this is the issue. It doesn't seem possible to break up the jobs because of this. Maybe we can open an issue on their end about saving state (i.e. init CodeQL > run job > save CodeQL state > new job > restore CodeQL state > run job > finish CodeQL). The other issue is that it seems you can only init one language at a time which does not work for a build-once scenario.

On my list eventually is making the general build process into a shell script with options/steps or a GitHub Actions template, but that is a long way off for now unfortunately.