wiki/src/blueprint/automated_builds_and_tests.mdwn

   1 [[!meta title="Automated builds and tests"]]
   2
   3 [[!toc levels=2]]
   4
   5 Rationale
   6 =========
   7
   8 An automated build and test environment would be pretty useful to
   9 ensure a few facts:
  10
  11 - new code does not break anything
  12 - new build tools (`live-build`) and included software
  13   (`live-config`, `live-boot`) don't break anything
  14 - updates pushed to the APT repositories we don't control (e.g. Debian's)
  15   don't break anything
  16 - the quality of our releases is good enough
  17 - power users get to test early images built from feature branches,
  18   or from `experimental`
  19 - we can ask bug reporters to test an image built from a bugfix
  20   branch, and see if it fixes their problem
  21
  22 What we have
  23 ============
  24
  25 * A Jenkins instance running on lizard, that builds a few branches
  26   whenever they are pushed. Results [are available
  27   publicly](http://nightly.tails.boum.org/).
  28 * A partially automated test suite:
  29   - [[documentation|contribute/release_process/test/automated_tests]]
  30   - [[setup|contribute/release_process/test/setup]]
  31   - [[usage|contribute/release_process/test]]
  32   - [[test cases|contribute/release_process/test]] that are not
  33     implemented yet.
  34
  35 Roadmap
  36 =======
  37
  38 0. Complete phase one (**build and publish ISOs automatically**):
  39    fix all child tickets of
  40    [[!tails_ticket 5324]].
  41 0. Run the test suite automatically on autobuilt ISOs:
  42    [[!tails_ticket 5288]]
  43 0. See other tickets in the *Continuous Integration* category,
  44    and organize the next steps.
  45
  46 What we need
  47 ============
  48
  49 Automated tests
  50 ---------------
  51
  52 Ideally, every automatically built ISO should be automatically tested,
  53 and the results displayed online.
  54
  55 Infrastructure
  56 --------------
  57
  58 Putting automatic builds and automatic tests on the same physical
  59 machine (while using
  60 virtualization to separate concerns) saves hosting and bandwidth costs:
  61 fresh images can be tested without being transferred.
  62
  63 In order to be able to build Tails in memory (which greatly speeds up builds)
  64 and to properly test HIGHMEM memory wipes, the test server should have at
  65 least 32 GB. Using KVM inside a KVM
  66 virtual machine is supported by the "nested KVM" feature.
  67 VirtualBox (Vagrant) in KVM is not supported as of March 2013.
  68
  69 We could set a threshold of tests that have to be successful before publishing
  70 one daily build image. This would prevent too-broken images to spread out and
  71 potentially harm users.
  72
  73 The setup of the automated build and test server should be done
  74 with public Puppet modules.
  75
  76 More specific pages
  77 ===================
  78
  79 [[!map pages="blueprint/automated_builds_and_tests/*"]]