[JulianWasTaken]

I agree with all this. Unfortunately I haven't found anything less bad :(

[VoiceOfWisdom]

Jenkins + the Job DSL Plugin [0] has been amazing. We don't do any configuration in the web interface, instead everything lives in a groovy file on BitBucket. Every time we push a change Jenkins grabs it and auto runs the groovy file, regenerating all of our jobs. We have it set up so that a job is created for every branch in our repo, so much easier to work with. All a developer has to do to get his branch building is push it to the repo.

[0] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin

[vorg]

You only need recognition-memory to use Web and GUI interfaces, whereas you need recall-memory to use command line interfaces and scripts, which is far more difficult. That's why clicking in a Web GUI or graphical XML-generator replaced scripting. You need a lot of previous information in your memory for recall to write stuff like the following example taken from your linked page:

  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}")
        }
    }
  }

The vocabulary and grammar in that script is quite complicated and people would rather be presented with the options for clicking on a web page. But perhaps you're promoting a particular software product?

[dripton]

GUIs are more discoverable than command lines. Text files are easier to save in version control. So it's common to have a system where the GUI hooks new users, but they eventually have enough configuration in it that the GUI is no longer a reasonable way to control it all, and they need a way to extract the information in a reasonable format. Hence the reason several Jenkins plugins have evolved to do that.

[e28eta]

I also used JobDSL, and thought it worked pretty well. I don't think my teammates agreed, they seemed to just want to change things in the UI and this was just something getting in the way of their work. Some were willing to learn it, others weren't interested.

I think the new Jenkinsfile approach looks very promising: http://jenkins-ci.org/content/pipeline-code-multibranch-work...

[btd]

We do similar thing but with workflow plugins.

[avtar]

At work we use Jenkins Job Builder http://docs.openstack.org/infra/jenkins-job-builder/#content... to maintain jobs using JSON or YAML files. As a result we rarely have to deal with the Jenkins web UI and that's alright :)

[RickHull]

Jenkins Job Builder is, IME, the only way to keep complex Jenkins configs sane. Did you know that Jenkins is constantly rewriting its own XML config? We've had Jenkins itself corrupt its own config (with some combination of active plugins).

Keeping your configs in YAML in source control is such a win. Not a fan of Jenkins, BTW.

[slavik81]

Every time I install Jenkins, I install the thinBackup plugin. Losing your configuration is way too common, but it's easy to restore.

[gvalkov]

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...

[PebblesHD]

We use this to generate builds from our (many, many) feature branches, its amazingly useful, bravo!

[falsedan]

Using Job DSL + Jenkins Job Builder here, trying to move as much stuff off Jenkins as possible.