--test_env (and some other test flags) should not discard analysis cache with --trim_test_configuration

[or-shachar]

Description of the problem / feature request:

My .bazelrc file has some options linked to test

test --test_arg=--jvm_flags=-Dcom.google.testing.junit.runner.shouldInstallTestSecurityManager=false

Apparently this makes analysis cache to be discarded between build and test invocations.

INFO: Build option --test_arg has changed, discarding analysis cache.

To fix it I need to link the option to build, which doesn't make a lot of sense as it's a test related.

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

--test_arg should not affect the analysis cache. Or the warning message should be better.
BTW: same goes for --test_env

What operating system are you running Bazel on?

OSX

What's the output of bazel info release?

release 0.22.0

[or-shachar]

FYI @sha1n @ittaiz

[sha1n]

Same behaviour is observed on Ubuntu + Bazel version 0.21
@or-shachar @ittaiz

[ittaiz]

Can you try with test trim true?

[sha1n]

Thanks @ittaiz! Adding that flag indeed has an effect, but only on test_args. So, the presence of test_env causes the analysis cache to be discarded, with and without that flag.

[programmablereya]

Unfortunately, --trim_test_configuration not working with --test_env is known (as mentioned in issue #5579). :( This is a good canonical issue for the issue of resolving that discrepancy, however! :)

[sha1n]

Thanks @serynth!
Can you elaborate more about why it doesn't work and whether or not there are plans to fix it, assuming that it is not the desired behaviour. Also, if there's any issue we can use to track progress around that area, it will be nice.

[programmablereya]

Sure! :) It definitely isn't the desired behavior, though whether it's fixed by --trim_test_configuration being fixed or when automatic trimming comes to fruition depends some on my schedule.

Why it doesn't work:
The flags named in #5579 (comment) are not in the TestConfiguration fragment, which is what --trim_test_configuration trims. Moving them requires doing some work to extract them from BuildConfiguration.Options and to remove BuildConfiguration's direct dependency on them. This is something I'd like to do, but automatic trimming is consuming my attention right now.

As I mentioned, this is (now) the canonical issue for tracking progress on this work.

[sha1n]

Thank you @serynth! 👍

[aiuto]

@sdtwigg Can you look at this while you are finishing up on --trim_test_configuration?

[ulfjack]

--test_env currently lives in CoreOptions and is copied into BuildConfiguration, which invalidates the analysis phase. It should be straightforward to move it to TestConfiguration. It's also accessed in CommandEnvironment (Yuk!) for use in the ClientEnv bazel info key (but that shouldn't be a blocker AFAICT).

Changes here also need to take into account Google's fork of the test strategies, which may prevent external contributions.

[sdtwigg]

Acknowledging this.

There is at least one minor hurdle. Internally, a small amount of rules have config_settings that are sensitive to --test_env, which requires special consideration before test_env can move under TestConfiguration.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

[aiuto]

Is this actually fixed and done?

…

On Thu, Feb 16, 2023, 3:31 AM Gowroji Sunil ***@***.***> wrote: Closed #7450 <#7450> as not planned. — Reply to this email directly, view it on GitHub <#7450 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHHZVXOBIPJUF2PWCBDWXXQVHANCNFSM4GX6MILA> . You are receiving this because you commented.Message ID: ***@***.***>

[gregestren]

No.