This is defunct, you may want to have a look at GnomeOS
1. What is it?
See also the live build server status page.
"gnome-continuous" (or just "Continuous" in a GNOME context) is a functional research project in high speed continuous delivery and testing for Linux kernel-based operating systems, designed from the ground up for GNOME. It is not an official project; rather, it is maintained on a volunteer, best-effort basis by some GNOME contributors.
The project was born to solve a seemingly simple problem:
The GNOME designers need to be able to try what they're designing, as it's being implemented.
To fulfill this, the gnome-continuous build system uses OpenEmbedded to build a base system, then has a custom build system on top which watches for commits to many git repositories (mainly GNOME, but including NetworkManager, systemd, X.org, polkit), builds them, integrates them into a complete filesystem tree that can be downloaded using the OSTree tool. But going beyond simply building, the system also automatically boots the build result in a virtual machine, then runs tests. What makes this system different from many previous GNOME build systems is:
- It is almost completely automated in a sustainable fashion; very few changes require human intervention
- It produces an actual downloadable result in the form of ready-to-run virtual machine images
- It is very, very fast. What other projects talk about doing "nightly", gnome-continuous does in minutes.
2. Who should use this?
- Machines. Seriously: the system is very much designed to meet the needs of automated testing.
- Human GNOME developers and testers who want to see GNOME as it is few minutes ago from git master
As for humans though: at the moment, there are no security updates. To be very clear: Due to lack of security updates, at present it would be at best irresponsible for this system to be used by anyone other than core GNOME developers and testers for the purposes of testing. While using the VM, human testers are advised to avoid browsing untrusted websites, and do not copy sensitive material such as SSH private keys into the VM.
3. An OSTree-native build system
Many GNU/Linux systems are either shipped as packages, or as inflexible images. The problem with packages are there are too many potential combinations to even consider testing. The problem with images is that one is locked into a totally inflexible system. OSTree allows a "medium" level of flexibility, where an OS builder can provide clients a choice of multiple (tens or hundreds) of pre-assembled filesystem trees.
Continuous is an OSTree-native build system, designed to take git repositories, build them, and ship them via OSTree at high speed.
It offers by default a choice of just two filesystem trees; there are "gnome-continuous/buildmaster/x86_64-runtime" and "gnome-continuous/buildmaster/x86_64-devel-debug".
At the moment, Continuous has no application mechanism; the trees are immutable. The "-runtime" tree comes with many applications, and "-devel-debug" comes with that plus developer-focused applications like Anjuta.
4. Non-goals
As mentioned above, Continuous is a research project; it is intended to be useful as well, but ultimately the goal is to improve the quality of GNOME, and the software it depends on such as NetworkManager and systemd. This small, well tested core can be reused and extended by larger software collections such as Debian and Red Hat Enterprise Linux.
In other words, it should be clear that the gnome-continuous system does not replace general-purpose GNU/Linux distributions, for a number of reasons. gnome-continuous is not even intended to be the build of GNOME inside GNOME; for example, jhbuild will remain actively maintained for developers to build subsets of GNOME such as GTK+ on top of existing distributions.
5. Primary focus
The focus of gnome-continuous is to promote and test the core GNOME technologies such as the GTK+ stack (with a special focus on glib), gnome-shell, the accessibility tools, and the core applications such as Epiphany.
At the moment, the system only targets virtualized environments. For more information, see this commit.
6. Media
LWN article: https://lwn.net/Articles/511877/
Colin's GUADEC 2012 presentation: http://people.gnome.org/~walters/guadec-2012-building-gnome/
Linux Plumbers 2012: http://people.gnome.org/~walters/Plumbers2012AtomicUpgrades/
7. The Code
8. Development
Gnome Continuous Mailing list: https://mail.gnome.org/archives/gnome-continuous-list/
OSTree Mailing list: https://mail.gnome.org/archives/ostree-list/
- IRC channel: #testable on irc.gnome.org
Issue tracker: https://gitlab.gnome.org/GNOME/gnome-continuous/issues/
Doing a local build (for developers): See Projects/GnomeContinuous/Building.
Main gnome.org continuous integration: http://build.gnome.org/#gnome-continuous
9. Installation
The build system continually produces qcow2 format disk images that are ready to boot in qemu. These images are produced after the "integrationtest" phase, which should ensure a basic level of quality.
You most likely want to download the -devel-debug image. The -runtime image doesn't have developer tools and debugging information.
Download it, then uncompress it using gunzip. Now, you should import it into a virtualization solution like libvirt.
9.0.1. Installation using virt-manager
- Create a new VM, click "Import existing disk"
- Choose OS type Linux, subtype anything modern (Fedora 19+)
- Double click on the VM - it may not boot
Go to View->Details, and change:
Disk -> Disk Bus to "virtio"
NIC -> Device model to "virtio"
Video -> VGA
9.0.2. Installation using gnome-boxes
GNOME Boxes from version 3.9.3 onwards has support for importing Continuous images.
- Select the image using 'Select a file' option in box creation wizard
Ordinarily this would be enough, but see https://bugzilla.gnome.org/show_bug.cgi?id=710706#c2 this bug for an additional step. (If the network connection is missing, change the NIC device model to "virtio" in virt-manager, as above. This should be fixed with libosinfo 0.2.8.)
9.0.3. Installation using other virtualization systems (VirtualBox, etc.)
The .qcow2 format is native to qemu, but it is possible to convert, if you have "qemu-img" on Linux available. At some point the build server may offer multiple types automatically (see bug 708836).
10. Becoming root (and upgrading)
The root user has no password by default. During the first boot, GNOME Initial Setup will create a user within the administration group, which will allow polkit to authorise you when needed.
Use pkexec to run a command as root.
To start a root shell, use:
$ pkexec bash
11. Upgrading
Run:
$ pkexec ostree admin upgrade
Then reboot. Note upgrades are fully atomic and do not disrupt the running system.
12. Downgrading
If the system does not boot after an upgrade, you can select the previous OSTree deployment from the boot loader.
If the system does not give you a usable session, you can log in as root in the console, and use:
# ostree admin undeploy 1
To undo the upgrade and revert back to the previous deployment.
13. Known Issues
Continuous aims to provide an experience that is as close to a real GNOME install as possible. However, there are some areas where things don't work as normal. See the list of known issues for more information.