FR: Unable to pass $TEST_UNDECLARED_OUTPUTS_DIR via java_test.args

[ghost]

Description of the problem / feature request:

Environment variables described by the Bazel test encyclopedia are not available for use in java_test command lines via the args attribute.

• args = ["-d", "$TEST_UNDECLARED_OUTPUTS_DIR"]: "in args attribute of java_test rule //:foo-tests: '$TEST_UNDECLARED_OUTPUTS_DIR' syntax is not supported;"
• args = ["-d", "$(TEST_UNDECLARED_OUTPUTS_DIR"]: "in args attribute of java_test rule //:foo-tests: $(TEST_UNDECLARED_OUTPUTS_DIR) not defined"
• args = ["-d", "$$TEST_UNDECLARED_OUTPUTS_DIR"]: Bazel passes a literal $TEST_UNDECLARED_OUTPUTS_DIR on the command line

Feature requests: what underlying problem are you trying to solve with this feature?

I am porting a legacy project to Bazel.

I have a java_test target which uses TestNG instead of JUnit. I am using ReportNG listeners to generate additional test reports. They attempt to write to $PWD/test-output by default. Users can change this only by passing -d outputDir on the command line. I want them to write to $TEST_UNDECLARED_OUTPUTS_DIR. However, I cannot pass $TEST_UNDECLARED_OUTPUTS_DIR on the command line via java_test.args.

As far as I can tell, my only option is to insert a custom launcher which evaluates the command line and environment itself.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

# BUILD.bazel
java_test(
    name = "my-test",
    srcs = ["test.java"],
    args = [
        "-d",
        "$TEST_UNDECLARED_OUTPUTS_DIR",
    ],
    test_class = "mytest",
)

What operating system are you running Bazel on?

Linux; CentOS 6.6

What's the output of bazel info release?

release 0.24.1+vmware

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

n/a

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

n/a

Have you found anything relevant by searching the web?

Not really. I found some issues related to option parsing on Windows by @laszlocsomor .

Any other information, logs, or outputs that you want to share?

[laszlocsomor]

As far as I can tell, my only option is to insert a custom launcher which evaluates the command line and environment itself.

That sounds fine to me. Do you see any problems?

I found some issues related to option parsing on Windows by @laszlocsomor .

Which one?

[ghost]

As far as I can tell, my only option is to insert a custom launcher which evaluates the command line and environment itself.

That sounds fine to me. Do you see any problems?

Just inconvenience/poor UX. It's a non-obvious hoop to jump through, and each (organizational) user of Bazel will have to solve this themselves. I wrote my own launcher, so I'm not blocked by this, but a pure Java team might not be readily equipped to write their own C++ launcher. (launcher must be a cc_binary.)

I found some issues related to option parsing on Windows by @laszlocsomor .

Which one?

Ack. I should've just left that blank and not tagged you, since my references are only tangentially related. They relate to jvm_flags, not args. Sorry about that. :(

They are --

• java_launcher.cc parsing of JVM flags doesn't use shell tokenization #7072 (comment) describes how jvm_flags arguments were embedded in a stub, and how evaluation on not-Windows was (is?) handled directly by Bash rather than a custom dequoting/tokenization code.
• java_binary.jvm_flags allows Bash injection #7097 discusses Bash injection via jvm_flags.

[guw]

@beasleyr-vmw Can you share the custom launcher you wrote? I'm facing a similar issue and would like to try your workaround.

[ghost]

@guw Sure, I'll share a gist once I have authorization from our open source program office.

[guw]

@beasleyr-vmw Don't bother. I figured out a way with pure Java.
salesforce/bazel-maven-proxy@0554d7e