-
Bug
-
Resolution: Fixed
-
Minor
-
None
If you inject a properties file with new line characters it is not parsing these correctly. Also it appears to be treating the properties file and the properties content differently.
To address this issue I submitted a pull request to force parsing as a standard Java properties object and then also extracted the parsing logic to be the same for both the content box and property files.
- is duplicated by
-
-
- Open
-
-
-
- Resolved
-
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
- links to
[JENKINS-31573] New line characters are not parsing correctly
Code changed in jenkins
User: John Jones
Path:
src/main/java/org/jenkinsci/plugins/envinject/service/PropertiesLoader.java
src/main/java/org/jenkinsci/plugins/envinject/util/SortedProperties.java
src/test/java/org/jenkinsci/plugins/envinject/sevice/PropertiesGetterTest.java
src/test/java/org/jenkinsci/plugins/envinject/sevice/PropertiesLoaderTest.java
http://jenkins-ci.org/commit/envinject-plugin/e64c47d89c0c9865e5ab6578172cf6d203e3b8a0
Log:
[FIXED JENKINS-31573] New line characters not parsing correctly (#78)
- Updated test to use LinkedHashMap since it expects order to be correct
- Used Java properties to parse content and files instead of custom class.
- Adding back in SortedProperties as a deprecated class
Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
http://jenkins-ci.org/commit/envinject-plugin/980150dd4dd931751155995be76416faa4201ce2
Log:
[FIXED JENKINS-38607] - Add explicit compatibility notice for the JENKINS-31573 change
Also updates maven-hpi-version to the version declared in POM
Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
src/main/resources/index.jelly
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectBuilder/config.jelly
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectNodeProperty/config.jelly
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectNodeProperty/global.jelly
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectPasswordWrapper/config.jelly
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectVarList/index.jelly
http://jenkins-ci.org/commit/envinject-plugin/df2515692aa050cfda1ece0ffdbc5c7cb5487c8e
Log:
Merge pull request #108 from oleg-nenashev/bug/JENKINS-38607
[FIXED JENKINS-38607] - Add explicit compatibility notice for the JENKINS-31573 change
Compare: https://github.com/jenkinsci/envinject-plugin/compare/8aec81f23148...df2515692aa0
Dirk Heinrichs
added a comment - What would be the best update strategy here?
We just found out the hard way that updating the plugin to 1.93.1 breaks many of our Windows based builds, so we downgraded to 1.92.1 again. Would it be OK to first fix/double all backslashes and upgrade the plugin afterwards? (Or, i.o.w.: Can 1.92.1 handle the doubled backslashes?)
Dirk Heinrichs
added a comment - What would be the best update strategy here?
We just found out the hard way that updating the plugin to 1.93.1 breaks many of our Windows based builds, so we downgraded to 1.92.1 again. Would it be OK to first fix/double all backslashes and upgrade the plugin afterwards? (Or, i.o.w.: Can 1.92.1 handle the doubled backslashes?) dhs there is a known issue with nested variables (JENKINS-39403), which may be a problem. Regarding the double backslashes in 1.92.1, it actually depends on the platforms behavior and on your use-cases
Dirk Heinrichs
added a comment - oleg_nenashev, AFAIK we don't use nested variables, so that shouldn't be a problem.
Reg. platforms behaviour and use cases: We mostly use it to propagate state between different "Execute Windows batch" steps of the same or even up-/downstream jobs. Some of this is telling the other build step the path of it's results, for example:
Execute batch (writes UNC path to property file as "VARIABLE=\\server\share\folder") -> EnvInject that property file -> Execute batch
So, can we first (while still running on 1.92.1) fix the batch scripts to write out "VARIABLE=\\\\server\\share
folder", see if everything works and then upgrade to 1.93.1?
Dirk Heinrichs
added a comment - oleg_nenashev , AFAIK we don't use nested variables, so that shouldn't be a problem.
Reg. platforms behaviour and use cases: We mostly use it to propagate state between different "Execute Windows batch" steps of the same or even up-/downstream jobs. Some of this is telling the other build step the path of it's results, for example:
Execute batch (writes UNC path to property file as "VARIABLE=\\server\share\folder") -> EnvInject that property file -> Execute batch
So, can we first (while still running on 1.92.1) fix the batch scripts to write out "VARIABLE=\\\\server\\share folder", see if everything works and then upgrade to 1.93.1? 
Nice. I've been troubleshooting a problem with a Windows build that injects a multi-line properties file. All of my Linux jobs that inject multi-line properties files work OK.
As a workaround, I was able to get it to get the property file to inject correctly in Windows by running unix2dos on it as a build step.