Jenkins Plugins - LTS

[Jesse Farinacci]

Greetings,

I am recently having a lot of frustration trying to fight fires for
many of my plugins. I am happy that people other than myself are using
the plugins, but it is very frustrating to work on a bug, ask someone
to test a fix, and then they will only test with the latest Jenkins,
and then they find a new issue seemingly unrelated to anything I
touched. I think there is a bigger problem here, in that it seems to
me in my personal experience over the past few months that Jenkins
plugin release compatibility is waning. I don't understand why things
will work in one release but break in another, and I barely have the
time to figure it out.

Anyhow, this is all just a lead up to my announcement that I will not
be updating any of my plugins to extend beyond Jenkins LTS. I will
only test against the latest LTS, and I will CLOSE-WONTFIX any JIRA
against any of my plugins which exploits anything newer than the
latest Jenkins LTS. For any new plugins I generate, I will try to use
the most recent LTS if possible.

This gripe dovetails with a project[1] I was working on to get all
plugins up to common release levels. I would really enjoy seeing 80%+
of all plugins updated (so at least they are tested there) to the
latest Jenkins LTS, within a month or so after each new major LTS
release.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Plugin+Report+Card

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

[Jan Ruzicka]

Hi Jesse and list,

The Plugin Report Card is cool.
Is there a way to fix the graph on the page?

It links to /download/temp/chart763702489395732759.png

The template section mentioning chart has this:
{chart:title=Distribution|type=bar|width=800}
|| Required Core ||#foreach( ${requiredCore} in ${requiredCores} ) $!{requiredCore.name} ||#end

|| Total Plugins |#foreach( ${requiredCore} in ${requiredCores} ) $!{requiredCore.count} |#end
{chart}
----
Is there a way to highlight plugins depending on releases other then LTS ?

----
Is there any differentiation between latest and latest released version of the plugin?
I can see developers trying to catch latest and greatest with snapshots and then dialing it down to LTS for release.

----
How often does the plugin report run?
I see daily updates up to Jun 11.

Thanks
Jan

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

[Jesse Glick]

On 07/04/2012 08:06 PM, Jesse Farinacci wrote:
> I would really enjoy seeing 80%+ of all plugins updated [...] to the latest Jenkins LTS

A minor glitch here: org.jenkins-ci.plugins:plugin is available in 1.447, but not 1.447.2. Probably it does not matter much, but if I understand correctly it would mean
that hpi:run and HudsonTestCase would be using a core version lacking some important fixes which might affect plugin usage.

(Is there a reason the root pom.xml omits <module>plugins</module>?)

[Jesse Farinacci]

Greetings,

On Thu, Jul 5, 2012 at 11:18 AM, Jan Ruzicka
<jan.r...@comtechmobile.com> wrote:
> The Plugin Report Card is cool.
> Is there a way to fix the graph on the page?

This was caused as an unhappy side effect by the totally awesome
Confluence plugin Kohsuke wrote[1] and deployed to our instance. I
fixed the graph not displaying by adding 'nocache' label to the page.

> Is there a way to highlight plugins depending on releases other then LTS ?

I suppose there is, but I'm not sure I see how valuable it it is.. you
can easily fork the project[2] and create a pull request to support
that feature.

[1] http://kohsuke.org/2012/06/22/potd-confluence-static-cache-generator-plugin/
[2] https://github.com/jenkinsci/backend-plugin-report-card

> Is there any differentiation between latest and latest released version of the plugin?
> I can see developers trying to catch latest and greatest with snapshots and then dialing it down to LTS for release.

The report is generated against the master tree for each plugin, it
isn't based against the latest release. It hasn't been my experience
to develop against the latest Jenkins release and then dial it down to
LTS. Sorry, but I don't know why anyone would do this.

> How often does the plugin report run?
> I see daily updates up to Jun 11.

It was supposed to run daily via a job on Jenkins-on-Jenkins, I will
check out why it isn't. Good catch!

[Jesse Farinacci]

Greetings,

On Thu, Jul 5, 2012 at 11:36 AM, Jesse Farinacci <jie...@gmail.com> wrote:
> On Thu, Jul 5, 2012 at 11:18 AM, Jan Ruzicka

>> How often does the plugin report run?
>> I see daily updates up to Jun 11.
>
> It was supposed to run daily via a job on Jenkins-on-Jenkins, I will
> check out why it isn't. Good catch!

This was failing because of the GitHub API v2 being sunset. I updated
to the latest v3 API, and everything is working again. Thanks for
catching that!

[Jesse Farinacci]

Greetings,

On Thu, Jul 5, 2012 at 11:18 AM, Jesse Glick <jgl...@cloudbees.com> wrote:
> A minor glitch here: org.jenkins-ci.plugins:plugin is available in 1.447,
> but not 1.447.2. Probably it does not matter much, but if I understand
> correctly it would mean that hpi:run and HudsonTestCase would be using a
> core version lacking some important fixes which might affect plugin usage.
>
> (Is there a reason the root pom.xml omits <module>plugins</module>?)

Ah, yes I think you're correct. That should probably get updated
during the whole LTS release process so that plugins can depend on
that requiredCore. And I have no idea why plugins is omitted! Probably
some relic of Jenkins' ancient past.. We'd need someone intimately
familiar with the release process to say why it is not there.

[Stephen Connolly]

On 6 July 2012 16:17, Jesse Farinacci <jie...@gmail.com> wrote:

Greetings,

On Thu, Jul 5, 2012 at 11:18 AM, Jesse Glick <jgl...@cloudbees.com> wrote:
> A minor glitch here: org.jenkins-ci.plugins:plugin is available in 1.447,
> but not 1.447.2. Probably it does not matter much, but if I understand
> correctly it would mean that hpi:run and HudsonTestCase would be using a
> core version lacking some important fixes which might affect plugin usage.
>
> (Is there a reason the root pom.xml omits <module>plugins</module>?)

Ah, yes I think you're correct. That should probably get updated
during the whole LTS release process so that plugins can depend on
that requiredCore. And I have no idea why plugins is omitted! Probably
some relic of Jenkins' ancient past.. We'd need someone intimately
familiar with the release process to say why it is not there.

I suspect a side-effect of having plugins in tree with svn and not wanting to release the plugins tree as part of the whole release process...

Though personally I think the current plugin parent strategy is *all wrong* and internally in CloudBees we use a different strategy... I have mentioned to KK that we should explore my approach for OSS but he has been reluctant so far to push such a change out.

-Stephen

[Jesse Glick]

On 07/09/2012 04:38 AM, Stephen Connolly wrote:
> internally in CloudBees we use a different strategy [for plugin parent]

Which seems to work nicely. [1] is tricky, whereas when artifacts are specified in the parent POM using <version>${jenkins.version}</version> it is easy to create a
settings.xml entry like

<profile>
<id>jenkins-snapshot</id>
<properties>
<jenkins.version>1.475-SNAPSHOT</jenkins.version>
</properties>
</profile>

and then just use e.g. 'mvn -Pjenkins-snapshot hpi:run' to test a plugin against a modified core. Also the ${jenkins.version} system addresses the current problem that in
order to get access to a bugfix in the parent POM - such as ability to build using JDK 7, fixed in 1.420 (98b7c4e) - you also introduce a possibly unwanted core API
dependency.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Choosing+Jenkins+version+to+build+against#ChoosingJenkinsversiontobuildagainst-Todependonthelatestbleedingedgetrunk%28orRC%29

[Kohsuke Kawaguchi]

Do you have ticket numbers for some of those issues? I'd like to take
a look into some of those.

Perhaps it's related to the UI changes? I can't really think of any
recent changes in how we develop the core that creates a difference.

2012/7/5 Jesse Farinacci <jie...@gmail.com>:

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

2012/7/9 Stephen Connolly <stephen.al...@gmail.com>:

> On 6 July 2012 16:17, Jesse Farinacci <jie...@gmail.com> wrote:
>>
>> Greetings,
>>
>> On Thu, Jul 5, 2012 at 11:18 AM, Jesse Glick <jgl...@cloudbees.com> wrote:
>> > A minor glitch here: org.jenkins-ci.plugins:plugin is available in
>> > 1.447,
>> > but not 1.447.2. Probably it does not matter much, but if I understand
>> > correctly it would mean that hpi:run and HudsonTestCase would be using a
>> > core version lacking some important fixes which might affect plugin
>> > usage.
>> >
>> > (Is there a reason the root pom.xml omits <module>plugins</module>?)
>>
>> Ah, yes I think you're correct. That should probably get updated
>> during the whole LTS release process so that plugins can depend on
>> that requiredCore. And I have no idea why plugins is omitted! Probably
>> some relic of Jenkins' ancient past.. We'd need someone intimately
>> familiar with the release process to say why it is not there.
>
>
> I suspect a side-effect of having plugins in tree with svn and not wanting
> to release the plugins tree as part of the whole release process...

Yes, I need to fix this.

>
> Though personally I think the current plugin parent strategy is *all wrong*
> and internally in CloudBees we use a different strategy... I have mentioned
> to KK that we should explore my approach for OSS but he has been reluctant
> so far to push such a change out.

I think the only thing I was reluctant about is to stop pushing out
the current plugin POM and forcing existing plugins to do some
disruptive changes, but by all means we should start posting a
separate parent POM that lets you specify the version as a property.

I think you already have that parent POM, so maybe we can just create
a new repository that contains that one POM?

> -Stephen
>
>>
>>
>> -Jesse
>>
>> --
>> There are 10 types of people in this world, those
>> that can read binary and those that can not.
>
>

--
Kohsuke Kawaguchi

[Stephen Connolly]

When the Jenkins ircbot is back online I will give it a shot, after my current task that is ;-)