- Jenkins Best Practices
- the jenkins and jenkins-slave JuJu charms may be good sources of inspiration for deployment
- !cpan Net-Jenkins
- Job builder provides one-way (Git to Jenkins) jobs synchronization; it's in Debian sid.
- jenkins.debian.net uses the SCM Sync plugin, that apparently handles committing to the VCS on configuration changes done in the web interface, and maybe more.
- jenkins-yaml might make it easy to generate a large number of similar Jenkins jobs, e.g. one per branch
- jenkins_jobs puppet module
Visible read-only on the web
We'd like our Jenkins instance to be visible read-only on the web. We'd rather not rely on Jenkins authentication / authorization to enforce this read-only policy. We'd rather see the frontend reverse proxy take care of this.
method should return the list of URL prefixes that we want to allow.
And we could forbid anything else.
- IRC plugin, but I'm told that the jenkins email notifications are way nicer than what this plugin can do, so see a better way to do it
- !cpan Jenkins-NotificationListenerNotification plugin.
Notifying different people depending on what triggered the build
At least the obvious candidate (Email-ext plugin) doesn't seem able to email different recipients depending on what triggered the build out-of-the-box. But apparently, one can set up two 'Script - After Build' email triggers in the Email-ext configuration: one emails the culprit, the other emails the RM. And then, they do something or not depending on a variable we set during the build, based on what triggered the build. Likely the cleaner and simpler solution.
Otherwise, we could have Jenkins email some pipe script that will forward to the right person depending on 1. whether it's a base branch; and 2. whether the build was triggered by a push or by something else. This should work if we can get the email notification to pass the needed info in it. E.g. the full console output currently has "Started by timer" or "Started by an SCM change", but this is not part of the email notification. Could work, but a bit hackish and all kinds of things can go wrong.
Also, I've seen lots of people documenting crazy similar things with some of these plugins: "Run Condition", "Conditional BuildStep", "Flexible Publish" and "Any Build step". But then it gets too complicated for me to dive into it right now.
How others use Jenkins
- setup documentation
- Tor's jobs
- Ubuntu QA Jenkins instance
- grml's Michael Prokop talks about autotesting in KVM during his talk at DebConf 10; they use Jenkins:
- jenkinstool has the tools Lars Wirzenius uses to manage his CI (Python projects test suite, Debian packages, importing into reprepro, VM setup of all needed stuff); the whole thing is very ad-hoc but many bits could be used as inspiration sources.