Bug (or "undocumented feature?") in dependency resolution using --latest true
#250
Comments
pwillis-els
changed the title
--latest true--latest true
|
I encountered the same issue. I thought at first that some plugin did really require a higher version of one of my plugin but I then discovered that it was due to the "latest" option. We update our Jenkins through a versioned/automated build. Given that, we fixed the version of plugins for reproducibility concerns. So it was a little confusing to have that behavior by default for plugins we explicitly set the version. |
|
I was also confused by the message that was displayed when I had enumerated each plugin version explicitly. I ran the command: I was confused that the message says "Plugin git:4.6.0 depends on git-client:3.7.0" when I know that git plugin 3.6.0 depends on git client plugin 3.6.0, not git client plugin 3.7.0. In my case, it would have helped if the phrasing of the message made it clear that the explicitly declared dependency on git-client:3.6.0 was being upgraded to git-client:3.7.0 because I had not provided the command line argument I had the desired results when I added Would it be enough to rework the user error message to say: |
|
no I think it should allow you to use that version, it should only selecting latest of transitive dependencies if it's defined on the top level AND is compatible then it should select what you have defined |
|
Since multiple people have experienced this bug (i've talked to a few more), can we come up with some possible fixes and have one implemented?
Thoughts? |
|
I prefer option 1, describe the behavior more precisely so that users understand that they have a choice with plugin installation manager that was not available with the plugin installation shell scripts. In those cases where the precise versions of all plugins are specified, the |
|
A limitation with option 1 is that when a new dependency is added to a plugin it won’t get updated until someone notices that it’s missing from their plugin list I still think 3 is the most sane option... (I don’t have a lot of time for this repo and to get something fixed the quickest way is to send a PR) |
|
As someone who just spent yesterday trying to understand this, option 3 is what I expected the behaviour to be before I learned that My expectation is:
That last point is similar to what currently happens, except the error would be because I pinned something incompatible, not because the tool chose to ignore my pinned versions. The only case where I would want to pin something meaning "version X or higher" without meaning "latest" is if I want to accept patch or minor updates only (e.g. like npm where pinning |
|
above was merged |
|
I encountered similiar isssues. Today I need build a custom Jenkins Docker Image from base Docker Image installPlugins:
- kubernetes:1.29.4
- workflow-aggregator:2.6
- git:4.7.1
- configuration-as-code:1.51
- kubernetes-client-api:4.13.2-1If I use option FROM jenkins/jenkins:2.289.1-jdk11
RUN jenkins-plugin-cli --verbose --latest true --plugins \
kubernetes-client-api:4.13.2-1 kubernetes:1.29.4 workflow-aggregator:2.6 git:4.7.1 configuration-as-code:1.51 then with the same behavior with PR: https://github.com/jenkinsci/plugin-installation-manager-tool/pull/325/files the Docker build process failed, due to I pinned If I use option FROM jenkins/jenkins:2.289.1-jdk11
RUN ls -alh
RUN jenkins-plugin-cli --verbose --latest false --plugins \
kubernetes-client-api:4.13.2-1 kubernetes:1.29.4 workflow-aggregator:2.6 git:4.7.1 configuration-as-code:1.51 Then Docker build process succeed. But when I inspect installed plugins versions in build log, It showed that some installed plugins versions is incorrect: $ docker build -f Dockerfile .
Sending build context to Docker daemon 8.192kB
Step 1/4 : FROM jenkins/jenkins:2.289.1-jdk11
---> 416c6656c1cd
Step 2/4 : RUN ls -alh
---> Using cache
---> d80f607455a9
Step 3/4 : RUN jenkins-plugin-cli --verbose --plugins kubernetes-client-api:4.13.2-1 kubernetes:1.29.4 workflow-aggregator:2.6 git:4.7.1 configuration-as-code:1.51 --latest false
---> Running in 560577e701c3
No .txt or .yaml file containing list of plugins to be downloaded entered.
Will install new plugin kubernetes 1.29.4
Will install new plugin pipeline-milestone-step 1.3.1
Will install new plugin snakeyaml-api 1.27.0
Will install new plugin trilead-api 1.0.13
Will install new plugin workflow-multibranch 2.20
Will install new plugin docker-workflow 1.14
Will install new plugin handlebars 1.1
Will install new plugin pipeline-stage-tags-metadata 1.3.2
Will install new plugin git-client 3.7.1
Will install new plugin variant 1.4
Will install new plugin scm-api 2.6.4
Will install new plugin kubernetes-client-api 4.13.2-1
Will install new plugin pipeline-stage-step 2.3
Will install new plugin pipeline-model-extensions 1.7.2
Will install new plugin configuration-as-code 1.51
Will install new plugin workflow-cps-global-lib 2.11
Will install new plugin workflow-support 2.20
Will install new plugin mailer 1.32.1
Will install new plugin jackson2-api 2.12.1
Will install new plugin pipeline-rest-api 2.10
Will install new plugin workflow-scm-step 2.12
Will install new plugin pipeline-model-api 1.3.2
Will install new plugin lockable-resources 2.3
Will install new plugin pipeline-input-step 2.8
Will install new plugin metrics 4.0.2.6
Will install new plugin momentjs 1.1
Will install new plugin git-server 1.7
Will install new plugin credentials-binding 1.13
Will install new plugin workflow-aggregator 2.6
Will install new plugin kubernetes-credentials 0.8.0
Will install new plugin pipeline-stage-view 2.10
Will install new plugin pipeline-build-step 2.7
Will install new plugin credentials 2.3.15
Will install new plugin pipeline-model-definition 1.3.2
Will install new plugin caffeine-api 2.9.1-23.v51c4e2c879c8
Will install new plugin workflow-step-api 2.23
Will install new plugin plain-credentials 1.7
Will install new plugin matrix-project 1.18
Will install new plugin bouncycastle-api 2.18
Will install new plugin docker-commons 1.14
Will install new plugin jquery-detached 1.2.1
Will install new plugin ace-editor 1.0.1
Will install new plugin git 4.7.1
Will install new plugin icon-shim 1.0.3
Will install new plugin authentication-tokens 1.4
Will install new plugin workflow-durable-task-step 2.22
Will install new plugin ssh-credentials 1.18.1
Will install new plugin cloudbees-folder 6.15
Will install new plugin durable-task 1.35
Will install new plugin workflow-basic-steps 2.11
Will install new plugin workflow-job 2.25
Will install new plugin jsch 0.1.55.2
Will install new plugin pipeline-graph-analysis 1.1
Will install new plugin junit 1.3
Will install new plugin structs 1.22
Will install new plugin apache-httpcomponents-client-4-api 4.5.13-1.0
Will install new plugin workflow-cps 2.89
Will install new plugin display-url-api 2.3.1
Will install new plugin script-security 1.76
Will install new plugin pipeline-model-declarative-agent 1.1.1
Will install new plugin branch-api 2.0.18
Will install new plugin workflow-api 2.41In above plugins versions, Plugin-Dependencies:
...
workflow-api:2.41
workflow-scm-step:2.11
workflow-step-api:2.23
workflow-support:3.7
...and Plugin-Dependencies:
...
workflow-multibranch 2.20
workflow-scm-step 2.6
workflow-step-api 2.16
workflow-support 2.20
...If plugin version resolve correctly, due to this behavior, when I start Docker Image after build, Jenkins cannot started successfully: Compare with kubernetes-client-api:4.13.2-1
kubernetes:1.29.4
workflow-aggregator:2.6
git:4.7.1
configuration-as-code:1.51FROM jenkins/jenkins:2.289.1-jdk11
RUN ls -alh /usr/share/jenkins/ref/plugins
COPY plugins.txt /usr/share/jenkins/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/plugins.txtWhen build image process run, plugins versions is resolved like that: An example, |
|
Hi , on marking latest as false, I am still getting dependencies issue, can you please help? |
Best to open a separate issue with precise details that describe the problem you are seeing. Most of the problems that I've seen with dependencies have been due to users providing an incomplete list of plugins. |
I'm not sure if this is expected behavior, but it certainly was unexpected to me, and seems like it might be a bug. Slightly complicated to explain, but I'll try...
Expected behavior:
But this is what is happening:
--latestdefault oftrue), regardless of what has been pinned.The "bug" here is that the list User A is providing is complete and accurate. All plugins + dependencies have been provided and pinned to their minimum required versions. But the tool is erroring out, seemingly due to ignoring the pinned items in favor of the latest dependencies it wants to install.
Maybe I missed something and something else is going on? But I've combed through all the
MANIFEST.MFfiles of all the plugins and even theplugin-versions.jsonfile, and all the dependencies shown below seem to be correct. It seems to be just--latest truethat is failing.The plugins below has been crafted to provide the minimum versions of all plugins + dependencies in this chain.
Sample failure with
--latest true:Sample success with
--latest false:The text was updated successfully, but these errors were encountered: