The Multi-Configuration Project abstraction (IE build matrices) is clunky and the plugin ecosystem doesn't respect it well (eg. the Gerrit plugin is extremely popular but very brittle here). So you wind up with O(n) projects anyway and still needing to copy and paste configuration among them.
Also Jenkins configuration itself is pretty nuts - settings splattered all over the web UI, backed by XML - compared to the simplicity of modern tools like Travis (which uses YAML).
And Jenkins' UI I would definitely categorize as typically-poor open source UI, having evolved and grown more complex over many years with no strong guiding vision.
Right before I was about to give up, I found Drone: http://try.drone.io/ (GitHub: https://github.com/drone/drone)
With Drone, builds are done within Docker containers. Cool enough, nothing super special there. The real magic is that all of the plugins (http://addons.drone.io/) themselves are also ran in Docker containers. So we can write plugins in whatever language we want, they can be pinned to specific tags or auto-upgraded at build time.
That and the setup process was basically "run this Docker image, pass in some env vars". The UI, while still very basic is easy enough for our other teams to use, and the small but growing community is very receptive to feedback and pull requests.
Check it out if you aren't opposed to a Docker-heavy build system. If you are running a Kubernetes setup like us, here are some starter manifests for you (http://gc-taylor.com/blog/2015/10/27/example-drone-ci-kubern...)
[0] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
def project = 'quidryan/aws-sdk-test'
def branchApi = new URL("https://api.github.com/repos/${project}/branches")
def branches = new groovy.json.JsonSlurper().parse(branchApi.newReader())
branches.each {
def branchName = it.name
job {
name "${project}-${branchName}".replaceAll('/','-')
scm {
git("git://github.com/${project}.git", branchName)
}
steps {
maven("test -Dproject.name=${project}/${branchName}")
}
}
}
I think the new Jenkinsfile approach looks very promising: http://jenkins-ci.org/content/pipeline-code-multibranch-work...
Keeping your configs in YAML in source control is such a win. Not a fan of Jenkins, BTW.
[1] https://github.com/gvalkov/jenkins-autojobs [2] http://jenkins-autojobs.readthedocs.org/en/latest/examples.h...
The configuration is hostile to separation of concerns. The configuration of your remote build nodes goes in the same XML as the configuration that groups your jobs into "views" on the front end.
I could go on. I don't think I'd build anything complex with Jenkins again. Id prefer to build a job system from scratch, honestly.
the Gerrit plugin
There are projects out there with workflows where people submit to Github so the CI can run, then it gets pulled into Gerrit for code review on a website with no visibility into the result of that CI.
I'd love to move all code review to Gerrit but I'd need to see something disrupt this space first.
This start up seems like they are trying to sort of package and iterate on the value and power of Gerrit: https://www.gitcolony.com
https://github.com/google/git-appraise
Although it may well be a decent Gerrit alternative - it still talks about interfacing with Jenkins.
But is Travis really a tool or just a service?
Having just learned of Travis on this thread, I can't seem to find its source code.
Somebody else mentioned Drone (https://github.com/drone/drone ) which could be a proper Jenkins replacement.
https://github.com/travis-ci/travis-ci
I don't think there's a quick and easy way to set up your local version of Travis, but it does seem possible.
> But is Travis really a tool or just a service?
I would certainly argue it's more on the 'service' end of things. If I had to guess, most people who find hosting their code on Github acceptable (Travis only works with Github at the moment) also find using the Travis web service acceptable as well so there isn't a lot of incentive to use Travis as a locally installed tool rather than using their as-a-service offering.
I wouldn't use it for production-sensitive crons, but for administrative stuff, it works fine.
Reminds me of this post by Ted dzubia where he uses makefiles for data processing [1].
I like reading about novel uses of tools other than their original intent.
1- http://widgetsandshit.com/teddziuba/2011/02/stupid-unix-tric...
Jenkins is very powerful, but I would not trust it (or any of the myriad plugins we have installed) to not have security holes.
In particular I like the flexibility around snapshot versus artifact dependencies, the APIs are decent (and you can do a lot of troublingly clever things if you invoke the API from within a build), and the metarunner concept seems strictly more powerful than the Jenkins equivalents, albeit with a somewhat steeper learning curve.
Jenkins skimps on so many basic problems (cleaning workspaces for deleted jobs, resource requirements for jobs, API which can handle 10 requests a second, config store that doesn't require parsing hundreds of XML files on startup). Plus it has its own git implementation, which has unconfigurable checkout behavior (i.e. fetch all branches then checkout), which makes it a huge disk hog on busy repos.
The plugin system is half-baked: we have to check every new plugin (& version) on a test instance to verify that it doesn't interact horribly with any existing plugin.
When Jenkins triggers a downstream job & blocks on it before continuing, it logs the job it triggered, but not the build (until after the job completes). This makes watching a build in progress extremely tedious, and you have to hunt through the builds of the triggered job to find the relevant build. None of this is exposed directly by the API, your client has to derive it itself.
1) Simple UI (for simple usecases) 2) Easy setup on single node or multi-node scenarios 3)Automation capabilities
Unfortunately there are some gaps that make it just enough of a pain to really take up in a Production 24x7 env.
1) In a distributed setup, there are very minimal node management capabilities unless you manually integrate with say Zookeeper or something.
2) the plugins for backing up and restoring configurations are "lacking" to put it politely
3) Very hard to change the Master machine in a master slave set-up
4)etc etc
So while Jenkins is a like the Swiss army knife for CI be careful that you don't take it to a (multi-node production) Gunfight - to stretch the analogy.
I'm almost to the point of using it just to manage generic "do X sort of stuff" tasks across many nodes, but the jobs that rely on an external system to run parameterized builds, and then the job then stores the results into the external system.
So I prefer to have clear segregation. Jenkins as a build tool only. Rundeck for deployment. If I had a big need for scheduling, I'd want a dedicated system for doing that too.