Pass process environment variables to the integration tests

[arturaz]

Currently mill's integration tests do not get all of the environment variables from the parent process.

This leads to MY_ENV_VAR=foo ./mill integration.feature[foo].local.nodaemon.testForked to not have access to MY_ENV_VAR, unless explicitly exposed via forkEnv .

mill/integration/package.mill

Lines 51 to 63 in 4540af4

	def forkEnv = Task {
	super.forkEnv() ++
	IntegrationTestModule.this.forkEnv() ++
	Map(
	"MILL_INTEGRATION_DAEMON_MODE" -> (mode == "daemon").toString,
	"MILL_INTEGRATION_IS_PACKAGED_LAUNCHER" -> millIntegrationIsPackagedLauncher().toString,
	"MILL_LAUNCHER" -> build.dist.bootstrapLauncher().path.toString,
	"MILL_LAUNCHER_BAT" -> build.dist.bootstrapLauncherBat().path.toString,
	"MILL_INTEGRATION_LAUNCHER" -> millIntegrationLauncher().path.toString
	) ++
	envUpdateSnapshots() ++
	(if (millIntegrationIsPackagedLauncher()) Map() else build.dist.localTestOverridesEnv())
	}

This first reared it's head in #5292 and now again in #5425.

This can lead to subtle bugs. For example, I'm not sure the CI flag is ever actually passed to the test here:

mill/integration/invalidation/watch-source-input/src/WatchSourceInputTests.scala

Line 24 in 4540af4

val maxDurationMillis: Int = if (sys.env.contains("CI")) 120000 else 15000

I suggest forwarding all env variables, as we currently do with MILL_TESTS_BSP_UPDATE_SNAPSHOTS. Is there any downside to that?

[lefou]

I think, we want to control the environment for integration tests from Mill, and having an explicit and reproducible setup that doesn't change much based on the host system, is what we should aim for. Of course, this comes at a prices in terms of flexibility. There is probably some middle ground, but we should outline and discuss the requirements and the implications.