Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output environment file for Windows #495

Merged
merged 2 commits into from
May 10, 2021

Conversation

edoardopirovano
Copy link
Contributor

Currently, the environment file for the tracer is only being output in the Unix format. Thus, these variables are not being read by the tracer on Windows machines. This PR addresses this by also outputting the environment file in the Windows format.

I have also modified the runner-analyze-csharp-windows test to unset the CODEQL_EXTRACTOR_CSHARP_ROOT variable before the build step. This would cause the test to fail if the environment file being produced was not correct.

@@ -6,6 +6,7 @@
"scripts": {
"build": "tsc",
"test": "ava src/** --serial --verbose",
"test-debug": "ava src/** --serial --verbose --timeout=20m",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine, but are you aware that you can debug a test from inside of vscode? See the .vscode/launch.json file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, can't hurt to have this target too for people debugging in other ways though 🙂

@@ -465,7 +465,12 @@ jobs:

- name: Build code
shell: powershell
# Note this step unsets the CODEQL_EXTRACTOR_CSHARP_ROOT to ensure that the .win32env file is read correctly
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In what situations is this not being read correctly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this PR the file was not being produced at all, so I figured we need to modify an integration test to make sure it actually gets read when it is produced.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh. I see, I misunderstood the comment and what you're doing here. By un-setting the CODEQL_EXTRACTOR_CSHARP_ROOT variable, you are ensuring that .win32env is being read correctly.

Could you update the comment to something like this?

Suggested change
# Note this step unsets the CODEQL_EXTRACTOR_CSHARP_ROOT to ensure that the .win32env file is read correctly
# Note we want to make sure that the .win32env file is read correctlyl, so we unset the CODEQL_EXTRACTOR_CSHARP_ROOT from the .sh file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, done ✅

(Get-Content ./codeql-runner/codeql-env.sh) | Select-String -pattern ".*CODEQL_EXTRACTOR_CSHARP_ROOT.*" -NotMatch | ? {$_.ToString().trim() -ne "" } | Set-Content ./codeql-runner/codeql-env.sh
$jsonEnv = Get-Content -Path ./codeql-runner/codeql-env.json -Raw | ConvertFrom-Json
$jsonEnv.PSObject.Properties.Remove('CODEQL_EXTRACTOR_CSHARP_ROOT')
$jsonEnv | ConvertTo-Json -Depth 1 | Out-File ./codeql-runner/codeql-env.json -Force
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we make this simpler, by removing CODEQL_EXTRACTOR_CSHARP_ROOT from the environment after the Invoke-Expression step below? I think Clear-Variable is the PowerShell command.
The step below doesn't use the JSON file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, done. For reason I thought those files needed patching to stop the runner reading them again.

const envPath = `${spec}.environment`;
fs.writeFileSync(envPath, buffer);

// Prepare the content of the compound environment file on Windows
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about doing this step only when we're on Windows, vs unconditionally?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have a (weak!) preference to only write the file that corresponds to the current platform. I doubt it makes any concrete difference either way, but it feels most right to try to mimic what the actual preload_tracer does.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, done - except in the unit tests where we still test both regardless of platform.

Copy link
Contributor

@hmakholm hmakholm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

The O(n²) buffer building makes me wince a bit, but (a) that's what the existing code does for Unix, (b) generally there are not that many environment variables to handle, and (c) the whole exercise ought to go away soon when we have multi-language support in the CLI anyway.

@adityasharad adityasharad merged commit 4c0671c into github:main May 10, 2021
@edoardopirovano edoardopirovano deleted the windows-env-file branch May 10, 2021 21:03
@github-actions github-actions bot mentioned this pull request May 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants