Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B blueprints
  • Project information
    • Project information
    • Activity
    • Members
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
Collapse sidebar
  • tails
  • blueprints
  • Wiki
  • automated_builds_and_tests

automated_builds_and_tests · Changes

Page history
Rename blueprints: .mdwn → .md authored Jan 02, 2021 by intrigeri's avatar intrigeri
Rationale:

 - Right now:

   - These pages' Markdown will be rendered when browsing our
     repository in the GitLab web interface

   - The .md extension is more common nowadays: GitHub, GitLab, and various
     other major players have settled on it. Let's get used to it.

 - If we decide to migrate our blueprints to GitLab (#18079),
   this will be a necessary first step.
Show whitespace changes
Inline Side-by-side
automated_builds_and_tests.md 0 → 100644
View page @ 7db7c482
[[!tag archived]]
[[!meta title="Automated builds and tests"]]
[[!toc levels=2]]
Rationale
=========
An automated build and test environment would be pretty useful to
ensure a few facts:
- new code does not break anything
- new build tools (`live-build`) and included software
(`live-config`, `live-boot`) don't break anything
- updates pushed to the APT repositories we don't control (e.g. Debian's)
don't break anything
- the quality of our releases is good enough
- power users get to test early images built from feature branches,
or from `experimental`
- we can ask bug reporters to test an image built from a bugfix
branch, and see if it fixes their problem
What we have
============
* A Jenkins instance running on lizard, that builds a few branches
whenever they are pushed. Results [are available
publicly](http://nightly.tails.boum.org/).
* A partially automated test suite:
- [[documentation|contribute/release_process/test/automated_tests]]
- [[setup|contribute/release_process/test/setup]]
- [[usage|contribute/release_process/test]]
- [[test cases|contribute/release_process/test]] that are not
implemented yet.
Roadmap
=======
0. Complete phase one (**build and publish ISOs automatically**):
fix all child tickets of
[[!tails_ticket 5324]].
0. Run the test suite automatically on autobuilt ISOs:
[[!tails_ticket 5288]]
0. See other tickets in the *Continuous Integration* category,
and organize the next steps.
What we need
============
Automated tests
---------------
Ideally, every automatically built ISO should be automatically tested,
and the results displayed online.
Infrastructure
--------------
Putting automatic builds and automatic tests on the same physical
machine (while using
virtualization to separate concerns) saves hosting and bandwidth costs:
fresh images can be tested without being transferred.
In order to be able to build Tails in memory (which greatly speeds up builds)
and to properly test HIGHMEM memory wipes, the test server should have at
least 32 GB. Using KVM inside a KVM
virtual machine is supported by the "nested KVM" feature.
VirtualBox (Vagrant) in KVM is not supported as of March 2013.
We could set a threshold of tests that have to be successful before publishing
one daily build image. This would prevent too-broken images to spread out and
potentially harm users.
The setup of the automated build and test server should be done
with public Puppet modules.
More specific pages
===================
[[!map pages="blueprint/automated_builds_and_tests/*"]]
Clone repository
  • ARM_platforms
  • ARM_platforms
    • Acer_Chromebook_R_13_CB5 312T
  • Add_Gnome_PPP_for_Dial Up_Users
  • CI_usability
  • Debian_Stretch
  • Debian_testing
  • Endless_upgrades
  • Faster_builds
  • GNOME_bugs_that_affect_Tails
  • GNotification
  • GitLab
  • Git_sub repositories
  • HTTP_mirror_pool
  • HTTP_mirror_pool
    • archive
  • HackFest_2014_Paris
View All Pages