Questions on hpi:custom-war and preconfigured Jenkins instances

[t...@praqma.net]

Hey everyone,

I'm currently working on a little project to facilitate some upcoming design meetings.
The idea is pretty straight-forward: Given a SHA-1, spin up an instance of Jenkins running that version of your plugin (preferably with some preconfigured jobs).
The point is to allow you to easily play with different versions of your plugin, maybe even hack something on the spot and take it for a spin.
(Just doing a local hpi:run wouldn't really cut it as I'd like to have multiple people playing on the same Jenkins instance at the same time.)
I've bumped into some issues while implementing this and I'm hoping to get some answers/feedback/ideas here.

After some brainstorming we figured we could supply Docker images with either the plugin hpi and do an hpi:run, or a jenkins.war with the plugin and all necessary dependencies pre-installed and run that.
We settled for the latter and turned to hpi:custom-war to supply us with the war file.
Everything seemed to work like a charm, until we realized the war file created by hpi:custom-war only contains the dependencies and not the actual plugin itself.
I was wondering what the point of custom-war is when it doesn't include the plugin itself? (Not complaining, just wondering.)

Anyway, I worked around that by adding the plugin's hpi to the war's WEB-INF/plugins afterward, which works just fine.
I'm not too unhappy with the current approach, but I'm wondering if there's a better way of preparing such a preconfigured war

Next up is figuring out how to get some preconfigured jobs into my new Jenkins instances.
The place-holder plan is to supply people with some Job DSL they need to run whenever they spin up a new Jenkins, but that's sub-optimal at best.
I haven't looked into this in detail yet. Suggestions are welcome.

TL;DR
I'm looking for a nice way to create a Jenkins.war with my plugin pre-installed.
I've hacked something together but I'm wondering if there's a better way to do it.

Kind regards,
Thierry

[Baptiste Mathus]

Funnily, I've been thinking about something along this this morning. Working on a bug on the chucknorris-plugin that would happen only on some Jenkins version, I thought about creating a special dev docker image that you would run with something like:

$ cd myplugin

$ docker run -e VERSIONS=1.450,1.609.1,1.625 -p 8080-8082:8080-8082 -v $PWD:/theplugin:ro jenkins/plugin-tester

And then (for people not using Docker), you would have three Jenkins versions with your plugin running: 1.450 on port 8080, 1.609.1 on 8081 and 1.625.1 on 8082.

Seems like it should be not too difficult to do. In the Docker command, we would copy the plugin source on N places and launch hpi:run in each locations from inside the container, remapping ports.

What do you think?

-- Baptiste

--
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/1b110392-4660-4cc9-a443-ceb9728454c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Kanstantsin Shautsou]

I can suggest compare with maven tooling.

Also this wouldn't work with backward incompatible changes like Master-Slave callables. So you may require special branch in github for fixed sources.

Seems your example would work only on linux machine. ATH has some spaghetti abstractions for representing Machine and remote Jenkins instance, but they doesn't support rule executions on remote instance (something that i started implementing few threads ago). 

[t...@praqma.net]

Thinking about it, taking the hpi:run path instead of the 'supply the whole .war' will probably be less trouble in the end.
I really like the idea of running different versions of Jenkins, too. It could make the project useful beyond the upcoming design meetings.
As for automatically setting up some jobs on the new Jenkins instances, I've discovered the Jenkins hook scripts, they might come in handy.

Cheers,
Thierry

[Stephen Connolly]

So in cloudbees we use a different parent pom for our plugins:

...

  <properties>

    <jenkins.version>... base version goes here...</jenkins.version>

    ...

  </properties>

...

     <dependency>

        <groupId>org.jenkins-ci.main</groupId>

        <artifactId>jenkins-core</artifactId>

        <version>${jenkins.version}</version>

      </dependency>

      <dependency>

        <groupId>org.jenkins-ci.main</groupId>

        <artifactId>jenkins-war</artifactId>

        <version>${jenkins.version}</version>

        <type>war</type>

      </dependency>

      <dependency>

        <groupId>org.jenkins-ci.main</groupId>

        <artifactId>jenkins-test-harness</artifactId>

        <version>${jenkins.version}</version>

      </dependency>

...

This lets us do rather cool stuff like

$ mvn hpi:run -Djenkins.version=1.625.1

To fire up the plugin on a specific jenkins version.

It has long been on Jesse and My backlog to move the OSS plugin parent pom over to this model as it makes life much much easier... but alas time is always short for doing that set of changes

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0abf33fa-73eb-4b03-953b-f2ce93eefdce%40googlegroups.com.

[Mads Nielsen]

+1 to getting that out as fast as possible..,

Mads Nielsen
Consultant
m...@praqma.net
+45 50 98 18 09
Skype: inkspot

Praqma
www.praqma.com
DK: CPH, Aarhus, Allerod
NO: OSL
SE: STHLM
+45 36 PRAQMA

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