XTrigger-Lib needs maintenance/release

[Tony Noble]

I realise this isn't a plugin as such, so not sure how the process would work.

A number of trigger plugins, mine included (urltrigger) rely on xtrigger-lib to perform the core job handling and cron scheduling.  From what I can see, Gregory Boissinot used to maintain this, along with the dependent plugins, but I'm guessing he stepped back from them all at the same time.

At the moment, a number of issues within xtrigger-lib prevent the dependent plugins from being pipeline-compliant.  Proposed fixes for them have been merged by @oleg-nenashev , but no release has been performed, so they're not specifically useable.

I guess the questions is - how do I go about getting a release created?  I'm happy to take the responsibility on myself, if that's what's required, but as mentioned above, I'm not sure how the process would work for a lib rather than a plugin.

Tony

[Oleg Nenashev]

FTR, there was a thread about the next steps for XTrigger lib: https://groups.google.com/forum/#!searchin/jenkinsci-dev/XTrigger%7Csort:date/jenkinsci-dev/voKBrqz7V_o/rCP5ysYZBwAJ

AFAICT, we still need to get a release, and ownership has not been fully transferred to anyone.

https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-xtrigger-lib.yml references only Gregory

Tony, if you are fine with that, we can just co-maintain the library for now.

In my case I would rather want to help to get it over the line and to help with further releases if needed, I have no time to really "maintain" the component

WDYT?

[Tony Noble]

Hi @oleg-nenashev,

That sounds ideal.  I do remember the thread now, but have to admit - I'm very much of the 'just keep it working' approach for the moment, until I get my head around how to create plugins that are essentially subclasses of other plugins (which is what would need to happen if xtrigger was migrated to be a plugin).  And if it's even possible to do all this without breaking existing user configuration.

I can raise the PR for repository permissions - what needs to happen for commit access to the repo?

Tony

--
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/edb112a3-84f7-4acf-8581-ccff5caf4cdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Thu, Jul 11, 2019 at 6:14 AM Tony Noble <tony....@gmail.com> wrote:
> how to create plugins that are essentially subclasses of other plugins (which is what would need to happen if xtrigger was migrated to be a plugin)

Completely routine; you just declare a Maven dependency and you are
done. Certainly less exotic and trouble-prone than the current design.

https://jenkins.io/doc/developer/plugin-development/dependencies-and-class-loading/

> if it's even possible to do all this without breaking existing user configuration.

Assuming Java package names are left untouched, there should be no
effect on user settings.

At any rate,

> I'm not sure how the process would work for a lib rather than a plugin.

The release process for the library is identical to that for a plugin:

mvn release:{prepare,perform}

The additional step in the current design is that you then need to go
to all the plugins using the library, update their dependency, and
release them too. If we switched the library to a plugin, it would
suffice to just release it—anyone accepting that update would get the
new behavior for all the feature plugins, since these would no longer
be physically bundling the library.

[Tony Noble]

On Thu, Jul 11, 2019 at 3:17 PM Jesse Glick <jgl...@cloudbees.com> wrote:

Completely routine; you just declare a Maven dependency and you are
done. Certainly less exotic and trouble-prone than the current design.

https://jenkins.io/doc/developer/plugin-development/dependencies-and-class-loading/

Thanks.  That gives me somethign to get stuck in to. 

The release process for the library is identical to that for a plugin:

mvn release:{prepare,perform}

Apologies - I meant the process of being added as a maintainer :0)  Thankfully the day job means I'm pretty comfortable with maven releases.

The additional step in the current design is that you then need to go
to all the plugins using the library, update their dependency, and
release them too. If we switched the library to a plugin, it would
suffice to just release it—anyone accepting that update would get the
new behavior for all the feature plugins, since these would no longer
be physically bundling the library.

True, but then if I read that correctly, any breaking change of the xtrigger plugin would require all dependant plugins to be updated and a co-ordinated release organised, rather than the current system where the dependent plugins simply avoid bumping the version of xtigger until they're ready?  The issue I see there is that (from what I can see) all the dependent plugins, or at least a lot of them, were maintained by Gregory and are now effectively unmaintained...

Admittedly, that's a problem to deal with as and when we get to the migration and I realise that the answer will probably be "don't make any breaking changes" :0)

Tony

[Jesse Glick]

On Thu, Jul 11, 2019 at 10:27 AM Tony Noble <tony....@gmail.com> wrote:
> any breaking change of the xtrigger plugin would require all dependant plugins to be updated and a co-ordinated release organised

Yes…so do not make breaking changes.

> The issue I see there is that (from what I can see) all the dependent plugins, or at least a lot of them, were maintained by Gregory and are now effectively unmaintained

I would advise anyone taking over as owner of part of this to ask to
be made owner of all of them. (Does not mean other interested parties
cannot contribute or even be primarily responsible for substantive
changes—just means that you have permissions to make changes to the
whole set of things when you need to.)

[Tony Noble]

Pull request submitted for release permissions: https://github.com/jenkins-infra/repository-permissions-updater/pull/1216

Could I also be give access to the github repo for xtrigger-lib, please?  

Repo: https://github.com/jenkinsci/xtrigger-lib

GitHub id: TonyNoble

Jenkins id: stealthdj

I'll look at what other plugins depend on xtrigger and submit a separate request for those.  Judging by the issues I've discovered with this update and previous conversations, I'm guessing that envinject may well also need to be included.

Thanks,

Tony

--
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/CANfRfr1N9RfJVZt%3Dtf%2BZtgA%3DHcL%2BdcFjjWxFrJjuVoxESqny%2Bg%40mail.gmail.com.

[Tony Noble]

@jglick , @oleg-nenashev

Using xtrigger-plugin as a guide, I'd suggest that the following should be grouped together as previously owned by Gregory.  As such, please could I be added as maintainer on github to:

• FSTrigger Plugin - https://github.com/jenkinsci/fstrigger-plugin
• URLTrigger Plugin - https://github.com/jenkinsci/urltrigger-plugin (not required, I'm already maintainer)
• IvyTrigger Plugin - https://github.com/jenkinsci/ivytrigger-plugin
• ScriptTrigger Plugin - https://github.com/jenkinsci/scripttrigger-plugin (This looks like something full of security holes and possibly in need of deprecation)
• BuildResultTrigger Plugin (a.k.a JobTrigger) - https://github.com/jenkinsci/buildresult-trigger-plugin
• XTrigger-Lib - https://github.com/jenkinsci/xtrigger-lib
• EnvInject-Lib - https://github.com/jenkinsci/envinject-lib
• XTrigger-Plugin - https://github.com/jenkinsci/xtrigger-plugin

I note that EnvInject has since been converted to a plugin - should I include this, or are you happy with the current setup for it?

Another point to note - given that the goal for xtrigger-lib is to convert to a plugin, the natural name for it would be xtrigger-plugin.  But that's obviously taken as noted above - rather than go off on the wrong track, would 'xtrigger-base-plugin' seem reasonable?

Thanks,

Tony

(GitHub id: TonyNoble , Jenkins id: StealthDJ)

[Daniel Beck]

> On 20. Jul 2019, at 14:52, Tony Noble <tony....@gmail.com> wrote:
>
> Another point to note - given that the goal for xtrigger-lib is to convert to a plugin, the natural name for it would be xtrigger-plugin. But that's obviously taken as noted above - rather than go off on the wrong track, would 'xtrigger-base-plugin' seem reasonable?
>

It's customary to name it whatever-api in Jenkins. envinject-lib is provided by the plugin 'envinject-api', there's branch-api and scm-api, etc.

[Oleg Nenashev]

My plan was to keep EnvInject Lib as a temporary lib until all plugins and "libs" switch to EnvInject API. Then I would have moved the code and removed the library repository. It was at the time of a Pipeline compatibility effort 4 years ago. But we have not been able to rework all Geegory's plugins at that time, switched to other tasks.

If you rework XTrigger Lib to a plugin, please use EnvInject API Plugin as a dependency.

BR, Oleg

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/Ue9hmTRhqS4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CFD98BB8-4683-4BB7-8101-D6FAEE28B4EC%40beckweb.net.

[Tony Noble]

Okay, so modifications:

- No need to add me as maintainer for envinject-lib

- XTrigger-lib plugin replacement will be named XTrigger-api-plugin

On that basis, if someone could add me as maintainer for the rest, it'd be much appreciated.

Tony

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/CAPfivLCe-d47xKn9wmOhen02%2BT0fxqXDF%3DQirp2MJqCSdPiCmQ%40mail.gmail.com.

[Oleg Nenashev]

Hi Tony,

I have granted you write access and made you a default assignee in the components.

If you decide  to become a maintainer of the EnvInject stuff, I will be happy to grant your permissions as well.

Some notes:

• To release the components, you will need to create a pull request to https://github.com/jenkins-infra/repository-permissions-updater
• ColMelvin has contributed a lot of patches which have not been released yet. IIRC I reviewed them 1 year ago, but nobody took ownership at that point. Some area for collaboration there, maybe
• For plugin you plan to maintain in longer term, it might make sense to use Release Drafter for changelogs (docs)

Best regards,

Oleg

On Saturday, July 20, 2019 at 9:30:49 PM UTC+2, Tony Noble wrote:

Okay, so modifications:

- No need to add me as maintainer for envinject-lib

- XTrigger-lib plugin replacement will be named XTrigger-api-plugin

On that basis, if someone could add me as maintainer for the rest, it'd be much appreciated.

Tony

On Sat, Jul 20, 2019 at 7:15 PM Oleg Nenashev <o.v.n...@gmail.com> wrote:

My plan was to keep EnvInject Lib as a temporary lib until all plugins and "libs" switch to EnvInject API. Then I would have moved the code and removed the library repository. It was at the time of a Pipeline compatibility effort 4 years ago. But we have not been able to rework all Geegory's plugins at that time, switched to other tasks.

If you rework XTrigger Lib to a plugin, please use EnvInject API Plugin as a dependency.

BR, Oleg

On Sat, Jul 20, 2019, 19:54 Daniel Beck <m...@beckweb.net> wrote:

> On 20. Jul 2019, at 14:52, Tony Noble <tony...@gmail.com> wrote:
>
> Another point to note - given that the goal for xtrigger-lib is to convert to a plugin, the natural name for it would be xtrigger-plugin.  But that's obviously taken as noted above - rather than go off on the wrong track, would 'xtrigger-base-plugin' seem reasonable?
>

It's customary to name it whatever-api in Jenkins. envinject-lib is provided by the plugin 'envinject-api', there's branch-api and scm-api, etc.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/Ue9hmTRhqS4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CFD98BB8-4683-4BB7-8101-D6FAEE28B4EC%40beckweb.net.

--
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 jenkin...@googlegroups.com.

[Tony Noble]

Thanks Oleg,

Pull request created: https://github.com/jenkins-infra/repository-permissions-updater/pull/1233

Tony

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/6ea8aa69-4713-43af-ae1f-181dc37e9000%40googlegroups.com.

[Tony Noble]

Pull request looks to have been approved, but not applied - can anyone assist?

Cheers,

Tony

[Oleg Nenashev]

done. Was waiting for more confirmations, but it got stalled

To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9HA8ETqBpxbRODcsgZAEEkDPGQ8FRxe8d2hb3EHTNzGOQ%40mail.gmail.com.

[Tony Noble]

Late follow-up, apologies.

Now I have time to look at outstanding PRs / Jira tickets, I still don't appear to have owner access to the following git repos:

• 
  
• ScriptTrigger Plugin - https://github.com/jenkinsci/scripttrigger-plugin
  

• BuildResultTrigger Plugin (a.k.a JobTrigger) - https://github.com/jenkinsci/buildresult-trigger-plugin

All other access appears to be sorted, however.

Can someone assist?

Tony

• 
  

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBO%2By9BZ6pov64EAC%2BShoU46kTY_7Y1z%3DJ4Jn2T%2Bcq0vQ%40mail.gmail.com.

[Ullrich Hafner]

I added you as committer to the repositories.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9E1caBcv9pQePQQ-eo1nJ6R_a-LSCyBGcN28N2iYVpXZw%40mail.gmail.com.

[Tony Noble]

Brilliant, thanks :0)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0DF8F1F7-B99F-4CDD-918E-22E36B8011EF%40gmail.com.

[Tony Noble]

Dredging up an old conversation - apologies

I've had chance to do some work on xtrigger-lib and convert to a plugin, removing its dependency on envinject-lib in the process.  I have a project xtrigger-api-plugin ready to go, so really just a query as to what the next step is - do I need to create my own repo which is then forked / moved into jenkinsci org, or is it possible to just create an empty repo and make me maintainer / owner?

I assume artifact upload permissions will also need to be sorted, but from memory that requires the github repo to exist first?

Cheers,

Tony

[Oleg Nenashev]

Hi Tony,

Thanks a lot for working on it! In this case I would be happy to just create a repo for you. Before we do so, what do you think about just renaming https://github.com/jenkinsci/xtrigger-lib ? It might be a more convenient approach if you keep the most of the codebase and do not need the old library implementation anymore.

Best regards,

Oleg

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9H-bqrGOVN_4XWEZS6hfwBQJA5yEBq6QHsrE2LCeNUQhg%40mail.gmail.com.

[Tony Noble]

Hi Oleg,

I'm keeping as much of the codebase as possible and the revision history, though obviously the structure has changed somewhat.  Happy to rename the existing repo and run a maintenance branch for xtrigger-lib, as long as that can be done without breaking any existing linkages and the artifact permissions system can cope with two different things pointing to the same repo?

Tony

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAJGAqpxeO_VX0oysy%2BV91ojBJK36QybROUXb00e%2Ba0dQ%40mail.gmail.com.

[Oleg Nenashev]

There should be no infra issues with renaming, so it is totally your choice based on your preference

FTR I created a separate repo for EnvInject API plugin when working on pluginizing EnvInject Lib. I did that because I wanted to retain binary/XStream compatibility, but did not want to bring the legacy AbstractProject only API into the new plugin. Not sure it is a case for you Toby, but for me it caused big overhead due to the need to maintain a chain of dependent components.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9FuaXSHMZdGok82PpD4%3DP3HM5UW3uGFs_Veg%3D9x%2BS6bbA%40mail.gmail.com.

[Tony Noble]

I looked at what you'd done with EnvInject when working on XTrigger and did wonder what the reasons for your approach were - and did spot the caveats.

My intention is to draw a line in the sand for XTrigger and all components that use it - the lib setup will be kept on a branch for security fixes only, the same will apply for dependent trigger plugins.  Development from here onwards will depend on the current LTS (2.277, I think?) as a minimum and any future releases of urltrigger, fstrigger etc will be in turn dependent on that.

I didn't plan to have the new repo require the old one, merely to leave the old one mothballed as a reference.  I suppose that suggests a rename is the best option - if you could sort that, it would be much appreciated.

Thanks,

Tony

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAU42ytKc-wktaM15YAxFxXJTOZxEVQ90nZ%2BJB7_wKNjg%40mail.gmail.com.

[Oleg Nenashev]

Actually, XTrigger lib was another reason as I remembered after looking at its code. XTrigger Lib depends on EnvInject Lib, and hence I would have been unable to just convert EnvInject Lib to API plugin without fixing the XTrigger Lib and its dependencies. Such an approach could have led to binary conflicts due to direct bundling of the EnvInject lib in all XTrigger-based plugin. Neither me nor my product manager were keen on expanding scope that much at that point.

FTR I renamed the XTrigger Lib repo to https://github.com/jenkinsci/xtrigger-api-plugin . 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9GuTM-hyEt0%3DO2gtyDsYf-VC8jhKP%2BTWyQf%2BrV%3DS%3DJocA%40mail.gmail.com.