Honor the Lua tracer FF for database trace-command invocations for scanned languages.
#1120
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aeisenberg
reviewed
Jun 24, 2022
|
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.
criemen
force-pushed
the
criemen/lua-tracer-ff-2
branch
from
11b7154
to
ab7316e
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| 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
aeisenberg
reviewed
Jun 27, 2022
| 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
approved these changes
Jun 27, 2022
|
I'll do so, thanks! |
This was referenced Jun 28, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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