During development, we sometimes need to figure out whether a behavior is a regression, or just in general to see how Jenkins used to behave in the past. This is complicated by update sites only being generated for the last year of Jenkins releases, and older Jenkinses will fail to install plugins that have too recent minimum requirements. This document explains how to work around that.
Jenkins infrastructure uses mirrors to distribute update site downloads and metadata. These mirrors are not automatically cleaned up, so when the project stops publishing an update site tier (~ downloads for a specific version of Jenkins), those remain available on mirrors.
See e.g. https://archives.jenkins.io/updates/ for the various update sites available on the archives mirror.
Select one that looks reasonable, e.g. stable-2.150 if you’re running Jenkins 2.150.x, and configure Jenkins with the update site URL: https://archives.jenkins.io/updates/stable-2.150/update-center.json
Since these update sites haven’t been updated in a while, you probably need to disable the certificate verification. Doing so is generally unsafe, as it enabled man-in-the-middle attacks, so should only be done in an isolated environment.
Run the following in the Jenkins script console: hudson.model.DownloadService.signatureCheck = false
This will remain effective until Jenkins is restarted.
These are historical snapshots of Jenkins update sites as they were months or years ago. Recently published plugins or newer releases of older plugins will not be available, even if they’re compatible with older versions of Jenkins. It’s a good way to install compatible versions of common plugin dependencies though, before reverting the configuration change and installing more recently published plugins.