- Artifact, build artifact
- Artifact cache server
- Base system
- Base system image
- Build system
- Build system image
- Cache key
- Cache server
- Chunk, Chunk artifact
- Configuration extension
- Continuous integration and delivery
- Definition, definition file, morphology
- Deploy, deployment
- Deployment extension
- Development system
- Development system image
- Distributed build
- git cache server
- Local build
- Staging area
- stratum (strata)
- System, System image, System artifact
- System branch
- Write extension
Note: this document is work in progress, and is still subject to frequent change. If you are in any doubt over the meaning of a specific word or phrase, please ask in irc or on the mailing list.
The result of building something from source: a chunk, a stratum, or a system.
- For a chunk, the source is the upstream source code plus a (possibly autogenerated, ephemeral) definition, and the result of the build (the chunk artifact) is what gets installed onto the system the chunk is part of.
- For a stratum, the source is the definition, and the artifact is the list of chunk artifacts used for a build of a specific system.
- For a system, the source is the definition, and the artifact is the files that are included in the system, plus any changes done at system building time.
Each artifact has a unique identity derived from its source code, build instructions and build environment, so that it can be shared.
A machine which can serve artifacts from its cache directory which is
morph instances on different machines to share
artifacts, avoiding the need for everyone to build the same thing that someone
else has already built.
See the caching page for more information.
A minimal Baserock system containing the minimum necessary to have a runnable system. Base systems are defined in definitions beginning
A system image of a Baserock base system.
A Baserock system containing the tools typically needed to build
Baserock systems. Build systems are defined in definitions beginning
A system image of a Baserock build system.
A Linux filesystem, used by Baserock to provide the capability of versioning complete systems.
This cache key is used to identify things in the build artifact cache, and to determine whether an artifact needs to be rebuilt. The cache key is computed for a source in a given context, and all the separate build artifacts built from that source in that context share the same cache key.
See git cache server and artifact cache server.
A component in a system that corresponds to an upstream project (e.g. the
systemd), or a component developed for Baserock itself.
A deployment extension used to configure the system, e.g. by adding
configuration files or entries in configurations to the system's rootfs.
Implemented in a
.configure file in the
extensions/ directory in the
A software development process, where changes to projects are integrated into the mainline of development frequently, to reduce the difficulty of integrating changes later. Tools such as Jenkins have been invented to make this easier. (See also Mason.)
A data file used by the Baserock tools to specify how things are constructed or deployed:
- a chunk definition specifies how a chunk gets built;
- a stratum definition specifies what chunks to include in a stratum and where each chunk's source is stored;
- a system definition lists the strata included in a system;
- a cluster definition specifies how a group of systems is to be deployed together.
A Baserock system artifact that has been built needs to be deployed to a
real or virtual machine, or an OpenStack instance before it can be run. This is
done using the
morph deploy command. The deployment will configure the
system to suit the particular target, by setting up the bootloader and
hostname, configuring network access, filesystems, etc.
A program or script which is invoked by
morph deployduring the process of
deploying a Baserock system. There are two types:
- configuration extension;
- write extension.
A Baserock system containing the tools typically used for developing under
Baserock. Consists of a Build System with additional support for lanuguages
including Ruby and Node.js. Development systems are defined in definitions
A system image of a Baserock Development system.
A tool which allows some steps in building a system to be performed in parallel, and on machines other than the base or development system. (See also Local build and the distbuild guide).
A distributed revision control and source code management (SCM) program. Used to in Baserock to store and provide version control of all system components.
A server that allows querying of the git repositories without having to clone them. It is typically on the same machine as the Trove.
The git server used in a Trove. See the gitano homepage
Performing a build on the build system or the development system rather than using the Distributed build tool.
A tool which converts or mirrors upstream source code into git repositories on the Trove. A component of a Trove.
A continuous integration and delivery server which monitors git repositories for changes to any components of the system(s) being developed, builds all the necessary artifacts, and tests them using a battery of automated tests. There are public examples for the Baserock project at Mason x86_64 and Mason armv7lf
morph program is the workflow, build, branching, and deployment tool that
is used when developing with Baserock. The word 'morph' is also often used to
refer to a definition (or morphology ), which has the extension
A directory where intermediate build artifacts are stored and assembled temporarily while building, before they are deployed. The directory exists:
- in the development system for local builds;
- in build worker nodes for distributed builds.
(This entry should be improved sometime)
A group of chunks that together serve some unified purpose. For example, a
stratum might contain a set of chunks for running a mail server, or chunks
for all the version control systems we support in Trove. A special case is the
build-essential stratum, which is the set of chunks which are enough to
build all the rest of Baserock.
The plural form of stratum is strata. Blame the ancient Romans. One stratum, many strata.
Strata form "super-components", bigger building blocks which make it easy to build entire systems. If chunks are individual red bricks, strata are pre-fabricated concrete walls and floors.
Strata definitions are stored in the
strata directory of the
In Baserock, a system is a set of strata that work together for some purpose. A system is not ready to run on a device or virtulization host, it needs to be deployed to a machine (real or virtual) first.
Can be deployed and run as a Virtual Machine in a virtualization tool such as VirtualBox or KVM (see Quick Start).
A Git branch in definitions.git is effectively a branch of an entire system, rather than one component, as the definitions.git repo controls what components and what version of each component goes into a system.
Old versions of Morph treated branches of the definitions.git repo specially, and had its own set of commands for working with them. Since Baserock 15.25, you should use normal Git commands when working in definitions.git, just like other repos.
(This entry needs further work - Trebuchet does not exist as a standalone program, only the referenced commands).
A tool which provides a generic update mechanism for a Linux system. It delivers updates through a binary patch for the filesystem. This helps to optimise the network bandwidth requirements of doing an upgrade of a Baserock system. It is similar to rsync, when run in batch mode, but more efficient in our use cases. (It is also much less featureful than rsync.)
It provides the following commands (invoke them with the
--help option in your
development system to see what each one does):
tb-switch tb-update tbdiff-create tbdiff-deploy
Trebuchet is not used much, yet.
A server that provides git hosting, mirroring and conversion of upstream source code into git, build artifact storage, and other services that are useful to a team using Baserock to develop products.
Old versions of Morph (before the Baserock 15.25 release) had a concept of the "workspace", where all Git clones in use by Morph must be kept. Morph no longer requires or supports the concept of a 'workspace', any Git clone can be used.
A deployment extension used to perform the deployment e.g. by copying a VM
disk image somewhere and starting the VM.
Implemented in a
.write file in the
extensions/ directory in the
May also include a '.check' file which contains preparatory checks for the write