-
Improvement
-
Resolution: Unresolved
-
Major
-
linux, jdk 1.7.0_51 jenkins 1.554.1, envinject 1.89
We have a job that uses an 'inject environment variables' build step to inject environment variables from a property file 'target/build.properties'. This property file was verified to exist in the workspace. At first this worked fine.
Then by accident someone created a file /target/build.properties in the root of the file system. What happened next is that the 'inject environment variables' build step would use this new file instead of the file in the job's workspace.
The cause of this behaviour is that the plugin first tries to resolve the path as a relative path against the current working directory (of the jenkins instance). In our case the current working directory was the root directory, which explains why it used /target/build.properties. Only when this file doesn't exist it will lookup the property file relative to the workspace. My expectation was that relative paths would only be looked up in the workspace.
- is duplicated by
-
JENKINS-29811 File used for injection is first looked up in directory containing workspace
-
- Resolved
-
-
-
- Resolved
-
- links to
[JENKINS-23666] Change resolution order for the property files
Code changed in jenkins
User: Oleg Nenashev
Path:
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectNodeProperty/config.jelly
src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectNodeProperty/help-propertiesFilePath.html
http://jenkins-ci.org/commit/envinject-plugin/060832b272a40abc2b4f5eebdfff7fde9a2f3654
Log:
JENKINS-23666 - Document current behavior of NodeProperties (#106)
Mentioned the current issue n the docs.
I really consider changing the behavior even without 2.0
It is a breaking change even if it's correct.
I'm fine with changing the default resolution order in EnvInject 2.x (to be released soon), but maybe we want to retain the original behavior as configurable option.