-
Notifications
You must be signed in to change notification settings - Fork 642
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
Fixes #960 Property placeholders are not interpolated when they are only thing in XML #964
Conversation
Codecov Report
@@ Coverage Diff @@
## master #964 +/- ##
============================================
+ Coverage 51.65% 51.67% +0.01%
- Complexity 1350 1351 +1
============================================
Files 147 147
Lines 7445 7447 +2
Branches 1121 1122 +1
============================================
+ Hits 3846 3848 +2
Misses 3232 3232
Partials 367 367
|
@rohanKanojia thanks for picking that up ! Gimme a bit, just on my way to a conference, so hope to review it soonish. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks good !
Howver, I would harden the detection of the +
a bit and move the docs to the place where the implicit variables are explained. See comments inline.
src/main/asciidoc/inc/misc/_env.adoc
Outdated
When creating a container one or more environment variables can be set via configuration with the `env` parameter | ||
When creating a container one or more environment variables can be set via configuration with the `env` parameter. Somehow maven is showing weird behavior in case of interpolating single ${..} parameter; so we have provided a workaround for that. An `env` can take the following forms: | ||
|
||
.Env format |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for caring about the documentation, too ;-)
However I would describe it a bit shorter. Maybe just:
If the only value of the env parameter is a docker-maven-plugin internal property which has been set implicitely you have to prefix the property with a single
+
like in+${docker.container.test.ip}
. This is necessary due to some Maven limitations which simply interpolates a lone, non defined property, to an empty string which can't then be replaced by this plugin after the initial interpolation phase.
Maybe we can list the affected properties here. Or we should put the whole documentation to the place, where the implicit properties are explained (i think this is even better)
@@ -57,6 +57,12 @@ public ContainerCreateConfig environment(String envPropsFile, Map<String, String | |||
String value = entry.getValue(); | |||
if (value == null) { | |||
value = ""; | |||
} else if(value.contains("+")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wold prefer a startsWith("+$")
here because otherwise its far too unspecific. (Think about values which can validly contain +
characters)
Even better, use a regexp ^\+\$\{.*\}$
. This would really only match our use case.
@@ -122,6 +123,7 @@ private String copyPropsToFile() throws IOException { | |||
Map<String,String> envMap = new HashMap<>(); | |||
envMap.put("JAVA_OPTS", "-Xmx512m"); | |||
envMap.put("TEST_SERVICE", "LOGGING"); | |||
envMap.put("TEST_HTTP_ADDR", "+${docker.container.consul.ip}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add also tests where the + sign is part of a value or when there is something in addition like in +${docker.container.consul.ip}additional_data
(here, there should be no removal of the +)
} | ||
|
||
@Test | ||
public void testSerialization() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is this test about ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I thought I should add a test to check whether these RunImageConfiguration objects are properly serialized into objects or not. If this doesn't look like a sane to you, I would remove it.
Also, Can there be other tests related to this class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, don't know exactly where this class should be serialized.
Adding tests are very valuable, but:
- they add maintenance costs, which is ok if the test has some value and tests the right thing. E.g they need to be updated if ImageConfiguration changes
- should not test trivial things which is out of scope of the project. E.g. testing Java serialization (which is the task of the JVM) is not in scope of this project. The same btw for testing setter and getter.
So, testing simple, dump configuration classes does not make sense normally, except when it add some extra logic.
What should be tested for sure are classes which use these configuration.
E.g. the latest PR about allowing to merge property based configuration with XML based configuration introduces some kind of logic to the configuration classes which could (and probably should) be tested. However, the plan is to move these classes to a Optional
to handle the situation better to distinguish between default values and values set by the user when it comes to mergign (where default values should be ignored).
tl;dr - yes, please remove this test ;-) (but thanks for caring about testing, not every contribution does this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for my naive mistakes. I'll update it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @rohanKanojia no need to apologize ! it's awesome that you picked up the story and did the implementation. Highly appreciated !
…hey are only thing in XML Somehow these ${...} parameters are not being picked up by maven properly when used solely without any suffix string literal, the maven parameter string comes off as NULL. So adding a workaround for this. We'll use +${...} as a parameter which would be handled by dmp afterwards
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks !
Fixes #960
Somehow these ${...} parameters are not being picked up by maven
properly when used solely without any suffix string literal, the maven
parameter string comes off as NULL. So adding a workaround for this.
We'll use +${...} as a parameter which would be handled by dmp afterwards