path: root/wiki/src/blueprint/automated_builds_and_tests/resources.mdwn
diff options
authoranonym <>2015-10-21 18:43:37 +0200
committeranonym <>2015-10-21 18:43:37 +0200
commit5d1603131c8f779feecddc30ec7a26fd50caecb2 (patch)
treeba4d289bef3c998d0a7584220ebb80453483bd01 /wiki/src/blueprint/automated_builds_and_tests/resources.mdwn
parentb25d21c50db43ac0e4a5179a010af5834227b548 (diff)
parent4c64182b0bc75f876d83036a6d60731731f90bcd (diff)
Merge branch 'devel' into test/10378-fix-tails-shipped-openpgp-keys-test-is-fragiletest/10378-fix-tails-shipped-openpgp-keys-test-is-fragile
Diffstat (limited to 'wiki/src/blueprint/automated_builds_and_tests/resources.mdwn')
1 files changed, 140 insertions, 0 deletions
diff --git a/wiki/src/blueprint/automated_builds_and_tests/resources.mdwn b/wiki/src/blueprint/automated_builds_and_tests/resources.mdwn
new file mode 100644
index 0000000..0368eb6
--- /dev/null
+++ b/wiki/src/blueprint/automated_builds_and_tests/resources.mdwn
@@ -0,0 +1,140 @@
+[[!meta title="Jenkins resources"]]
+[[!toc levels=2]]
+- [Jenkins Best
+ Practices](
+- [plugins](
+ * [Git plugin](
+ * [Copy Artifact
+ plugin](
+ can be used to run a test job against the result of a build job,
+ e.g. for Debian packages (think Lintian) or Tails ISO images; see
+ [grml's setup
+ documentation](
+ that uses it.
+- the [jenkins]( and
+ [jenkins-slave](
+ JuJu charms may be good sources of inspiration for deployment
+- [[!cpan Net-Jenkins]] (not in Debian) allows to interact with
+ a Jenkins server: create and start jobs, get information about
+ builds etc.
+Jobs management
+- [Job builder]( provides
+ one-way (Git to Jenkins) jobs synchronization; it's in Debian sid.
+ * [configuration documentation](
+ * Debian uses it in their ``: it runs `jenkins-jobs
+ update $config` after importing updated YAML job config files
+ from Git.
+ * Tor [use
+ it]( too.
+- 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](
+Web setup
+### 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.
+The [Reverse Proxy
+Jenkins plugin can be useful to display [an example
+of this method.
+### Miscellaneous
+- [sample nginx configuration](
+- [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-NotificationListener]] is a server that listens to
+ messages from Jenkins [Notification
+ 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](
+ * configuration: `git://`
+- [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:
+ * [Jenkins instance](
+ * [unittests](
+ * [debian-glue Jenkins plugin](
+ * [kantan]( simple test suite for
+ autotesting using Grml and KVM
+ * [Jenkins server setup documentation](
+- [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.
+Jenkins for Perl projects
+* [a collection of links](
+ on the Jenkins wiki
+* an overview of the available tools: [[!cpan Task::Jenkins]]
+* [a tutorial](
+* [another tutorial](
+* use [[!cpan TAP::Formatter::JUnit]] (in Wheezy) rather than the Jenkins TAP plugin
+* use `prove --timer` to know how long each test takes