Honor the Lua tracer FF for database trace-command invocations for scanned languages. - #1120
criemen merged 3 commits into
Conversation
Sorry, something went wrong.
aeisenberg
left a comment
There was a problem hiding this comment.
Looks sensible. Though I think it shouldn't be too hard to create a unit test.
Sorry, something went wrong.
|
Another thing that I'm seeing is that these Test Python Package Installation tests are flaky. We should probably automatically retry them if they fail. (Unrelated to this PR.) |
Sorry, something went wrong.
|
Oh...looks like this test is no longer flaky...it's just failing. |
Sorry, something went wrong.
ghost
left a comment
There was a problem hiding this comment.
Looks good. All tests passed.
Sorry, something went wrong.
…scanned languages. In theory, a scanned language will not setup the build tracer, and so shouldn't care about lua versus legacy tracing. However, `go` is a special case where the autobuilder runs under the build tracer, that then gets disabled immediately again, unless a special environment variable is used. Therefore, we need to thread through the feature flag to this `database trace-command` invocation. For other scanned languages, this should be a no-op, as no tracing is ever set up.
| export async function getCodeQLForTesting(): Promise<CodeQL> { | ||
| return getCodeQLForCmd("codeql-for-testing", false); | ||
| export async function getCodeQLForTesting( | ||
| cmd = "codeql-for-testing" |
Check failure
Code scanning / CodeQL
Exec call vulnerable to binary planting
| injectedMlQueries: false, | ||
| }; | ||
|
|
||
| test("createdDBForScannedLanguages() Lua feature flag enabled, but old CLI", async (t) => { |
There was a problem hiding this comment.
There are 4 tests here that are almost the same, but with different parameters. Can you merge them? The easiest thing to do is something like this:
[{ name: "Lua feature flag enabled, but old CLI", version: "2.9.0", ... }, ...].forEach(options => {
test(`createdDBForScannedLanguages() ${options.name}`, async (t) => {
...
sinon.stub(codeqlObject, "getVersion").resolves(options.version);
...
});
});
This will help emphasize the actual differences between the tests.
Sorry, something went wrong.
aeisenberg
left a comment
There was a problem hiding this comment.
My suggestion is quite minor. Feel free to merge this now to get it into the 2.10.0 release and then tweak it later.
Sorry, something went wrong.
|
I'll do so, thanks! |
Sorry, something went wrong.
In theory, a scanned language will not setup the build tracer, and so
shouldn't care about lua versus legacy tracing. However, go is a
special case where the autobuilder runs under the build tracer, that
then gets disabled immediately again, unless a special environment
variable is used.
Therefore, we need to thread through the feature flag to this
database trace-command invocation. For other scanned languages,
this should be a no-op, as no tracing is ever set up.
I couldn't find any tests for the existing functionality, so I couldn't extend them either. If anybody has some great ideas for how to test this change, I'm happy to write some tests for this, too.
Merge / deployment checklist