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).
On Wednesday, November 4, 2015 at 12:54:36 AM UTC+3, 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] <javascript:>>: > >> 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] <javascript:>. >> 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/1d69182a-15cd-4756-9378-3348a1cfe277%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
