Output a useful URL to download each plugin

[woodrufj]

What feature do you want to see added?

Some organizations need to request outside downloads from an interface shop that has little desire to use client-supplied techniques like the Plugin Manager, and demand a clear, specific URL they can pass to CURL or equivalent.

I'd like to be able to get a valid download URL included in some output form from the Plugin Manager. Such a URL should remain valid for some modest time, such as two weeks.

Including it as a key in the .yaml output would work. Another choice would be another --output format; I suggest file extension .url.

Upstream changes

No response

Are you interested in contributing this feature?

I would like to; but need to get approval from my employer (they have an extensive policy on this, and are willing to approve if I do the right things.) I am a competent Java programmer.

[timja]

I don't think including it in the yaml output makes sense by default.

I don't have a problem with the feature although I'm not sure the cleanest way to include it command and naming wise.

[woodrufj]

We need to realize that the Plugin Manager has the opportunity to do some dynamic optimization w/r/t selecting a download source which cannot be carried through to a static output URL. I don't know if it does, but it might, and this feature shouldn't constrain that. That optimization might change over time; and need not be a documented interface. This "static URL, good for at least ~2 weeks" need is different from what the Plugin Manager can do.

This suggests to me that, if this feature was implemented, the documentation come with a note saying basically "it's better to use the Plugin Manager to do the download". This feature is only for cases where you can't do that.

[timja]

Hmm I'm not sure if what you want will work.

Are you able to handle a static URL get.jenkins.io/plugin/2.46/junit.hpi or are you after the actual download url from a mirror?

I'm not sure about the tool resolving the urls itself, but that's probably something you could build on top pretty easily.

[woodrufj]

I don't have exact definitions. What you specified above looks reasonable (except it gets a 404...) My idea is that anything that can be handed to CURL or WGET and results in a "junit.hpi" file meets the stated requirement. The goal is to minimize the opportunity for the "download shop" to claim they can't get what was asked for. Assume they have zero programming ability.

URL should probably be constrained to be under the "jenkins.io" domain, because some of the responsibility of such a "download shop" is to ensure that downloads come from a reputable source. I'm wondering if that would should constrain redirects to not come from, for example "jenkins-mirror.state-university.cn". My guess is they'll never even see the redirects, tho.

[timja]

(I made up the URL, its approx that with a version that exists)