Gerrit Windows job fails due to command is tool long (> 8k)

[meteorcloudy]

Windows has a command line length limit of 8K.
We do a bazel query to get all tests targets, then pass them to a single bazel test command, when the targets are too many, the job will fail.
See https://ci.bazel.build/blue/organizations/jenkins/gerrit/detail/gerrit/2274/pipeline

This happened before for bazel-tests: bazelbuild/bazel#3742

[meteorcloudy]

//cc @iirina @laszlocsomor @philwo Does anyone know why do we have to do a bazel query before bazel test?

continuous-integration/jenkins/lib/src/build/bazel/ci/BazelUtils.groovy

Line 159 in dc6796a

def filteredTests = bazelCommand(makeTestQuery(tests), false, true)

Looks like it suppose to filter unnecessary tests by test_filter_tags, but from the CI output, it just fetchs all tests specified by tests.

[philwo]

@meteorcloudy Not sure - I once heard that the reason was that we want to have the list of targets in the log. But I find that to be not very useful, because it is often just a huge wall of text anyway. I never used that.

Maybe remove it and see what happens? 😃

[laszlocsomor]

@meteorcloudy : Yes, Damien told me some months ago that the reason for the queries is that in some files we use test patterns which we need to expand. But I'm with Philipp, let's remove it and see if anything breaks.

[meteorcloudy]

Thanks for the feedback! I'll try to remove it.

[meteorcloudy]

https://github.com/bazelbuild/bazel/blob/master/scripts/ci/bazel-tests.json#L63
This will probably break if we remove bazel query

[philwo]

@meteorcloudy Can we rewrite that somehow? Just give a list of hard-coded known-good targets? This expression is basically unmaintainable (and probably unmaintained ;)) anyway this way.

@aehlig Any idea on how to simplify the "tests that can be run on FreeBSD CI" expression?

[meteorcloudy]

I found a "hacky" way to solve this without removing bazel query...
After getting a list of test targets, we can write test <test target> into a bazelrc file for each of the tests. Then we can workaround the command line limit by sort of using a "parameter file".

What do you think?

[meteorcloudy]

Can we rewrite that somehow? Just give a list of hard-coded known-good targets? This expression is basically unmaintainable (and probably unmaintained ;)) anyway this way

I agree, it's best we can remove this complex test patterns.

[philwo]

After getting a list of test targets, we can write test <test target> into a bazelrc file

WTF, that works? 🤣

[laszlocsomor]

Ough. That's gross. I like it.

[meteorcloudy]

@philwo Yes... 😂

[meteorcloudy]

So how should we proceed?
Simplify the test expression or use this nice dirty hack? @aehlig

[philwo]

Would favor getting rid of the "bazel query" step and simplify the test expression.

[philwo]

The new CI will (probably) no longer use "bazel query" to filter test targets, so we'll have to change the test configs to use simpler target specifications.

[philwo]

Obsolete.