JENKINS_UC_DOWNLOAD_URL usage logic incorrect

[nhojpatrick]

Jenkins and plugins versions report

Environment

jenkins-plugin-manager-2.13.0.jar

What Operating System are you using (both controller, and any agents involved in the problem)?

n/a

Reproduction steps

1. ENV JENKINS_UC_DOWNLOAD_URL http://localhost:8080/jenkins
2. RUN jenkins-plugin-cli --plugins my-plugin:1.2.3

Expected Results

Download attempt from; http://localhost:8080/jenkins/my-plugin/1.2.3/my-plugin.hpi

Actual Results

Download attempt from; https://updates.jenkins.io/download/plugins/my-plugin/1.2.3/my-plugin.hpi

Anything else?

No response

[nhojpatrick]

Fixing the same issue as highlighted here https://github.com/jenkinsci/docker/pull/1299

[juanmacoo]

I don't understand this change, this is exactly how it works after #375 .

[nhojpatrick]

I don't understand this change, this is exactly how it works after #375 .

That code doesn't appear to fully work in all situations. Reading the code it looks like if pluginUrl is empty, then it uses jenkinsUcDownloadUrl. But the update center json contains the pluginUrl, so it will always be present.

But I've just patched it locally so I'm good. I was just trying to help out others.

[juanmacoo]

AH, no, I see what you did. My bad.

[cronik]

wouldn't the correct solution here to use my-plugin:1.2.3:http://localhost:8080/jenkins/my-plugin/1.2.3/my-plugin.hpi? The associated #416 seems to give precedence over and ignore the other download url configuration options like JENKINS_UC_EXPERIMENTAL and JENKINS_INCREMENTALS_REPO_MIRROR .

[ac-miller]

When I read the README, JENKINS_UC_DOWNLOAD_URL is listed as the way to download all of your plugins through a specific mirror. But the behavior of the code does not reflect this. Either the README needs to be updated or a solution like #416 would be better.

From the README:

When this value is set, it replaces the plugin download URL found in the update-center.json file with ${JENKINS_UC_DOWNLOAD_URL}

It does not mention that there is also a check for existence of pluginUrl

[bordenit]

This is a very annoying issue if you want to download artifacts from Artifactory as well. If I pass in the Artifactory url it shouldn't slice my url, and then randomly append /download/plugins to it. It should accept the exact url at least up to the standard folder format for the plugin. What was the workaround if there is no fix?

[cronik]

Been using the plugin manage cli with Artifactory for a while using the following setup:

JENKINS_UC=https://artifactory.example.com/artifactory/jenkins-update-center/dynamic-stable-2.414.3/update-center.json
# don't really use these but set them anyway
JENKINS_UC_DOWNLOAD_URL=https://artifactory.example.com/artifactory/jenkins-update-center/download/plugins
JENKINS_UC_EXPERIMENTAL=https://artifactory.example.com/artifactory/jenkins-update-center/experimental/update-center.json
JENKINS_INCREMENTALS_REPO_MIRROR=https://artifactory.example.com/artifactory/jenkins-update-center/incrementals
JENKINS_PLUGIN_INFO=https://artifactory.example.com/artifactory/jenkins-update-center/current/plugin-versions.json

If a custom plugin is required it happens on per plugin override basis in the plugins spec. The provided download url overrides all other UC configurations.

my-plugin:1.2.3:https://artifactory.example.com/artifactory/jenkins-plugins-generic-local/my-plugin/1.2.3/my-plugin.hpi

Note that Artifactory doesn't support the dynamic plugin folder resolution that the plugin manager attempts to perform so we have to resolve it first and explicitly include it in the JENKINS_UC path. This can be done with the following script.

https updates.jenkins.io/update-center.json version==${LTS_VERSION} -h | grep Location

Another issue with Artifactory is once it caches update-center.json it never downloads it again so you end up with a point-in-time snapshot. You either need to delete the cached file (zap doesn't help) or use some Artifactory plugin to refresh it (see RTFACT-12556). We typically prefer the point-in-time snapshot since we build docker images and it provides a stable plugin set between LTS releases.

Artifactory generic repository cache characteristics combined with Jenkins dynamic plugin folders definitely make this whole process a bear, but it is possible.

Hope this helps.

[bordenit]

Thanks. I just set JENKINS_UC_DOWNLOAD to https://artifactory.example.com/artifactory/ and created a virtual repo from there at the default path to my Jenkins plugin remote repo. I'm fine with it querying the internet for the plugin-versions.json and update-center.json, just want it to scan the plugin downloads with X-ray.