Closed timja closed 6 years ago
INFORMACIÓN: Upgrading Jenkins. The last running version was 2.73. This Jenkins is version 2.101. ene 11, 2018 6:55:15 PM hudson.PluginManager loadDetachedPlugins
I am somewhat surprised that 2.89 was not detected as the last running version, but it looks like only the following events save the currently running version, so if none of these happened then it is possible that Jenkins never saves 2.89 as a running version:
There is code that is supposed to check that detached plugins are not downgraded, and I'm not sure why that didn't work. I will try to reproduce locally.
Ah, never mind, it is because the linked code only returns early if it knows the plugin should be installed, so it falls through to the next if statement which returns true because the last version is wrong, so it gets installed.
I think it makes sense to save the running version somewhere that happens more consistently than in the 4 places mentioned previously, and it also makes sense to invert the first check in LoadDetachedPlugins to return false early if the plugin is already installed and is newer than the currently running version.
Exactly, 2.89 was never saved as a running version. My understanding is that saving the running version was also fixed in JENKINS-48365, the problem is that the current code needs to take into account upgrades from versions with the bug in saving the running version.
Yes, the problem is the second if when having the incorrect lastExecVersion.
My understanding is that saving the running version was also fixed in
JENKINS-48365
No, saving the running version was unchanged by JENKINS-48365, it just changed the condition used to decide if an upgrade is occurring (Switched to comparing versions directly instead of checking for InstallState.UPGRADE).
EDIT: Since one of the events that saves the running version is detached plugins being installed when an upgrade is detected, I guess JENKINS-48365 did fix the version number saving issue as it causes upgrades to be detected reliably.
I think that inverting the check in LoadDetachedPlugins will fix the problem for all instances regardless of what version has been detected, but I will make sure to add tests to verify.
Yeah good point, I realized that after I wrote my previous comment and edited. That means that I just need to fix these lines and add some tests.
I realized that of the ways to save the running version:
The first one doesn't really matter, because the restart state is only triggered if the running version is detected to be the same as before, so saving it again is pointless.
Code changed in jenkins
User: Devin Nusbaum
Path:
core/src/main/java/hudson/PluginManager.java
test/src/test/java/jenkins/install/LoadDetachedPluginsTest.java
test/src/test/resources/jenkins/install/LoadDetachedPluginsTest/upgradeFromJenkins2WithNewerPlugin.zip
http://jenkins-ci.org/commit/jenkins/d6298979581da67336f077cda9fd218eb790bdb3
Log:
JENKINS-48899 Do not downgrade detached plugins when upgrading Jenkins (#3229)
It has been fixed and released in 2.103
Code changed in jenkins
User: Devin Nusbaum
Path:
core/src/main/java/hudson/PluginManager.java
test/src/test/java/jenkins/install/LoadDetachedPluginsTest.java
test/src/test/resources/jenkins/install/LoadDetachedPluginsTest/upgradeFromJenkins2WithNewerPlugin.zip
http://jenkins-ci.org/commit/jenkins/7b6c86dc581e573a91802639647630ae40d8e208
Log:
JENKINS-48899 Do not downgrade detached plugins when upgrading Jenkins (#3229)
(cherry picked from commit d6298979581da67336f077cda9fd218eb790bdb3)
Seems to be caused by
JENKINS-48365, similar toJENKINS-48604but not the same.Steps to reproduce:
The problem seems to be that given that upgrade detection was also fixed by
JENKINS-48365in the upgrade from 2.89 to 2.101 the core thinks it is upgrading from 2.73 so it "blindly" install command-launcher without checking if it is installed, overwriting the installed version with the bundled, older one.Last step logs:
Originally reported by andresrc, imported from: Jenkins downgrades detached plugins on upgrade