I didn't mention, you could use Ansible: - https://github.com/geerlingguy/ansible-role-jenkins
If you haven't worked with chef/puppet previously, you might find ansible quicker to learn. That's my POV. Cheers On Friday, 25 September 2015 14:04:12 UTC+2, Barry Laffoy wrote: > > Hi Victor > > Thanks for the response. > > I reckoned Chef or Puppet was the best bet, but I didn't want to prejudice > any answers. > > I'll check out the chef cookbooks you linked. I couldn't find much on the > web about provisioning Jenkins with Chef or Puppet, so I was wary about > going down one of those paths before I found out if other people had been > successful. > > Cheers > > On Friday, 25 September 2015 11:59:21 UTC+1, Victor Martinez wrote: >> >> Hi, >> >> You already spotted those configuration management tools, I've been >> using Puppet and Chef: >> >> - https://github.com/chef-cookbooks/jenkins >> - https://forge.puppetlabs.com/rtyler/jenkins >> >> I prefer Chef since you can configure your ssh slaves as part of the >> cookbook, when in puppet you only can configure swarm connections. >> >> As you can read in the README.md there are some examples of how to use >> plugins, versioning them and also add configuration files in case they are >> not part of the global config! >> >> If you want to go further, why don't you try docker? There is a >> plugin.txt file which might help you to install plugins, it's another >> paradigm actually, so you will need to rethink how to use it. >> >> - http://jenkins-ci.org/content/official-jenkins-lts-docker-image >> >> custom plugins, you could use >> https://wiki.jenkins-ci.org/display/JENKINS/UpdateSites+Manager+plugin >> in order to define your own Update Site, actually Jenkins provide another >> one called experimental. It might help you if you would like to archive >> those artifacts (hpi/jpi) in your internal artifact repo. >> >> I hope it helps >> >> Cheers >> >> On Friday, 25 September 2015 12:45:46 UTC+2, Barry Laffoy wrote: >>> >>> Hi >>> >>> Is there any way of managing the plugins installed in Jenkins other than >>> through the GUI interface? >>> >>> Ideally I would like to be able to define a list of plugins (names, >>> URLs, version numbers) in a text file, which would be read by Jenkins and >>> ensure that the correct plugins are installed (and warn/error of any >>> discrepancies or extraneous plugins). Ideally, something similar to a >>> `pom.xml`, or node's `package.json`, or python's `requirements.txt`. >>> >>> I'd be happy with such a tool if it were a standalone executable, or >>> another Jenkins plugin, or a feature of some Config Management tool (e.g. >>> Puppet, Chef, Ansible, Salt). >>> >>> I know that plugins can be installed by copying .hpi/.jpi files to >>> ~jenkins/plugins/. This works for backing up, mostly, but is far from >>> ideal. Problems I have with this: >>> >>> * plugin bloat: no record of when/why a plugin was installed or if it >>> should be removed; over time a large number of unused plugins acccumulate >>> * version drift: no record of when/why a plugin was updated, or why a >>> particular version was changed; in most cases you just use the most up to >>> date version from when you installed the plugin, and upgrading in the >>> future is difficult to track >>> * custom plugins: if I've recompiled a .hpi file for a fork of a plugin >>> I've made, it's tough to tell the difference between my version and the >>> version in the update-center >>> >>> I'm a big fan of infrastructure-as-code. Particularly, I like being able >>> to see a history of infrastructure changes in a source controlled >>> repository. Source control of Jenkins plugins would allow >>> >>> * informative commit messages >>> * code review for why plugins are being added >>> * easier rollbacks to previous good states when upgrading >>> >>> Being able to deploy a Jenkins master from configuration would provide a >>> bunch of other benefits: >>> >>> * easier to deploy new Jenkins masters (for testing, disaster recovery, >>> complex multi-master configurations) >>> * indicate the source of the plugin (i.e. the update-center, a github >>> repo, or an internal artifact manager) >>> * indicate the correct version to use >>> >>> Is there any existing tool or framework that would provide all of this? >>> Or will I have to roll my own? >>> >>> Thanks! >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" 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-users/a5a8d717-f728-4156-b0f2-4792dd5c7bd8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
