+1 to getting that out as fast as possible.., [image: ____________________________________________________________] Mads Nielsen Consultant [email protected] +45 50 98 18 09 <+45%2050%2098%2018%2009> Skype: inkspot Praqma www.praqma.com DK: CPH, Aarhus, Allerod NO: OSL SE: STHLM +45 36 PRAQMA <+4536772762>
<http://www.code-conf.com/day-of-docker-osl15/?src=mailbanner> On Wed, Nov 4, 2015 at 2:07 PM, Stephen Connolly < [email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMynrxEFSS_u8YLDmx0sx7duJ5JpbpS2m5QpY5Ts8uRh1A%40mail.gmail.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/CAFariutzC3bf%2BaWOHRW4d5JW5Xfpgw85EOYhyUmPazcTdELRBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
