Home

Clear Linux* Distro Factory

The clr-distro-factory project provides a Build Workflow implementation. The Build Workflow is the last phase in architecting the life-cycle of a Clear Linux* OS derivative.

The Build Workflow is intended to be driven by any CI/CD solution, Jenkins or otherwise. We prefer to keep reliance on Jenkins at minimum. Alternatively, you can even run it manually from a bash terminal.

Prerequisite

Architect the life-cycle of a Clear Linux* OS derivative

Code Organization

The code is organized as the following:

1. Root folder contains code that is used across pipelines
2. Each folder represents one pipeline
3. Each script within the folder is either a stage or step of that pipeline
4. Each folder contains a pipeline file that describes the sequence on which the stages and steps needs to be executed

The code style can be found on Shell-Code-Style-and-Considerations and code quality is also enforced by shellcheck (via make check).

Deployment of the 'Distro Release Workflow'

One of the goals of clr-distro-factory is to provide a uniform way to execute the Release Workflow that can be shared among multiple instances, therefore there is the need to split process ('How') from the data ('What'). So the first act of each pipeline on clr-distro-factory (the 'How') is to fetch what it is called a clr-distro-factory-config repository (the 'What'). The clr-distro-factory-config is a git repository that contains all the data needed by the workflow to run and is unique to each downstream instance. It contains information like the downstream name, infrastructure host names, where to find bundles definitions etc. The clr-distro-factory-config needs to be based on this template. Every time clr-distro-factory is released, a matching release is also made at clr-distro-factory-config, so users know what data is needed in order to run a given release of clr-distro-factory.

The canonical way to use clr-distro-factory is to create a Jenkins Pipeline job for each Pipeline listed below. For the pipeline configuration, set Pipeline script from SCM -> Git, point to clr-distro-factory repository and pick one release as 'Branch to build' (i.e. refs/tags/clr-distro-factory-<version>). For the Script path, set the path to the appropriate pipeline file.

For specific settings of each Pipeline, refer to their specific documentation.

The Pipelines

• Build Pipeline
• Watcher Pipeline
• Koji Pipeline

Customized Pipelines

When it comes to 'DevOps' there is no "one size fits all." QA is usually the main example of this. Teams usually implement QA in different ways with different tools (that is why there is no QA stage enforced on this repository). That was one of the main drivers to keep each stage the most isolated as possible from others, allowing for the most reuse of the common parts of this project on deployments that deals with different requirements.

It should be easy to keep track of improvements on clr-distro-factory while adding custom steps and stages to its pipelines. To do so, the only thing that is required is for one to use a fork clr-distro-factory instead of the main repository, adding changes on top of a given release and rebasing it after each release.