CodeQL 1.0.16 fails on Linux (1.0.15 ok)

[softins]

The CodeQL runs for the Jamulus project on Linux have started failing since CodeQL was updated to 1.0.16. Version 1.0.15 was fine.

For comparison, the workflow was run on the same commit as an earlier successful run.

The successful run is at https://github.com/softins/jamulus/actions/runs/1303486160

The failed run on the same commit is at https://github.com/softins/jamulus/actions/runs/1311314438

1. Is it possible in the meantime to pin the version of CodeQL used to 1.0.15?
2. Is there a bug in 1.0.16?
3. Is there something different we need to do for 1.0.16 to run correctly?

Thank you

[hvitved]

The No source code was seen and extracted error indicates that something could potentially have changed in the tracer. @github/codeql-c could you take a look, please?

[adityasharad]

1. Is it possible in the meantime to pin the version of CodeQL used to 1.0.15?

Yes: in your workflow file, you can change github/codeql-action/init@v1 and github/codeql-action/analyze@v1 to github/codeql-action/[email protected] and github/codeql-action/[email protected]. This will pin the version to that specific tag, instead of tracking the latest v1.* release. Commit SHAs from the github/codeql-action repo are also supported in this syntax.

[edoardopirovano]

The No source code was seen and extracted error indicates that something could potentially have changed in the tracer. @github/codeql-c could you take a look, please?

Versions 1.0.16 and 1.0.15 of codeql-action both use the same release of the CodeQL toolchain (2.6.2) and, therefore, the same tracer. This must be due to a change in the Action itself - I strongly suspect #744.

[softins]

Just to confirm that by explicitly specifying 1.0.15, my run is successful again.

[edoardopirovano]

Just to confirm that by explicitly specifying 1.0.15, my run is successful again.

Thanks for trying that out! I'll investigate what is going on with 1.0.16 soon but I'm glad you're unblocked in the meantime :)

[edoardopirovano]

Thanks for raising this with us @softins! My understanding of what is going on is as follows - CodeQL needs some environment variables to be set during the build process so that it can observe the build. However, your build script uses debuild which by default unsets all environment variables as documented here. Thus, in order to allow CodeQL to observe the build process the --preserve-env option needs to be passed to that command. I've opened a PR doing this here: jamulussoftware/jamulus#2060, and can confirm that with that change everything works with 1.0.16.

I'm unsure how this workflow worked with 1.0.15. We made some changes (#744) to how we set the environment variables that observe the build, but my understanding is that even with 1.0.15 we did need some variables to be set. My hypothesis is that the changes we made broke some mechanism we had of being resistant to variables being unset. This merits a deeper investigation, but in the meantime I would suggest that merging the above PR is the best way to resolve your issue.

[softins]

@edoardopirovano thank you for the quick response and the PR!

[edoardopirovano]

@edoardopirovano thank you for the quick response and the PR!

Closing this issue since your build appears to be working again after my PR: https://github.com/jamulussoftware/jamulus/actions/runs/1317351140

I will open an internal issue to investigate further quite what happened that made the workflow as previously written not work.