I would be extremely wary of doing something like this considering that Jenkins stability is not stellar and bugs are aplenty. The codebase is fairly old and is littered with outdated code, failed refactorings etc. In the course of daily operation Jenkins is extremely susceptible to race conditions, potential memory leaks, and that is just core - without even running any plugins. Entrusting your company's critical infrastructure to it seems to me a bit dangerous.
Can we use Jenkins for that?
31–40 of 50 posts
Re: Can we use Jenkins for that?
#32The question appears to be "how can we abuse Jenkins today"? For small teams and orgs, Jenkins is fine, but scales horribly.
Totally agree. When you have critical systems driven from Jenkins jobs, and they're called all hours of the day, how do you manage to upgrade Jenkins without trashing all the running jobs? (A: pay CloudBees for the Multi-Master plugin).
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.
Re: Can we use Jenkins for that?
#33Eh, I'm sure there are many things Jenkins is OK at, but it's not that great of build server. 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 itsel…
Have to second all of this. There plugin ecosystem looks full but the vast majority of plugins are unsupported, qality varies enormously without any good way to judge it, and god help you if you want to mix and match plugins which weren't made to work together.
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.
Re: Can we use Jenkins for that?
#34Eh, I'm sure there are many things Jenkins is OK at, but it's not that great of build server. 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 itsel…
We were in the same boat as we moved towards a more Dockerized production environment on Kubernetes. There is a great Jenkins+Kubernetes whitepaper detailing how to string all of the various plugins together, check all of the right boxes, fill all of the right fields in. But it was apparent that the setup and maintenance costs were going to be higher than we wanted. And nobody outside of the engineering group would probably be able to figure out how to use the thing (we have a lot of other teams writing code that aren't "engineering" teams).
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...)
Re: Can we use Jenkins for that?
#35Eh, I'm sure there are many things Jenkins is OK at, but it's not that great of build server. 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 itsel…
I agree with all this. Unfortunately I haven't found anything less bad :(
In line with the other suggestions, there is also jenkins-autojobs [1] (disclaimer: I wrote it). It's a set of scripts that listen for changes in a git|hg|svn repository and create|update jobs from template jobs and the rules defined in a yaml config file [2].
[1] https://github.com/gvalkov/jenkins-autojobs [2] http://jenkins-autojobs.readthedocs.org/en/latest/examples.h...
Re: Can we use Jenkins for that?
#36Does anyone consider Jenkins as a replacement to CRON?
Yes, We do. We primarly use it as Job scheduling engine. I have multiple teams asking for data extracts, and I fashioned Jenkins to run extracts both adhoc as well as fixed schedule basis.
Re: Can we use Jenkins for that?
#37Earlier quoted context omitted.
I agree with all this. Unfortunately I haven't found anything less bad :(
In line with the other suggestions, there is also jenkins-autojobs [1] (disclaimer: I wrote it). It's a set of scripts that listen for changes in a git|hg|svn repository and create|update jobs from template jobs and the rules defined in a yaml config file [2]. [1] https://github.com/gvalkov/jenkins-autojobs [2] http://jenkins-autojobs.readthedocs.org/en/latest/examples.h...
We use this to generate builds from our (many, many) feature branches, its amazingly useful, bravo!
Re: Can we use Jenkins for that?
#38Re: Can we use Jenkins for that?
#39Eh, I'm sure there are many things Jenkins is OK at, but it's not that great of build server. 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 itsel…
> compared to the simplicity of modern tools like Travis (which uses YAML).
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.
Re: Can we use Jenkins for that?
#40Eh, I'm sure there are many things Jenkins is OK at, but it's not that great of build server. 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 itsel…
> compared to the simplicity of modern tools like Travis (which uses YAML). 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.
> Having just learned of Travis on this thread, I can't seem to find its source code.
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.