Creating a manifest¶
Manifest repositories are used to store repo tool 1 manifests. These manifests are used, in the repo tool, to fetch all the sources, tools and scripts needed to build a PELUX-based system.
The PELUX project contains a reference 2 for how a well-structured manifest repository should look like. When creating a new manifest repository, it is a good idea to duplicate the PELUX manifests, and see which parts can be kept in your own manifests.
It is not necessary to
git clone the PELUX manifests, since the git history
is likely not important for your project. Instead of
git clone:ing the
manifests, you may opt to simply copy them. To do this, browse to the PELUX
manifests GitHub page 2, and press the "Clone or download"
button, then press "Download ZIP".
In the examples below, it is assumed that the downloaded zip is named "pelux-manifests.zip".
Creating a git repo for a PELUX-based manifest¶
repo tool assumes all manifests are stored in a git repo, to keep track
of changes, thus a new git repository must be created for the manifests.
$ mkdir my-manifests $ cd my-manifests $ git init $ unzip <path-to-zip>/pelux-manifests.zip
Do not stage and commit the newly unpacked files just yet. Some tweaks must be done to the files before they can be re-used by your project.
Tweaking the manifest files¶
Below follows general recommendations for modifications of common files.
ci-scriptsdirectory can likely be kept as-is, if these scripts seem useful for your project
docdirectory should contain extra documentation for the repository, if applicable
The vagrant-cookbook directory should contain a
git submodulepointing to
firstname.lastname@example.org:Pelagicore/vagrant-cookbook.git, or a different repository containing vagrant scripts. This submodule is used by the
Vagrantfile, and is only needed if Vagrant 3 is used for the project.
CONTRIBUTING, LICENSE, and README should be updated according to the
pelux-manifestslicense and your project guidelines
Dockerfilecan likely be left as-is, and can be customized according to your project needs for Docker builds
Directory names must be updated (for example, the
TEMPLATECONFvariable must be set to match your layer structure)
Image names must be updated to reflect your own image names (
In general, this file can be customized to suit your project's CI needs
Vagrantfileshould be usable as-is, but can be modified to accommodate your project's CI and virtualized build needs
pelux.xmlis the actual manifest file. The manifest file has to be modified to indicate the correct repositories. It is possible to structure manifest files in a hierarchical fashion, such that a common base manifest and (possibly several) specialized manifests, for example per architecture, or for qt inclusion. In PELUX, we're only using one manifest since this is easier. The only downside is that we may download some layers that we're not using later.