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
On 4 November 2015 at 08:07, <[email protected]> wrote:
> 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
> <https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Hook+Script>, they
> might come in handy.
>
> Cheers,
> Thierry
>
> On Tuesday, November 3, 2015 at 10:54:36 PM UTC+1, Baptiste Mathus wrote:
>>
>> 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
>>
>> 2015-11-03 15:54 GMT+01:00 <[email protected]>:
>>
>>> 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
>>> <http://jenkinsci.github.io/maven-hpi-plugin/run-mojo.html>, 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
>>> <http://jenkinsci.github.io/maven-hpi-plugin/custom-war-mojo.html> 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
>>>
>>> --
>>> 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 [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/1b110392-4660-4cc9-a443-ceb9728454c8%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1b110392-4660-4cc9-a443-ceb9728454c8%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Baptiste <Batmat> MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor !
>>
> --
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/0abf33fa-73eb-4b03-953b-f2ce93eefdce%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/0abf33fa-73eb-4b03-953b-f2ce93eefdce%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMynrxEFSS_u8YLDmx0sx7duJ5JpbpS2m5QpY5Ts8uRh1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
