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¶
The 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.
The
ci-scriptsdirectory can likely be kept as-is, if these scripts seem useful for your projectThe
docdirectory should contain extra documentation for the repository, if applicableThe vagrant-cookbook directory should contain a
git submodulepointing togit@github.com:Pelagicore/vagrant-cookbook.git, or a different repository containing vagrant scripts. This submodule is used by theVagrantfile, 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 guidelinesThe
Dockerfilecan likely be left as-is, and can be customized according to your project needs for Docker buildsThe
Jenkinsfilesets up a Jenkins 4 pipeline 5 for Continuous Integration (CI) builds of your manifest. This file must be modified to accommodate your project. In particular: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 (
core-image-peluxmay becomecore-image-yourproject)In general, this file can be customized to suit your project's CI needs
The
Vagrantfileshould be usable as-is, but can be modified to accommodate your project's CI and virtualized build needsThe
xmlfilepelux.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.