[JENKINS-47370] Unable to override global envs after update to 2.1.4 #51
Comments
|
Confirmed here, after reverting to 2.1.3 all the problems gone. 2.1.4 need more testing. |
|
Yes. Overrides is what has been fixed in 2.1.4 Likely the behavior needs to be configurable, so that both 2.1.3 and 2.1.4 behaviors should be supported somehow.
|
|
oleg_nenashev you mean that not being able to override a global env is the intended behavior? |
|
Btw the issue does not limits to overriding variable, it is the main feature of injecting a new variable in the build process that fails for me At least I verified with a few println() that the code is still executed, but anything placed in the hashmap is not saved properly
def map... if (!binding.variables.containsKey('VAR1') || binding.variables.get('VAR1').equals("")) { map['VAR1'] = TOTO; } return map;
2.1.3 => VAR1=TOTO if VAR1 is undefined (expected) 2.1.4 => VAR1=null if VAR1 is undefined (not expected) |
|
Created warning on Wiki: https://wiki.jenkins.io/display/JENKINS/EnvInject+Plugin Probably I should depublish the release for now |
|
Yeah, I was looking for a way to lock the plugin to 2.1.3 and not being notified of newest updates of one plugin I guess it is not possible ? We use to update Jenkins always but have been forced to close connection to Jenkins update servers to not get the regression update. The downgrade button is nice with the plugin but I believe it misses a button like "Shutdown update notifications" per plugins |
|
Code changed in jenkins |
|
Code changed in jenkins Add compatibility notice for |
|
If you are not going to touch this issue anymore this is serious problem here, as administrator It's impossible to communicate to the team the DO NOT UPDATE EnvInject I have to ban all jenkins domains in the host Linux configuration level to stop Jenkins updates My suggestion (only if you are not going to improve this fix causing regressions)
So we can stick to this version, because I believe we need Jenkins updates while we dont need EnvInject updates anymore and want it as it is working actually, the fix you published for it was not affecting us. |
|
I am going to make the change, not sure when. I am traveling since mid-October, and unfortunately I had no time to work on it. Everybody is welcome to submit a pull request. > as administrator It's impossible to communicate to the team the DO NOT UPDATE EnvInjec If your users are able to install and update plugins, IMHO you have a larger problem than EnvInject. Common users should have no access to plugin management if they ignore warnings in Web UI and changelogs. If you do not see the warning in the Update Manager on your instance, let me know. > branch the 2.1.3 version to a newer plugin called "Environment Injector Plugin (Old compatibility version)" It cannot be easily done in such way due to the risk of binary conflicts. Anyway, I am going to improve the configuration and to at least offer the opt-out flag. |
|
fld: Got the same issue. Fixed reverting that plugin |
|
This issue sounds very much like JENKINS-14437. |
|
The regression impact is properly documented && the plugin 2.1.4 is marked as incompatible, so it should minimize the impact on users. 2.1.3 is also available through archives. Although I understand all the possible frustration by plugin users, I decided to NOT work on this issue. The regression has been introduced by me by a fix created during the working time, and I cordially apologize for any inconvenience it caused. Taking the proper regression announcement my team decided to not fix the regression in foreseeable future, because it is focused on other much more important tasks around Jenkins stability. I have no time to work on it during my spare time, because I am focused on the Jenkins core maintenance and other community work. On the other hand, I will be happy to review and deliver pull requests if somebody proposes them. I would also like to highlight that the plugin is waiting for adoption for more than two years. During all this time I was trying to keep this plugin afloat by reviewing the incoming pull requests, fixing defects and keeping the codebase up to date to simplify the handover. But I have not been using this plugin on my own so that such maintenance was a bit lame. I invite all active users to contribute to the plugin by taking ownership of this plugin and of EnvInject API. I am happy to provide any required knowledge transfers and do some assistance during the first months of maintenance |
|
This seems to be fixed in 2.1.6 |
|
it's not |
|
We're heavily affected by this issue and can't upgrade from 2.1.3 because of it. |
|
[Originally duplicated by: JENKINS-53229] |
|
[Originally duplicated by: JENKINS-53213] |
|
Any chance this one may get revisited? |
We have a global setting of JIRA_URL=jira.acme.com
In some jobs we override this in the "Prepare an environment for the run" section to JIRA_URL=jira-staging.acme.com
After upgrading to 1.24 this stopped working. The effective value as seen in shell scripts is jira.acme.com
Setting the value in a "Inject environment variables" build step also has no effect.
The only thing that has an effect is to set the value inside the shell script.
Originally reported by jbochenski, imported from: Unable to override global envs after update to 2.1.4
The text was updated successfully, but these errors were encountered: