search

timja / jenkins-gh-issues-poc-06-18

0 stars 0 forks source link

[JENKINS-23758] Enhance the update center metadata format to allow listing multiple versions of plugins and core #5283

Open timja opened 10 years ago

timja commented 10 years ago

Currently the update center metadata only permits listing one version of Jenkins core and one version of every plugin. It would be nice if we could advertise not just the latest version of Jenkins / each plugin but also some other versions within the metadata. For example currently the update center will list something like

{
  "core":{
    "buildDate":"...",
    "name":"core",
    "sha1":"...",
    "url":"...",
    "version":"..."
  },
  "plugins":{
    "async-http-client":{
      "buildDate":"...",
      "dependencies":[...],
      "developers":[...],
      "excerpt":"...",
      "labels":["library"],
      "name":"async-http-client",
      "requiredCore":"1.424",
      "sha1":"...",
      "title":"...",
      "url":"...",
      "version":"1.7.8",
      "wiki":"..."
    },
    ...
  },
  ...
}

In order to retain backwards compatibility, it would likely be necessary to introduce the extension as child elements... but care needs to be taken in order to preserve the signature verification semantics... the general idea would be to extend to something like:

{
  "core":{
    "buildDate":"...",
    "name":"core",
    "sha1":"...",
    "url":"...",
    "version":"1.571",
    "history":{
      "1.570":{
"sha1":"...",
"url":"..."
      },
      "1.569":{
"sha1":"...",
"url":"..."
      },
      ...
    }
  },
  "plugins":{
    "async-http-client":{
      "buildDate":"...",
      "dependencies":[...],
      "developers":[...],
      "excerpt":"...",
      "labels":["library"],
      "name":"async-http-client",
      "requiredCore":"1.424",
      "sha1":"...",
      "title":"...",
      "url":"...",
      "version":"1.7.8",
      "wiki":"...",
      "history":{
"1.7.7":{
  "dependencies":[...],
  "requiredCore":"...",
  "sha1":"...",
  "url":"..."
},
"1.7.7":{
  "dependencies":[...],
  "requiredCore":"...",
  "sha1":"...",
  "url":"..."
},
...
      }
    },
    ...
  },
  ...
}

Where each history entry would be keyed by the version and contain a map of values that are a delta from the main entry (so that if requiredCore is the same as the main entry we don't list it... obviously sha1 and url are always going to be different and some values such as developers, title, etc probably don't need to be provided in the history as it is reasonably safe to assume that the current version is what matters... but that is a decision for the system generating the metadata... the principle should be that the format lists the delta.

The format change would enable a lot more flexibility in plugin installation strategies available within Jenkins... the risk is that the metadata format change may make it impossible for older versions of Jenkins to upgrade so great care is required when making the format change... perhaps the simplest way is to make Jenkins core support reading the new format first and then change to the new format once the number of Jenkins instances accessing the OSS update centers that report an older version of Jenkins falls below a specific threshold (i.e. 5%)

Originally reported by stephenconnolly, imported from: Enhance the update center metadata format to allow listing multiple versions of plugins and core
  • status: Open
  • priority: Major
  • resolution: Unresolved
  • imported: 2022/01/10
timja commented 10 years ago

jglick:

I think compatibility can be addressed by just exposing the new format on a new URL. The current *.json is anyway confusing since it is actually JSONP, not JSON. We could produce a new URL convention with an expanded format, in actual JSON (which core can now consume since it has the option to download from the master rather than through the browser).

timja commented 2 years ago

[Originally related to: JENKINS-45235]