-
Bug
-
Resolution: Unresolved
-
Minor
-
None
It appears that dependency resolution for detached and bundled plugins makes no guarantees about which version of a dependency gets installed if different versions are requested. Discovered by while investigating JENKINS-48604, see https://github.com/jenkinsci/jenkins/pull/3201#discussion_r157554968.
I don't have an actual example of this in the wild, but here is the idea of how to reproduce:
- Assume a plugin artifactA with two releases: 1.0 and 2.0
- Assume a plugin artifactB, with a single release 1.0, which has a dependency on artifactA:1.0
- Assume a plugin artifactC, with a single release 1.0, which has a dependency on artifactA:2.0
- Create a fresh Jenkins installation.
- Upgrade Jenkins using a jenkins.war with artifactB:1.0 and artifactC:1.0 in /WEB-INF/detached-plugins
- Expected Result: artifactA:2.0 should be installed.
- Actual Result: The installed version of artifactA depends on which of artifactB and artifactC is processed first, (alphabetical order, hashset iteration order?).
- relates to
-
JENKINS-48614 Optional dependencies of bundled and detached plugins are not upgraded if an outdated version is installed
-
- Open
-
-
JENKINS-48604 Jenkins 2.96 downgrades script-security plugin on core update
-
- Resolved
-
[JENKINS-48615] Dependency resolution for detached and bundled plugins should always use the most recent version out of all versions requested
Link |
New:
This issue relates to |
Link | New: This issue relates to JENKINS-48614 [ JENKINS-48614 ] |
Description |
Original:
Discovered by while investigating I don't have an actual example of this in the wild, but here is the idea of how to reproduce: # Assume a plugin {{artifactA}} with two releases: 1.0 and 2.0 # Assume a plugin {{artifactB}}, with a single release 1.0, which has a dependency on {{artifactA:1.0}} # Assume a plugin {{artifactC}}, with a single release 1.0, which has a dependency on {{artifactA:2.0}} # Create a fresh Jenkins installation. # Upgrade Jenkins using a {{jenkins.war}} with {{artifactB:1.0}} and {{artifactC:1.0}} in {{/WEB-INF/detached-plugins}} # Expected Result: {{artifactA:2.0}} should be installed. # Actual Result: The installed version of {{artifactA}} depends on which of {{artifactB}} and {{artifactC}} is processed first. |
New:
It appears that dependency resolution for detached and bundled plugins makes no guarantees about which version of a dependency gets installed if different versions are requested. Discovered by while investigating I don't have an actual example of this in the wild, but here is the idea of how to reproduce: # Assume a plugin {{artifactA}} with two releases: 1.0 and 2.0 # Assume a plugin {{artifactB}}, with a single release 1.0, which has a dependency on {{artifactA:1.0}} # Assume a plugin {{artifactC}}, with a single release 1.0, which has a dependency on {{artifactA:2.0}} # Create a fresh Jenkins installation. # Upgrade Jenkins using a {{jenkins.war}} with {{artifactB:1.0}} and {{artifactC:1.0}} in {{/WEB-INF/detached-plugins}} # Expected Result: {{artifactA:2.0}} should be installed. # Actual Result: The installed version of {{artifactA}} depends on which of {{artifactB}} and {{artifactC}} is processed first. |
Description |
Original:
It appears that dependency resolution for detached and bundled plugins makes no guarantees about which version of a dependency gets installed if different versions are requested. Discovered by while investigating I don't have an actual example of this in the wild, but here is the idea of how to reproduce: # Assume a plugin {{artifactA}} with two releases: 1.0 and 2.0 # Assume a plugin {{artifactB}}, with a single release 1.0, which has a dependency on {{artifactA:1.0}} # Assume a plugin {{artifactC}}, with a single release 1.0, which has a dependency on {{artifactA:2.0}} # Create a fresh Jenkins installation. # Upgrade Jenkins using a {{jenkins.war}} with {{artifactB:1.0}} and {{artifactC:1.0}} in {{/WEB-INF/detached-plugins}} # Expected Result: {{artifactA:2.0}} should be installed. # Actual Result: The installed version of {{artifactA}} depends on which of {{artifactB}} and {{artifactC}} is processed first. |
New:
It appears that dependency resolution for detached and bundled plugins makes no guarantees about which version of a dependency gets installed if different versions are requested. Discovered by while investigating I don't have an actual example of this in the wild, but here is the idea of how to reproduce: # Assume a plugin {{artifactA}} with two releases: 1.0 and 2.0 # Assume a plugin {{artifactB}}, with a single release 1.0, which has a dependency on {{artifactA:1.0}} # Assume a plugin {{artifactC}}, with a single release 1.0, which has a dependency on {{artifactA:2.0}} # Create a fresh Jenkins installation. # Upgrade Jenkins using a {{jenkins.war}} with {{artifactB:1.0}} and {{artifactC:1.0}} in {{/WEB-INF/detached-plugins}} # Expected Result: {{artifactA:2.0}} should be installed. # Actual Result: The installed version of {{artifactA}} depends on which of {{artifactB}} and {{artifactC}} is processed first, (alphabetical order, hashset iteration order?). |