Adding github release info to https://plugins.jenkins.io/

[Gavin Mogan]

Hey Everyone,

In a recent PR, we got to talking about adding github releases info to the wiki, but was mentioned its probably better to add it to plugins.jenkins.io instead (Totally agree, plus i have more skills in this area).

But I'm a little conflicted about solutions before I start doing any development I thought I could get some feedback.

Idea

1) Pure javascript solution - Make the browser access github apis as anonymous (ex https://api.github.com/repos/jenkinsci/blueocean-plugin/releases) and output the content directly from the front end.

Some Advantages:

* No need to check every plugin to see if they are using github releases, just the one currently being rendered.

* Simple straightforward change, only frontend code

Some Downsides:

* Could hit the anonymous per ip rate limits and things could break

* May not work with the Server side rendering (probably would want to skip it to avoid slamming github anyways)

2) Update the backend api to fetch the result.

Some Advantages:

* As we do with all the other plugin data

* cached so wouldn't need each user to hit github

Some Downsides:

* Would have to grab data for every plugin

* So many moving parts, server, elastic search, plugin data job.

* Rate limit for the actual server, not spread across all users

* Less gavin skillset

Probably for 2, since its all repos we manage, we could do an webhook for release being created, and only update on that condition, but I'm still unsure about that.

So what says you all, good/bad/other ideas?

Gavin

[Jesse Glick]

On Thu, Jun 20, 2019 at 12:03 AM 'Gavin Mogan' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
> we got to talking about adding github releases info to the wiki, but was mentioned its probably better to add it to plugins.jenkins.io instead

I think this needs a somewhat broader discussion of what the landing
page for a plugin (hosted in @jenkinsci) ought to be. There are two
basic kinds of visitors, I would think:

· People who want to know general stuff about the plugin—what it does,
how to configure it, etc.
· Admins already running the plugin who see an update notification
inside Jenkins and want to check release notes before accepting.

And we have a number of places where content is either defined,
displayed, or linked to:

· wiki.jenkins.io/display/JENKINS/*+Plugin
· `jenkinsci/*-plugin/README.md`
· https://jenkins.io/doc/ for certain fundamental plugins.
· jenkinsci/*-plugin/releases
· plugins.jenkins.io
· `jenkinsci/*-plugin/pom.xml#/project/url`
· `$jenkins/pluginManager/`

Using Confluence is awful in my experience: clumsy to edit, no code
review, mediocre speed & reliability, hard to keep in synch with code
changes.

My inclination is to say that the best practice would be for the `url`
ought to point to plugins.jenkins.io, which ought to be (somehow)
aggregating `README.md` + `releases`, but that the plugin manager
ought to link directly to `releases`.

[Daniel Beck]

> On 20. Jun 2019, at 15:44, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> My inclination is to say that the best practice would be for the `url`
> ought to point to plugins.jenkins.io, which ought to be (somehow)
> aggregating `README.md` + `releases`, but that the plugin manager
> ought to link directly to `releases`.

This doesn't really downgrade gracefully for plugins that don't use releases. (And FTR, Jenkins currently links to the POM <url> from the plugin manager "Installed" tab, as that's what the plugin specifies, while "Available"/"Updates" link to the plugin site, as that's what the update center provides -- this can probably be improved a bit too, allowing the update center to override the URL linked to from "Installed" for any plugin it advertises, with a downgrade to <url> if unavailable).

Ideally we improve plugins.jenkins.io to be a sufficiently useful resource for both use cases. For most plugins, we know their GitHub repository, so should be able to include information from there on plugins.jenkins.io, having release notes (both manually maintained on the wiki, on GitHub with CHANGELOG.md, or via GH releases) and documentation (wiki or GH) side by side -- that's more or less been the idea from the beginning, but so far nobody had the time to actually do it.

Regarding the wiki page, that's not _really_ been necessary for a few years. It's just that plugins.jenkins.io can only currently inline wiki pages, not GitHub repos/pages (which it would just link to[1]) -- but with https://github.com/jenkins-infra/plugin-site-api/pull/54 it looks like that's about to change.

1: For example https://plugins.jenkins.io/google-kubernetes-engine

[Jesse Glick]

On Thu, Jun 20, 2019 at 4:37 PM Daniel Beck <m...@beckweb.net> wrote:
> This doesn't really downgrade gracefully for plugins that don't use releases.

Sure, I am talking about how I would like things to look for plugins
which opt in to current recommendations.

> plugins.jenkins.io can only currently inline wiki pages, not GitHub repos/pages (which it would just link to) -- but with jenkins-infra/plugin-site-api #54 it looks like that's about to change.

Great!

[Gavin Mogan]

Can we add a new optional field to the poms to say where release notes are?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1eneYQ2a8KuUbbix%3DQ%3DO692E7Qvz6PS9s6ox6%3DC5PpKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Gavin Mogan]

So looks like one either uses properties, or a new doctype. I feel like the doc type might be way too hard.

<jenkins.plugin.changelog.url>

Would that be too hackish? For the site backend?

[Daniel Beck]

Don't start here.

This should be done (IMO) via new entries in the plugin's MANIFEST.MF file.

To accomplish that, extend maven-hpi-plugin to have a new option for the changelog or whatever, and if set and non-empty, add that to the manifest.

Then update the plugin parent POM to the new release of maven-hpi-plugin, and parameterize the new option based on a property.

Then you can update the plugin's POM to the latest parent POM and set the property.

[Zbynek Konecny]

Hi,

there is already an open PR for the maven-hpi-plugin to add the metadata to Manifest:
https://github.com/jenkinsci/maven-hpi-plugin/pull/68

Cheers,
Zbynek