Concepts and terminology

User

A person who connects to the redpesk Web UI, authenticated by SSO like openID Connect server or github account.

The user can have limited access to some functions in the web UI, depending on the initial configuration of the administrator.

Team

A list of users, which is always associated at least to one team owner or manager.

The owner can configure the access to some actions, and is able to invite other users to join in.

Role

There can be many roles which can limit the number of actions the user is able to access, such as developer, tester, or manager.

Developer

A user who has limited actions in the web UI, he can only build one or many applications and test them, but he wont be able to set the configuration of a project or an application, for example, if the configuration has been configured as mandatory by the manager.

In fact, the developer is in charge of the build, test, and deployment of the applications.

Manager

A user who is able to invite other users to his team. He has mostly the configuration of user’s roles in his team.

He has a slightly different view, compared to a developer, having access to different reporting tools, which help him have an oversight on the developer’s work (package building, testing and deployment)

Distribution

A set of software packaged, patched and tested which can be used to compose a bootable image usable as an operating system.

Example: redpesk LTS arz 1.0

Eventually, it can also be a constraint or condition the user can add to a project or an application, which will add the build configuration.

redpesk Distribution Variants

There are 2 variants for the main redpesk distribution: LTS and devel.

LTS version:
- full name: redpesk lts arz 1.0
- aligned on CentOS for Long Term Support, this is used for industrial and commercial needs
- short name: rparz (stand for arz 1.1), arz_0_2(stand for arz 1.0.2)
LTS update version:
- full name: redpesk lts arz 1.0-update
- updated version of redpesk lts arz 1.0 that provides latest changes (security or bug fixes) on top of arz 1.0
devel version:
- full name: redpesk devel arz
- aligned on CentOS Stream, this is used for the development. Geared towards development, this is used as the incubator for the next redpesk LTS release.
- short name: rpdarz

Architecture (CPU)

Represents the hardware design of the CPU. This design is controlled by its own set of instructions. There are several types of architecture: x86_64, arm64, etc.

In the case of redpesk, the user enables an architecture inside a project or an application.

The build has a host architecture and has one or many target architectures.

Project

A project is the container defining a larger task. It contains the resources needed to build one or more packages (applications).

The project needs a name.
It also needs a slug, to be identified in the web UI. This slug will become the ID of the project. The slug is a unique alias which will identify the project with other micro-services behind the web UI. Ex: my-unique-slug-123.

Inheritance

Inheritance allows one project to inherit the resources from another project or distribution.

In the redpesk CI, the user can choose one or more inheritances.

Application

A collection of files, folders, .spec files, etc; designed for the end user.

Like the project, the application needs a name as well. It also needs a slug, which will become the ID of the application.

To be able to fetch all the sources from the application, the user needs to choose a method to submit the source of an app, which is the URL. Ex: git@github.com:myFolder.

Application branches

The branch notion becomes useful when the package sources depend on a specific distribution defined in your project.

Each branch has its own spec file, sources, patches and it is possible to set different settings for each branch such as:

Source URL
Source revision
Specfile location
Application services
Emulated build

Each distribution set in the application is associated to one of the application branches, thus once a build is launched against a distribution, the associated branch is used, coming with its own package sources, version, release.

Spec file

The spec file describes how a package is built and it gives metadata and instructions needed.

Defines all the actions the RPMBuild command should take to build an application, as well as all the actions necessary for the rpm command to install and remove the application.

Each source RPM should have the necessary spec file for building a binary RPM.

Example: the hello-world package spec file would be named hello-world.spec

The syntax inside the spec defines how to build the package, version numbers, dependency information on other applications, etc.

Inside a spec file, there can be 5 main sections:

Metadata : Contains name, version, licence, text information about the package. Also defines which files to use, patch and build.
Preparation: Contains the snippet of shell commands to execute and prepare the sources before building. In general it consists of uncompressing and patching the source code files.
Build: Describes how the package has to be built
Install: Describes how to install the built application.
Files: File distribution among the package and subpackages of the spec file.

OPTIONAL: You can set other optional sections like:

Check: Holds the unit tests configuration and instructions

If you are having trouble modifying the spec file from your application, you can check this guide : RPM Packaging Guide

Build

A process where a group of tasks are executed to produce one or more results. In this case, the build step represents the cross-build of the application sources for the specified distributions and architectures.

image test

In the web UI, the build’s result can have different states.

States	Description
free	the build has not been assigned to a builder
closed	the build result is successful
failed	the build has failed
open	the build setup is in progress
canceled	the build has been stopped by the user
building	the build is in progress
complete	the build is over
deleted	the build has been deleted

Emulated build

The emulated build is an option that can be enabled when creating or updating an application. This option enables the emulation of the application’s build for the selected architectures, using binfmt-misc with qemu interpreter for the build.

The emulated build uses the kernel featured from binfmt in order to run qemu only for foreign architectures.

For example, if the user wants to build his application for an aarch64 target, but doesn’t want to cross build his application, that’s where the emulated build can be enabled. This will enable the builder to call qemu for foreign architecture program.

Log

The record of a processing step, which can be the result of a build, a source file scan, tests, a deployment, etc.

Logs can be useful to debug your build/test/deploy if it fails. Specially to know exactly what command or step is causing the failure.

Task

Intermediary internal step for a given process (build, deployment).

You can find mainly 5 types of tasks

Setup build environment (waitrepo) : initial step to setup/provision build infrastructure.
Packaging sources into SRPM package (buildSRPMFromSCM) : Build task of an RPM from a given application, which fetches the source from the URL (git) and creates the SRC.RPM
Building native application (buildArch) : Build task of an RPM from a given application. This task compiles the sources from the native architecture of the builder ( in this case x86_64).
Cross-building application (buildArchCross) : Build task of an RPM from a given application for a given architecture. This task compiles the sources from the architecture from the target (in this case, the aarch64), on a builder having a different architecture (in this case x86_64).
Publishing package (tagBuild) : Publication of resulting RPM(s) into repositories so that RPM is available to be installed on a target using dnf command.

Test