Re: Automated Jenkins Plugin/Dependency Management

On Saturday, October 15, 2016 at 2:55:43 PM UTC-4, Daniel Beck wrote: > > > > 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/plug

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 14.10.2016, at 22:

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 deps in build.gradle fi

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: 'latest

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 ca

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 bo

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 configure

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 id

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 a

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 serv

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 q

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 anyone has done something similar but I wa

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 related to Jenkins 1.x pl

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 the JSON -- which is the

Automated Jenkins Plugin/Dependency Management

Hey Jenkins-Users, I manage almost a dozen Jenkins servers and our team has been having some issues with plugin management: such as locking our new installations to known working versions of some troublesome Jenkins plugins. We use chef + Jenkins DSL to completely automate the initial installati