-
Bug
-
Resolution: Fixed
-
Major
-
None
- is related to
-
JENKINS-18597 provide the option to ignore system changes
-
- Closed
-
[JENKINS-14144] Build config history getting spammed
Darragh Bailey
added a comment - It's not clear why this needs to be added and removed for each build.
Would it be possible to simply add the wrapper upon saving the configuration when envInject is enabled for the build job, and then to simply not remove it?
Darragh Bailey
added a comment - It's not clear why this needs to be added and removed for each build.
Would it be possible to simply add the wrapper upon saving the configuration when envInject is enabled for the build job, and then to simply not remove it? Hi,
I'm one of the maintainers of the JobConfigHistory plugin. We weren't aware of the problem, I only found this issue by chance.
However, we could add a configuration option that allows you to have changes made by the system user ignored by the config history. This would be relatively easy to implement, but means that changes made by the system user will get attributed to the user who makes the next config change. If this would be a solution for your problem, please open an issue at
https://issues.jenkins-ci.org/browse/JENKINS/component/15683
Zoltán Buza
added a comment - I also don't see the point why EnvInject has to modify job config before and after each build.
Can someone explain it in details? I would really appreciate that!
Zoltán Buza
added a comment - I also don't see the point why EnvInject has to modify job config before and after each build.
Can someone explain it in details? I would really appreciate that! 
Kevin Behrens
added a comment - I'm seeing this issue too. I wanted to point out that it not only affects the utility of Job config history, but also SCM Sync configuration plugin.
My setup is old, dating to 2012/07
jenkins 1.473
envinject 1.60
Kevin Behrens
added a comment - I'm seeing this issue too. I wanted to point out that it not only affects the utility of Job config history, but also SCM Sync configuration plugin .
My setup is old, dating to 2012/07
jenkins 1.473
envinject 1.60 Proposal for a partial workaround : https://github.com/jenkinsci/envinject-plugin/pull/17
Seems current design (to add/remove a technical buildwrapper) introduce a possible race condition :
with concurrent builds enabled, build 1 may remove buildWrapper after build 2 added one, but before it actually was used to set build 2 environment.
indeed, proposed https://github.com/jenkinsci/envinject-plugin/pull/18 as a real fix. #17 was only a quick and dirty workaroud
Code changed in jenkins
User: Nicolas De Loof
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/envinject/EnvInjectListener.java
src/main/java/org/jenkinsci/plugins/envinject/service/BuildWrapperService.java
http://jenkins-ci.org/commit/envinject-plugin/a9be296cb4a2293b6123addacaeb629b8ba99ae1
Log:
JENKINS-14144 use a WorkspaceListener to avoid injecting a temporary BuildWrapper
Code changed in jenkins
User: Gregory Boissinot
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/envinject/EnvInjectListener.java
src/main/java/org/jenkinsci/plugins/envinject/service/BuildWrapperService.java
http://jenkins-ci.org/commit/envinject-plugin/dd3834c83ecf6f0c3310ae492893bd63c46d927e
Log:
Merge pull request #18 from ndeloof/JENKINS-14144-alt
[FIXED JENKINS-14144] use a WorkspaceListener to avoid injecting a temporary BuildWrapper
Compare: https://github.com/jenkinsci/envinject-plugin/compare/96a526963b53...dd3834c83ecf
Sorry for the delay in responding.
No it's only those that have envInject configured to do something, once it needs to inject an environment variable into the build, I see the config history recording the addition and removal of the build wrapper "<org.jenkinsci.plugins.envinject.EnvInjectListener_-JobSetupEnvironmentWrapper/>"