Looking for collaborators: Redesign of archives pages about plugin-site HOT 10 CLOSED

We also can make the plugin site API check the etag and pull it if changes. There's lots of ways to handle it. I can update update center to split them.

My vote is keep the UI on plugin site.

from plugin-site.

Do you want to keep the current URL or could those be moved? (https://updates.jenkins.io/download/plugins/log-cli/ to the plugin site, https://updates.jenkins.io/download/war/ seems to be a duplicate of https://get.jenkins.io/war/ so maybe those could be merged). If moving is OK, the update center could just dump the information in JSON and the plugin site would process it (as a React component).

from plugin-site.

Would keep the current URLs; it's important that it's effective immediately, otherwise that would negate recent improvements.

from plugin-site.

Initial commit in jenkins-infra/update-center2#469

from plugin-site.

do we have all the data in plugin site? or can get it? I feel like it would make a great new tab like npm does.

from plugin-site.

There's plugin-versions.json but it's very expensive to download (10+ MB IIRC), which is why it's not documented on the root page of https://updates.jenkins.io/

And, again, a big benefit of the current design is that new releases are visible immediately there. It's an easy way to start troubleshooting distribution.

from plugin-site.

Well if the update center would export these as per-plugin JSON, the plugin site could fetch them from client side and render them nicely, there would also be no delay. That would remove the need to maintain frontend code (CSS, template substitution) in an otherwise backend repository, on the other hand the static HTMLs from the PR above could be used also pushed to the mirrors to make them look a bit nicer... not sure what's the best way forward 🤷

from plugin-site.

maintain frontend code (CSS, template substitution) in an otherwise backend repository

If the plugin site didn't show me different information practically every time I reload the page, perhaps. I just don't trust it to act as a stable resource to determine which releases exist or which is the newest one, especially when I (in my admittedly unusual use case) need to be certain what's shown matches the current update center content exactly.

Given my use case, and given the update center is intended as a standalone component, I will move forward with my proposed solution. At a minimum, it should get all the low-tier "security researchers" off my back who keep reporting visible directory indexes as security vulnerabilities. If you want to replace the archives link on the plugins site with something different, feel free.

could be used also pushed to the mirrors

If they're configured to render index.html as directory indexes, which they might not be. Additionally, has a problem when the index page is nontrivial, e.g. for the https://updates.jenkins.io/ index I was unable to use admonitions due to (IIRC) CORS.

from plugin-site.

Well, we can have both. Finish jenkins-infra/update-center2#469 now (mostly for distribution debugging purposes) and enhance the "Releases" tab in the future to also include download links (for Jenkins administrators).

from plugin-site.

I'm going to close this as the new releases tab is powered by update center instead of github, it'll have all the download links baked in.

from plugin-site.