Speed up local development with a global integration environment

[hchauvin]

So this is related to the download cache issue (https://github.com/bazelbuild/bazel-integration-testing/issues/63) but operates at a different level. Here, the issue is not to improve performance in general, but only locally, in a development environment.

It would go like this:

• With a "--define=BAZEL_INTEGRATION_TESTING_DIR=/tmp/foo" in the .bazelrc, the feature is activated and the global integration environment is set to "/tmp/foo".
• A new JUnit rule can be used to make advantage of that. If the feature is activated, the JUnit rule can use the test name to set up a workspace at "/tmp/foo/workspace_" (the workspace can be deleted before each invocation). Since the output base is derived from an MD5 hash of the absolute path of the workspace, the output base will be reused across invocations, making use of caching. If the feature is not activated, a temporary workspace is created in TEST_TMPDIR as usual.

[ittaiz]

Skylark code can’t access “define”s On Tue, 24 Apr 2018 at 14:47 Hadrien Chauvin [email protected] wrote:

So this is related to the download cache issue (#63 https://github.com/bazelbuild/bazel-integration-testing/issues/63) but operates at a different level. Here, the issue is not to improve performance in general, but only locally, in a development environment.

It would go like this:

• With a "--define=BAZEL_INTEGRATION_TESTING_DIR=/tmp/foo" in the .bazelrc, the feature is activated and the global integration environment is set to "/tmp/foo".
• A new JUnit rule can be used to make advantage of that. If the feature is activated, the JUnit rule can use the test name to set up a workspace at "/tmp/foo/workspace_" (the workspace can be deleted before each invocation). Since the output base is derived from an MD5 hash of the absolute path of the workspace, the output base will be reused across invocations, making use of caching. If the feature is not activated, a temporary workspace is created in TEST_TMPDIR as usual.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel-integration-testing/issues/67, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUIF9bXuX8COiVu2V6nKxGCWjvd5Ad5ks5trxC2gaJpZM4ThhAU .

[hchauvin]

Actually it can. They are subject to makevar expansion and are available with the dictionary ctx.var. I think that it is not a well-known feature because 1) it is not well documented, 2) there is almost always a better way to do things. However, in this case, I think it makes sense to use it.

[ittaiz]

Are you sure? My colleague @hmemcpy tried to use them and wasn’t successful. Later on a googler (don’t remember who) said it’s not available to skylark. I’m pretty sure @laurentlb confirmed skylark code can’t read “—define” On Tue, 24 Apr 2018 at 21:26 Hadrien Chauvin [email protected] wrote:

Actually it can. They are subject to makevar expansion and are available with the dictionary ctx.var.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel-integration-testing/issues/67#issuecomment-384033281, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUIF_oDYrbPo_zjC_w4Ea4xvluKMdQiks5tr25ogaJpZM4ThhAU .

[hmemcpy]

@ittaiz to be fair, I didn't try to use --define (after being told they're not supported in Skylark, I didn't attempt it). I tried --action_env to specify environment variables, but they required a repository (rctx) to access them.

[hmemcpy]

they are subject to makevar expansion and are available with the dictionary ctx.var.

Thanks @hchauvin, that's good to know!

[ittaiz]

@hchauvin do you still want this given #71? Not sure I understand the value given the more robust solution

[hchauvin]

Even with a shared cache, this proposal still reduces the time to run WorkspaceDriverIntegrationTest locally by around 50% (I have a draft of the solution), so I think it still stands. I don't see it as the priority, as I think the exact benefit and API depends on how other proposals are implemented, such as the one I submitted concerning the runfiles (#64).