Union-izing test's extra_env_vars and runtime_package_dependencies

[xlevus]

Background

I have a suite of tests that do integrations against an external environment. Currently our CICD will deploy the packaged dependencies to the system and then run the tests on the local machine. Which means our 'test' step is a bit more involved than just ./pants test ::.

One suggested solution to this was to create a codegen target that deploys the resources, but this would then cause things to be deployed unnecessarily every time export-codegen is run. It also doesn't solve how to inject the location of the deployed resources into the tests.

idea

Currently you can define [test].extra_env_vars to inject extra stuff into the env, and runtime_package_dependencies to add packageable targets to the test process digest. But from a quick skim of the code, all of this is replicated in each backends subprocess call.

e.g.:
https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/goals/pytest_runner.py#L245
https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/go/goals/test.py#L595

It would be ideal if extra_env_vars and runtime_package_dependencies were somehow Unionized. Allowing 3rd party plugins to provide ways to add additional data into test runs.

[xlevus]

My original thought was to move the 'collection' of the environment vars to a env_vars and runtime_digest attribute on the TestRequest that backends would then merge together before their Process call.

But:

• It seemed pretty simple and obvious to do pre-batching, I have no idea where it'd go now.
• This might break caching?

[stuhood]

Sorry for not responding at the time!

My initial thought on it is that if it is possible to build in the actual functionality that you want (launching and parenting services from Pants while a test is running), then that would be preferable to having a wrapper script start them, and then a Pants plugin to provide their settings.

I’m having trouble finding a relevant issue, but it might look like a test_service(name=.., binary_target=..) target, which spawned the service as a daemon for the length of dependent test runs (or optionally for pantsd’s lifetime).

So, long story short: yes, I think that that type of @union might make sense. The service target might use the type of @union that you mention in order to provide extra env vars / etc to dependent test targets. But including an actual use case upstream would make the plugin functionality less fragile, and hopefully also easier to use.