Re: Automated Jenkins Plugin/Dependency Management

> On 15.10.2016, at 20:47, Daniel Beck wrote: > > As the update center JSON tells you, its groupId is not > org.jenkins-ci.plugins. > > https://repo.jenkins-ci.org/releases/com/sonyericsson/hudson/plugins/rebuild/rebuild/ Missed the newest response, sorry about that. > On

Re: Automated Jenkins Plugin/Dependency Management

> On 14.10.2016, at 22:03, Maciej Wiczynski wrote: > > I looked in https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/ and > don't see rebuild plugin listed. > I did find it in https://updates.jenkins-ci.org/current/update-center.json > but don't see how to set

Re: Automated Jenkins Plugin/Dependency Management

So.. figures once I posted I found a possible solution. If I set the group(via cookbook attribute) I get a build.gradle that seems to work, snippet of rebuild dependency: jenkinsPlugins([ group: 'com.sonyericsson.hudson.plugins.rebuild', name: 'rebuild', version:

Re: Automated Jenkins Plugin/Dependency Management

I found this thread via http://blog.thesparktree.com/post/149039600544/you-dont-know-jenkins-part-1. I'm new to gradle/jenkins and was trying to do something similar with my setup. I'm running into problem where some plugins are not found. I'm not sure how to find or specify where plugins

Re: Automated Jenkins Plugin/Dependency Management

My fault explaining that I know that I can extract it using the *jar* command, but I don't get the same "unzipped" output as running *java -jar jenkins.war*. It looks like this happens because of some magic in https://github.com/jenkinsci/extras-executable-war that handles the unpacking and

Re: Automated Jenkins Plugin/Dependency Management

Yep, the command is `jar xvf jenkins.war`, that will explode the war into the current directory. On Friday, August 26, 2016 at 12:27:00 PM UTC-7, Michael Kobit wrote: > > Is there a way to basically "unzip" the *jenkins.war* so that the > plugins, workflow-libs, and other parts can be

Re: Automated Jenkins Plugin/Dependency Management

Is there a way to basically "unzip" the *jenkins.war* so that the plugins, workflow-libs, and other parts can be configured before actually running the service? On Wednesday, August 17, 2016 at 9:36:08 AM UTC-5, Jason Kulatunga wrote: > > Hey, > Thanks for all the help guys. > I slept on this

Re: Automated Jenkins Plugin/Dependency Management

Hey, Thanks for all the help guys. I slept on this idea for a few days because, to be honest I really didn't want to write my own package manager and re-invent the wheel. I took a step back and looked

Re: Automated Jenkins Plugin/Dependency Management

We are looking at doing something similar (actually talking about this with colleagues today). The idea is to basically build an immutable Jenkins instance that can't be modified. Or at least severely limit any kinds of modifications to it so that we have an easily deployable "Jenkins as a

Re: Automated Jenkins Plugin/Dependency Management

Hey, Thanks for all the feedback :) @Daniel Beck: Yup, I'm familiar with the limitations of the https://updates.jenkins-ci.org/current/update-center.json file. Thats why I'm thinking of creating a plugin/dependency resolution system that will have to directly download the specific version of a

Re: Automated Jenkins Plugin/Dependency Management

IMO a Docker image with the right set of plugins you've tested, plus the security config you're talking about about forbidding any upgrade would seem a simpler way. And probably it would your life simpler if you somehow have to support all those different instances which can currently be actually

Re: Automated Jenkins Plugin/Dependency Management

Kind of off topic, but it would really be nice to be able to "pin" a plugin to a specific version that won't get upgraded. On Thu, Aug 11, 2016 at 11:08 AM Daniel Beck wrote: > > > On 11.08.2016, at 15:14, Jason Kulatunga wrote: > > > > I'm not sure if

Re: Automated Jenkins Plugin/Dependency Management

> On 11.08.2016, at 15:14, Jason Kulatunga wrote: > > I'm not sure if anyone has done something similar but I wanted to get some > feedback before I spent too much time investigating either idea. Note that pinning doesn't prevent a plugin from being upgraded -- it's

Re: Automated Jenkins Plugin/Dependency Management

> On 11.08.2016, at 15:14, Jason Kulatunga wrote: > > we've also verified that 'installNecessaryPlugins' does not actually respect > the version parameter. As the plugin update site metadata does not support arbitrary versions, it'll always install the one present in