Honor the Lua tracer FF for database trace-command invocations for scanned languages.#1120
Honor the Lua tracer FF for database trace-command invocations for scanned languages.#1120
database trace-command invocations for scanned languages.#1120Conversation
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.
|
Another thing that I'm seeing is that these |
|
Oh...looks like this test is no longer flaky...it's just failing. |
…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.
11b7154 to
ab7316e
Compare
| 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.
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.
|
I'll do so, thanks! |
In theory, a scanned language will not setup the build tracer, and so
shouldn't care about lua versus legacy tracing. However,
gois aspecial 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-commandinvocation. 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