Environment variable changes are reverted and gradle.startParameter is used to read system properties in init scripts
#682
Conversation
There was a problem hiding this comment.
Since these changes are required for BVS, is there a good reason why the same problem won't manifest for other init-script consumers?
I'm OK with these changes to BVS, but I'd request changes to apply these to the reference init-script. Namely, I think we can avoid the duplicate definition of getInputParam(name) by changing the signature to getInputParam(gradle, name).
I expect this is a universal issue. In earlier versions of Gradle, what I discovered is that any modification to environment variables (changes, additions, etc.) are not reflected throughout the life of the Daemon process. It will be more common that you have Daemon reuse locally than in CI. The other consideration is locally these environment variables are only included when invoking the scripts. In CI, the environment variables are always present in CI for every build invocation, though modifications are possible, it will be very infrequent. I think this essentially makes it a non-issue for CI plugins. I believe this is the relevant Gradle issue: gradle/gradle#10483
I can follow up with a PR. 👍 |
There was a problem hiding this comment.
LGTM. @erichaagdev and I went through the PR review together.
Gradle 7.0.2 and earlier cannot reliably read system properties using `System.getProperty` from init scripts. This PR adds reading system properties using the `gradle.startParameter.systemPropertiesArgs` API. Related BVS PR: gradle/develocity-build-validation-scripts#682
This PR:
gradle.startParameterto read system propertiesI suggest reviewing only the last 2 commits as the first 2 only revert the previous changes.
Relevant diff: https://github.com/gradle/gradle-enterprise-build-validation-scripts/pull/682/files/64f48ec26c9fb43c51d62d281a9c3a99554342e1..632519d8c0cf14190fe3ac6608b72ac50fd791d4