Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not set empty MAVEN_OPTS environment variable #258

Merged
merged 7 commits into from
Mar 13, 2023

Conversation

c00ler
Copy link
Contributor

@c00ler c00ler commented Mar 12, 2023

This pull request introduces the following changes:

  • When maven auto-injection is disabled, update MAVEN_OPTS only if it has the changes added by auto-injection
  • When maven auto-injection is disabled, remove MAVEN_OPTS instead of setting an empty value
  • When maven auto-injection is enabled, merge changes with existing MAVEN_OPTS defined in the node properties.

Fixes https://issues.jenkins.io/browse/JENKINS-70663 and https://issues.jenkins.io/browse/JENKINS-70692

@c00ler c00ler added the bugfix label Mar 12, 2023
@c00ler c00ler self-assigned this Mar 12, 2023
@c00ler c00ler marked this pull request as ready for review March 13, 2023 10:40
turnOnBuildInjectionAndRestart(agent)

then:
with(getMavenOptsFromNodeProperties(agent).split(" ").iterator()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not asserting on the list directly ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, both approaches are applicable. I find the iterator approach more expressive and more flexible. It enforces the order, without being dependent on a particular collection type.

return nodeEnvVars.get(MAVEN_OPTS_VAR);
@Nullable
private static String getCurrentMavenOpts(Node node) {
return EnvUtil.getEnv(node, MAVEN_OPTS_VAR);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about changing EnvUtil.getEnv to return an Optional directly ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible. But I'm not sure about the value though. This is a private method with a very limited scope. It's quite easy to ensure that null value is properly handled. Not all usages will really benefit from an Optional here. See removeIfNeeded method for example, where we would need to resolve optional straightaway to be able to perform a check.

return Optional.ofNullable(mavenOpts)
.map(this::filterMavenOpts)
.orElse("");
.map(this::filterMavenOpts);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, how about changing the return result of filterMavenOpts by Optional<String> and flatMap here ?

@c00ler c00ler merged commit a75cafe into master Mar 13, 2023
@c00ler c00ler deleted the avenderov/do-not-set-empty-maven-opts branch March 13, 2023 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants