plugin-x requires a greater version of Jenkins when using internal remote repository as mirror of jenkins UC

[ysmaoui]

Jenkins and plugins versions report

Environment

trying to build a new jenkins image with latest LTS ( currently 2.414.1 ) with extra plugin `simple-theme-plugin`

the latest version of `simple-theme-plugin` ( 172.v4b_8766c70078 ) requires a more recent core version than the current LTS 

and the plugin-installation-manager-tool  fails to install the older version of the plugin that fits with LTS 2.414.1 ( but this is the case only when a jfrog artifactory remote repo of the jenkins-UC is used

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

Jenkins LTS 2.414.1
plugin : simple-theme-plugin - latest version 172.v4b_8766c70078 , requires jenkins core version 2.421 > LTS
Jenkins_UC: an internal artifactory remote repo ( used in a company where no direct access to the public jenkins_UC exist -- so only through the remote repos)

Reproduction steps

JENKINS_VERSION="2.414.1"

curl --location --silent --fail https://updates.jenkins.io/update-center.actual.json?version=$JENKINS_VERSION | jq --raw-output '.plugins["simple-theme-plugin"].version'
=> using the public update center we get the correct plugin version that we can install with LTS 2.414.1

curl \
    -H "Authorization: Bearer <auth_token>" \
    --location \
    --silent \
    --fail https://<jfrog_artifactory-remote-repo-for-jenkins_UC>/update-center.actual.json?version=$JENKINS_VERSION | jq --raw-output '.plugins["simple-theme-plugin"].version'

=> this returns the latest version of simple-theme-plugin that is not compatible with LTS 2.414.1

when the output of https://<jfrog_artifactory-remote-repo-for-jenkins_UC>/update-center.actual.json and https://<jfrog_artifactory-remote-repo-for-jenkins_UC>/update-center.actual.json?version=$JENKINS_VERSION there is no difference ( as if ?version=$JENKINS_VERSION is not taken into consideration )

Expected Results

curl \
    -H "Authorization: Bearer <auth_token>" \
    --location \
    --silent \
    --fail https://<jfrog_artifactory-remote-repo-for-jenkins_UC>/update-center.actual.json?version=$JENKINS_VERSION | jq --raw-output '.plugins["simple-theme-plugin"].version'

( using the remote repo that mirrors Jenkins_UC )
should provide the plugin version that is compatible with the specified jenkins core version

Actual Results

using the remote repo of Jenkins_UC we get an incompatible version of the plugin ( we get the latest plugin version, but that latest version is not compatible with the current LTS)

Anything else?

is it known that the plugin manager tool is not working well with Jenkins_UC mirrors ?
is there a possible fix / workaround ?

[ysmaoui]

for now my workaround is to point to JENKINS_UC="${JENKINS_UPDATES_MIRROR}/stable/update-center.json" ( so the stable subfolder, to get the version that are valid for LTS )

• usually I need to install the latest LTS, so getting the latest version that fits an LTS would work like this )
  • but the faulty behavior could still happen if we are trying to install plugins for older LTS versions than the latest

[mawinter69]

I would say this is more a problem of the artifactory mirror. It is just not understanding the version argument.
When you got to https://updates.jenkins.io/update-center.actual.json you get redirected to https://updates.jenkins.io/current/update-center.actual.json
when you got to https://updates.jenkins.io/update-center.actual.json?version=2.414.2 you get redirected to https://updates.jenkins.io/dynamic-stable-2.414.1/update-center.actual.json

[MarkEWaite]

I would say this is more a problem of the artifactory mirror. It is just not understanding the version argument.

I agree with @mawinter69 . The Jenkins update center documentation page says:

The top level update site will forward requests to the best matching tiered update site, or the current update site based on the version query parameter sent by Jenkins. (emphasis added)

I assume you'll need to configure a web server that will forward requests to the best matching tiered update site. The site layout documentation gives pointers on what is needed to do that.