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

make inferred workspace dir consistent with actual one in builds #129

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

gmishkin
Copy link

@gmishkin gmishkin commented Apr 2, 2020

I want to make the workspace path you get when you look at $BUILD_WORKSPACE_DIRECTORY inside the target you're running, be consistent with the value you get if you do $(dirname "$(dirname "${BASH_SOURCE[0]}")") in a tools/bazel script. I'm using the latter form of this as part of a startup option in my wrapper.

I am using the tools/bazel script to $BAZEL_REAL run the full wrapper target, which takes the rest of the args, does some logging, and invokes BAZEL_REAL again with the original args. But it also needs to set that startup option when it does so, to avoid thrashing the server. To do so it uses BUILD_WORKSPACE_DIRECTORY.

What I noticed is that it was thrashing the server anyway. When I dug in, it turned out the issue was that inside tools/bazel it was passing

--host_jvm_args=-Djavax.net.ssl.trustStore=/Users/geoff/proj/./cacerts`

But inside the target running via bazel run, it was passing

--host_jvm_args=-Djavax.net.ssl.trustStore=/Users/geoff/proj/cacerts`

Even though they're logically the same file, bazel doesn't realize that, especially when the path is being passed to an arbitrary JVM flag. So it restarts the server each time.

Removing the leading ./ in the constant prevents the server restarts, and seems safe because that constant is only ever used in os.path.join() which is aware of how to combine path components.

I also included a test to show the difference, but you can remove it if you think it's silly.

@gmishkin
Copy link
Author

gmishkin commented Apr 3, 2020

@philwo errr... should I start passing shell=True to subprocess.Popen() on Windows?

To get it to be able to run batch files.

@philwo
Copy link
Member

philwo commented Apr 17, 2020

@gmishkin Sorry for not getting back to you. Your fix looks good to me - thanks for the debugging!

Regarding shell=True, the Python docs say this:

The only time you need to specify shell=True on Windows is when the command you wish to execute is built into the shell (e.g. dir or copy). You do not need shell=True to run a batch file or console-based executable.

The test failure you're seeing is probably due to Windows just not supporting running executables that lack an .exe or similar suffix. Thus, running tools/bazel would never work on Windows anyway (it would have to be called tools/bazel.cmd or something like that).

I think we have to add special logic to delegate_tools_bazel so that it looks at different files on Windows (maybe we could try tools/bazel.exe, tools/bazel.cmd, tools/bazel.bat in that order?)

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.

2 participants