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 application pre-packaged, patched and tested which can be used to compose a bootable image usable as an operating system.

Example: redpesk LTS corn 3.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 corn 3.0
- aligned on CentOS for Long Term Support, this is used for industrial and commercial needs
- short name: rpcorn (stand for corn 3.0), corn_0_2(stand for corn 3.0.2)
LTS update version:
- full name: redpesk lts corn 3.0-update
- updated version of redpesk lts corn 3.0 that provides latest changes (security or bug fixes) on top of corn 3.0

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 applications (packages).

The project needs a name, it also have a slug and an uid to be identified in the web UI. This slug is an alias which, with uid, uniquely identify the project with other tools and URL, Ex: my-unique-slug_12345abc.

There are several types of projects depending on your needs:

Standard project : used to build applications (packaged as RPMs),
Container project : used to build containerized applications. It is based on redpak container,
Image project : used to build an image. Then, the resulting image can be deployed on a real board or emulator like qemu.

For standard project, the project will resulting to a RPM repository, it contains all RPM packages resulting of applications builds.

Inheritance between projects: inheritance allows one project to inherit the resources (understand applications / packages through RPM repository) 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 by 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 the sources from the application, the user needs to provide a GIT source URL, example: git@github.com:myFolder. To package an application the redpesk factory needs a spec-file as well (this is redhat/fedora build process).

Environment

Environment are available inside projects. Environments allow to have various variants of your projects to define for example different secrets.

When you create a project, an initial environment is automatically associated and is named: default.

A common usage is to define in your project one environment for production (eg. named prod), one environment for development (eg. named dev), in order to have different secret values for production and for development, for example.

Secret

A secret has a key name and a value. The key is used to refer the secret in various parts: eg. git sources URL, external specfile URL or secret injection in source code, …

Secrets are defined in the context of project’s environment.

Syntax to refer a secret is: ${{secrets.KEY_NAME}}

For more details, refer to project’s environment and secrets chapters.

Application packaging branches

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

WARNING: branch notion here is about git used to hold packaging files, eg. spec file; it’s NOT the branch of the git sources.

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
build mode
…

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, license, 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 un-compressing 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 sub-packages 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 these guides :

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

Cross build

Cross-compilation is the default build mode used for architectures other than the native architecture of the builder. It installs dependencies into a sysroot for the target architecture in order to cross-compile the application.

A set of macros is provided to simplify and make the cross-compilation process as transparent as possible. Please contact redpesk support if a configuration is missing—we can provide new ones upon request.

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.

Accel build

The accel build mode is designed to speed up emulation. It combines cross-compilation and emulation, and can be thought of as using a native sysroot inside a target rootfs. If a native tool is available, it will execute the native version; otherwise, the tool execution will be emulated.

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

On board tests