[JENKINS-58537] Allow some plugin version mismatch#59
[JENKINS-58537] Allow some plugin version mismatch#59stopalopa wants to merge 1 commit intojenkinsci:masterfrom
Conversation
| * @param plugin plugin to set | ||
| * @return | ||
| */ | ||
| public boolean setAlternateVersion(Plugin plugin) { |
There was a problem hiding this comment.
why are we doing this? I assume dependencies will always have a correct version, and we shouldn't fix user errors silently? it should just fail and let the user know what plugin was wrong
There was a problem hiding this comment.
You would think the dependencies would have the right version, but I had previously found an example where this wasn't the case. The vsphere-cloud plugin version says it requires node-iterator-api version 1.5, but the plugin-versions.json has dependency information for 1.5.0 and 1.5.0 is also the version on the download page. I'm looking at it now and it seems like you can download the plugin if 1.5 or 1.5.0 is listed as the version, but I thought that this wasn't working previously. In this case, since the user didn't directly request that plugin (it was just a dependency), if it failed it wouldn't be their fault.
There was a problem hiding this comment.
metadata looks fine to me?
https://updates.jenkins.io/current/update-center.actual.json
this seems like a giant hack and we should fix the plugin if we can find the issue
There was a problem hiding this comment.
The metadata for this plugin is still messed up. Vsphere-cloud says it requires node-iterator-api version 1.5, even though that version doesn't exist for node-iterator-api here: http://updates.jenkins.io/download/plugins/node-iterator-api/ or here: http://mirror.xmission.com/jenkins/updates/current/plugin-versions.json, although apparently it doesn't truly matter in this case since
http://updates.jenkins.io/download/plugins/node-iterator-api/1.5.0/node-iterator-api.hpi and
http://updates.jenkins.io/download/plugins/node-iterator-api/1.5/node-iterator-api.hpi will both download the plugin.
However, in the cases where there's a version mismatch of a dependency and the plugin can't be downloaded, with the newer PRs an error would be thrown immediately if the plugin dependencies can't be resolved (if the plugin dependencies can't be determined from plugin-versions.json, which is dependent on having the right plugin version, or the plugin's dependencies are determined from the manifest, which is still dependent on being able to download the plugin, which is dependent on having the right version to build the download url) and there'd be nothing the user could do.
I see what you're saying though, and this could potentially cause more problems than it solves. I didn't really have any idea of how common this issue might be, but maybe it's pretty rare. I'll close this PR and we can see if it's actually a problem users encounter. I'm also open to suggestions on other ways to address this.
There was a problem hiding this comment.
Looks like both versions are in artifactory:
https://repo.jenkins-ci.org/webapp/#/search/package/eyJzZWFyY2giOiJxdWljayIsInF1ZXJ5Ijoibm9kZS1pdGVyYXRvci1hcGkifQ==
Probably a failed release, sounds like a good idea to hold off on this change 👍
2 participants
https://issues.jenkins-ci.org/browse/JENKINS-58537