\label{doc_BUILDSERVER_md_md_doc_BUILDSERVER}%
\Hypertarget{doc_BUILDSERVER_md_md_doc_BUILDSERVER}%
 The \href{https://build.libelektra.org/}{\texttt{ Elektra buildserver}} handles a variety of tasks that reaches from testing Pull Requests (PRs) to deploying new versions of the \href{https://www.libelektra.org}{\texttt{ Elektra website}}.

We reworked our build system to use a more modern Jenkinsfile approach with benefits such as


\begin{DoxyItemize}
\item tracking modifications to our build process in SCM
\item tracking changes to the build environment
\item speeding up builds
\end{DoxyItemize}\hypertarget{doc_BUILDSERVER_md_autotoc_md718}{}\doxysection{Setup}\label{doc_BUILDSERVER_md_autotoc_md718}
This section aims to give an introduction into this setup.\hypertarget{doc_BUILDSERVER_md_autotoc_md719}{}\doxysubsection{Multibranch Pipeline Jobs (libelektra)}\label{doc_BUILDSERVER_md_autotoc_md719}
We use the Jenkins Job type called \href{https://jenkins.io/doc/book/pipeline/multibranch/\#creating-a-multibranch-pipeline}{\texttt{ Multibranch Pipeline}} provided by the \href{https://wiki.jenkins.io/display/JENKINS/Pipeline+Multibranch+Plugin}{\texttt{ Pipeline Multibranch Plugin}} for our CI tests called {\ttfamily libelektra}.

Simplified a multibranch pipeline job acts as an umbrella job that spawns child jobs for different branches (hence multibranch). The main purpose of the libelektra job is to scan the repository for changes to existing branches or to find new ones (for example branches that are used in PR\textquotesingle{}s). It also contains the information on how to build the jobs in the form of a path that points to a Jenkinsfile containing more detailed instructions. The job also takes care of handling build artifacts that are archived and cleaning them out once the PRs are closed and a grace period has expired.

Summarized libelektra\textquotesingle{}s job purpose is to combine the where (our Git repository), with a when (tracking changes via polling or webhooks) with a how (pointing to the Jenkinsfile + configuration).\hypertarget{doc_BUILDSERVER_md_autotoc_md720}{}\doxysubsection{Jenkins Shared Library}\label{doc_BUILDSERVER_md_autotoc_md720}
We use a \href{https://www.jenkins.io/doc/book/pipeline/shared-libraries/}{\texttt{ shared library}} to share common functionalities across multiple pipelines. This shared library contains all docker related functionalities, code to publish artifacts and various other directives and helper functions. After integrating this shared library with\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{@Library('libelektra-\/shared') \_}
\DoxyCodeLine{}
\DoxyCodeLine{pipelineConfig \{}
\DoxyCodeLine{  now = new Date()}
\DoxyCodeLine{\}}

\end{DoxyCode}


we can use any function that is declared in the shared library.

It is available in the \href{https://github.com/ElektraInitiative/jenkins-library}{\texttt{ following repository}}. For more detailed usage instruction or instructions on how to integrate this shared library into Jenkins, see its \href{https://github.com/ElektraInitiative/jenkins-library/blob/master/README.md}{\texttt{ README.\+md}}.\hypertarget{doc_BUILDSERVER_md_autotoc_md721}{}\doxysubsection{Jenkinsfiles}\label{doc_BUILDSERVER_md_autotoc_md721}
Jenkinsfiles describe what actions the build system should execute on which build slave. Currently Elektra uses four different files.\hypertarget{doc_BUILDSERVER_md_autotoc_md722}{}\doxysubsubsection{Jenkinsfile.\+daily}\label{doc_BUILDSERVER_md_autotoc_md722}

\begin{DoxyItemize}
\item Jenkinsfile.daily contains daily maintenance tasks, like cleaning up build servers.
\item \href{https://build.libelektra.org/job/libelektra-daily/}{\texttt{ Buildjob\+: libelektra-\/daily}}
\item \href{https://master.libelektra.org/scripts/jenkins/Jenkinsfile.daily}{\texttt{ Jenkinsfile.\+daily}}
\end{DoxyItemize}\hypertarget{doc_BUILDSERVER_md_autotoc_md723}{}\doxysubsubsection{Jenkinsfile.\+monthly}\label{doc_BUILDSERVER_md_autotoc_md723}

\begin{DoxyItemize}
\item Jenkinsfile.monthly contains monthly triggering of libelektra job on master.
\item \href{https://build.libelektra.org/job/libelektra-monthly/}{\texttt{ Buildjob\+: libelektra-\/monthly}}
\item \href{https://master.libelektra.org/scripts/jenkins/Jenkinsfile.monthly}{\texttt{ Jenkinsfile.\+monthly}}
\end{DoxyItemize}\hypertarget{doc_BUILDSERVER_md_autotoc_md724}{}\doxysubsubsection{Jenkinsfile.\+release}\label{doc_BUILDSERVER_md_autotoc_md724}

\begin{DoxyItemize}
\item Triggered manually with optional arguments. It is used for automated releasing a new version of Elektra.
\item Jenkinsfile.release contains description how to release a new version of Elektra.
\item \href{https://build.libelektra.org/job/libelektra-release/}{\texttt{ Buildjob\+: libelektra-\/release}}
\item \href{https://master.libelektra.org/scripts/jenkins/Jenkinsfile.release}{\texttt{ Jenkinsfile.\+release}}
\end{DoxyItemize}\hypertarget{doc_BUILDSERVER_md_autotoc_md725}{}\doxysubsubsection{Jenkinsfile}\label{doc_BUILDSERVER_md_autotoc_md725}

\begin{DoxyItemize}
\item Triggered on code changes and is for testing changes to the codebase.
\item Jenkinsfile contains descriptions how to build, test and deploy Elektra.
\item \href{https://build.libelektra.org/job/libelektra/}{\texttt{ Buildjob\+: libelektra}}
\item \href{https://master.libelektra.org/scripts/jenkins/Jenkinsfile}{\texttt{ Jenkinsfile}}
\end{DoxyItemize}\hypertarget{doc_BUILDSERVER_md_autotoc_md726}{}\doxysubsubsection{DSL}\label{doc_BUILDSERVER_md_autotoc_md726}
The language used is a groovy based DSL described in the \href{https://jenkins.io/doc/book/pipeline/jenkinsfile/}{\texttt{ Jenkinsfile book}}. Most groovy syntax is allowed to describe pipelines in a Jenkinsfile, but it is executed in a sandbox which might block certain calls.

Since plugins might extend the pool of available commands or variables a full list of currently available syntax can be seen in \href{https://build.libelektra.org/job/libelektra/pipeline-syntax/}{\texttt{ pipeline syntax}} after a login to the build server. Some functionality is not covered by this page when the responsible plugin is not implementing it. Usually an approach similar to what is described on \href{https://stackoverflow.com/questions/51103359/jenkins-pipeline-return-value-of-build-step}{\texttt{ stackoverflow}} can be used to track down the responsible code inside the providing plugins source code.

We also provide a number of helper functions in our Jenkinsfiles that are documented at the function head. Most common use cases, for example adding a new build with certain CMake flags, are easy to add because of them. For example, the configuration that is responsible for the {\ttfamily debian-\/stable-\/full} stage is generated completely by a single helper function called {\ttfamily build\+And\+Test}\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{tasks << buildAndTest(}
\DoxyCodeLine{  "{}debian-\/stable-\/full"{},}
\DoxyCodeLine{  DOCKER\_IMAGES.stretch,}
\DoxyCodeLine{  CMAKE\_FLAGS\_BUILD\_ALL +}
\DoxyCodeLine{    CMAKE\_FLAGS\_BUILD\_FULL +}
\DoxyCodeLine{    CMAKE\_FLAGS\_BUILD\_STATIC +}
\DoxyCodeLine{    CMAKE\_FLAGS\_COVERAGE}
\DoxyCodeLine{  ,}
\DoxyCodeLine{  [TEST.ALL, TEST.MEM, TEST.NOKDB, TEST.INSTALL]}
\DoxyCodeLine{)}

\end{DoxyCode}


When adding new stages to the build chain it is generally a good idea to look up an existing stage which does something similar and adapt it to the new use case.\hypertarget{doc_BUILDSERVER_md_autotoc_md727}{}\doxysubsection{Security}\label{doc_BUILDSERVER_md_autotoc_md727}
Since a malicious PR could easily destroy the build server and slaves or expose credentials some restrictions are introduced. Only PR authors that have the right to push to libelektra can modify the Jenkinsfile and have those changes be respected for the respective branch.\hypertarget{doc_BUILDSERVER_md_autotoc_md728}{}\doxysubsection{Test Environments}\label{doc_BUILDSERVER_md_autotoc_md728}
We use Docker containers to provide the various test environments.

They are described \href{https://master.libelektra.org/scripts/docker}{\texttt{ in the repository}} and the Jenkinsfile describes how to build them. If a rebuild of the images is needed is determined by the hash of the Dockerfile used to describe it. If it has not changed the build step will be skipped. In the case that an image needed a build it will afterwards be uploaded into a private Docker image registry (on a7) and thus is shared between all Docker capable build slaves.\hypertarget{doc_BUILDSERVER_md_autotoc_md729}{}\doxysection{Jenkinsfile (\+Main CI Pipeline)}\label{doc_BUILDSERVER_md_autotoc_md729}
\hypertarget{doc_BUILDSERVER_md_autotoc_md730}{}\doxysubsection{Tests}\label{doc_BUILDSERVER_md_autotoc_md730}
We will use the Docker images build as described earlier to run compilations and tests for Elektra. This allows us to run tests independent of which nodes are available (as the environment is portable).

The Jenkinsfile describes the steps used to run tests. Helper functions for easily adding new tests are available ({\ttfamily build\+And\+Test}, {\ttfamily Build\+And\+Test\+Asan}, ...).

The {\ttfamily with\+Docker\+Env} helper, that is available in the shared library, makes sure to print the following information at the start of a test branch\+:


\begin{DoxyItemize}
\item branch name
\item build machine
\item docker image id
\end{DoxyItemize}

Coverage reports are generated automatically when using the {\ttfamily build\+And\+Test} helper and the appropriate CMake flags for coverage generation have been set. They are uploaded to \href{https://doc.libelektra.org/coverage/}{\texttt{ https\+://doc.\+libelektra.\+org/coverage/}}.

Artifacts from {\ttfamily ctest} are also preserved automatically when using {\ttfamily build\+And\+Test}. The function also takes care of providing a stage name based path so multiple tests can not overwrite files that share the same name.

Tests are executed in order dictated by the Jenkinsfile. In general new tests should be added to the \textquotesingle{}full build stage\textquotesingle{} that will only run after a standard full test run succeeded. This saves execution time on the build server for the most common errors.

Since there is no strict way to enforce the way tests are added we encourage you to read the existing configuration and modify existing tests so they suite your needs.\hypertarget{doc_BUILDSERVER_md_autotoc_md731}{}\doxysubsection{Deployment}\label{doc_BUILDSERVER_md_autotoc_md731}
For runs of the build job that are run in the master branch we also execute deployment steps after all tests pass. We use these steps to build Debian and Fedora packages and move them into the repositories hosted on the community node.

Additionally we recompile the homepage and deploy it on the community node.\hypertarget{doc_BUILDSERVER_md_autotoc_md732}{}\doxysection{Jenkinsfile.\+release (\+Release Pipeline)}\label{doc_BUILDSERVER_md_autotoc_md732}
\hypertarget{doc_BUILDSERVER_md_autotoc_md733}{}\doxysubsection{Release Builds}\label{doc_BUILDSERVER_md_autotoc_md733}
The {\ttfamily build\+Release} function runs various test suites and collects and archives debug information. It also generates source-\/packages and packages for Debian based distributions and Fedora.

The generated packages are additionally installed and tested on a clean Docker image.\hypertarget{doc_BUILDSERVER_md_autotoc_md734}{}\doxysubsection{Manual approval}\label{doc_BUILDSERVER_md_autotoc_md734}
In order to verify the correct behavior and results of the previous steps and their generated artifacts, we use the \href{https://www.jenkins.io/doc/pipeline/steps/pipeline-input-step/}{\texttt{ Input Step}} to pause the pipeline. After manually verifying the correctness, the pipeline run can be resumed.\hypertarget{doc_BUILDSERVER_md_autotoc_md735}{}\doxysubsection{Publishing}\label{doc_BUILDSERVER_md_autotoc_md735}
The previously generated packages are published to the repositories, as described above in {\itshape Jenkinsfile (Main CI Pipeline)}. The API documentation and source packages get published to the relevant Git repositories. Finally the Alpine release image is published to Docker Hub.\hypertarget{doc_BUILDSERVER_md_autotoc_md736}{}\doxysection{Jenkins Setup}\label{doc_BUILDSERVER_md_autotoc_md736}
This section describes how to replicate the current Jenkins configuration.\hypertarget{doc_BUILDSERVER_md_autotoc_md737}{}\doxysubsection{Jenkins libelektra Configuration}\label{doc_BUILDSERVER_md_autotoc_md737}
The {\ttfamily libelektra} build job is a multibranch pipeline job. It is easiest to add via the Blue\+Ocean interface.

Most of the default settings should be ok, however some settings need to be verified or added to build Elektra correctly\+:


\begin{DoxyItemize}
\item {\ttfamily Advanced clone behaviors} should be added and the path to the Git mirror needs to be specified\+: {\ttfamily /home/jenkins/git\+\_\+mirrors/libelektra}. This reference repository is created and maintained by our \href{https://build.libelektra.org/job/libelektra-daily/}{\texttt{ daily buildjob}}.
\item Under Property strategy you can add {\ttfamily Trigger build on pull request comment}. {\ttfamily jenkins build (libelektra$\vert$all) please} is a good starting point. This functionality is provided by the \href{https://wiki.jenkins-ci.org/display/JENKINS/GitHub+PR+Comment+Build+Plugin}{\texttt{ Git\+Hub PR Comment Build Plugin}}.
\item For Build Configuration you want to specify {\ttfamily by Jenkinsfile} and add the script path\+: {\ttfamily scripts/jenkins/\+Jenkinsfile}.
\end{DoxyItemize}\hypertarget{doc_BUILDSERVER_md_autotoc_md738}{}\doxysubsection{Jenkins libelektra-\/release Configuration}\label{doc_BUILDSERVER_md_autotoc_md738}
The {\ttfamily libelektra-\/release} job is a normal pipeline job.

Most of the default settings can be used.


\begin{DoxyItemize}
\item Under General you need to enable {\ttfamily Permission to Copy Artifact} and set the field to {\ttfamily $\ast$}.
\item For Build Configuration you want to specify {\ttfamily by Jenkinsfile} and add the script path\+: {\ttfamily scripts/jenkins/\+Jenkinsfile.\+release}.
\end{DoxyItemize}\hypertarget{doc_BUILDSERVER_md_autotoc_md739}{}\doxysubsection{General Set-\/\+Up of a New Pipeline}\label{doc_BUILDSERVER_md_autotoc_md739}
We will cover how to set-\/up a pipeline that uses a different Git repository than this {\ttfamily libelektra} repository.

Most of the default settings can be used.


\begin{DoxyItemize}
\item If a private repository were to be used with a Git\+Hub type job, a credentials pair of {\ttfamily elektrabot} must be selected to access this repository.
\item For Build Configuration you want to specify {\ttfamily by Jenkinsfile} and add the script path to the Jenkinsfile.
\end{DoxyItemize}

We first start by including the shared library as described above in {\itshape Jenkins Shared Library}. Then we declare in a Jenkinsfile an empty map that will contain all Docker images we will use in this pipeline\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{DOCKER\_IMAGES = [:]}

\end{DoxyCode}


This map will later be populated in a function. For a Docker image with Ubuntu Focal and the Dockerfile located at {\ttfamily ./ci/\+Dockerfile} this function would need to look as follows\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{def dockerInit() \{}
\DoxyCodeLine{  node('master') \{}
\DoxyCodeLine{    checkout scm}
\DoxyCodeLine{}
\DoxyCodeLine{    DOCKER\_IMAGES.focal = dockerUtils.createDockerImageDesc(}
\DoxyCodeLine{      'ubuntu-\/focal', dockerUtils.\&idTesting,}
\DoxyCodeLine{      './ci/',}
\DoxyCodeLine{      './ci/Dockerfile'}
\DoxyCodeLine{    )}
\DoxyCodeLine{    // more docker images ...}
\DoxyCodeLine{  \}}
\DoxyCodeLine{\}}

\end{DoxyCode}


We can now begin to create the stages that initialize, pull and if necessary also build these Docker images\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{stage('Init docker images') \{}
\DoxyCodeLine{  dockerInit()}
\DoxyCodeLine{\}}
\DoxyCodeLine{}
\DoxyCodeLine{stage('Pull docker images') \{}
\DoxyCodeLine{  parallel dockerUtils.generateDockerPullStages(DOCKER\_IMAGES)}
\DoxyCodeLine{\}}
\DoxyCodeLine{}
\DoxyCodeLine{maybeStage('Build docker images', DOCKER\_IMAGES.any \{ img -\/> !img.value.exists \}) \{}
\DoxyCodeLine{  lock('docker-\/images') \{}
\DoxyCodeLine{        parallel dockerUtils.generateDockerBuildStages(DOCKER\_IMAGES)}
\DoxyCodeLine{  \}}
\DoxyCodeLine{\}}

\end{DoxyCode}


Now the actual stages that contain our CI/\+CD code can be created.

To allow parallel execution of stages we create generator functions that return a map of stages that can be executed in parallel. For example the following generator function would create a map of two tasks that could be run in parallel.


\begin{DoxyCode}{0}
\DoxyCodeLine{def generateTestStages() \{}
\DoxyCodeLine{  def tasks = [:]}
\DoxyCodeLine{}
\DoxyCodeLine{  tasks << test(}
\DoxyCodeLine{    'ubuntu-\/focal-\/test',}
\DoxyCodeLine{    DOCKER\_IMAGES.focal}
\DoxyCodeLine{  )}
\DoxyCodeLine{}
\DoxyCodeLine{  tasks << test(}
\DoxyCodeLine{    'ubuntu-\/bionic-\/test',}
\DoxyCodeLine{    DOCKER\_IMAGES.bionic}
\DoxyCodeLine{  )}
\DoxyCodeLine{}
\DoxyCodeLine{  return tasks}
\DoxyCodeLine{\}}

\end{DoxyCode}


Suppose we have a bash script {\ttfamily test.\+sh} in the root of our Git repository. This script can be executed inside one of our Docker images by using the {\ttfamily with\+Docker\+Env} function\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{def test(stageName, image) \{}
\DoxyCodeLine{  return [(stageName): \{}
\DoxyCodeLine{    stage(stageName) \{}
\DoxyCodeLine{      withDockerEnv(image) \{}
\DoxyCodeLine{        sh "{}./test.sh"{}}
\DoxyCodeLine{      \}}
\DoxyCodeLine{    \}}
\DoxyCodeLine{  \}]}
\DoxyCodeLine{\}}

\end{DoxyCode}


We can now call the generator function {\ttfamily generate\+Test\+Stages} in a new stage\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{stage('Testing') \{}
\DoxyCodeLine{  parallel generateTestStages()}
\DoxyCodeLine{\}}

\end{DoxyCode}
\hypertarget{doc_BUILDSERVER_md_autotoc_md740}{}\doxysubsection{Adding a Jenkins Node}\label{doc_BUILDSERVER_md_autotoc_md740}
A node needs to have a JRE (Java Runtime Environment) installed. Further it should run an SSH (Secure SHell) server. Docker need to be installed as well.

A {\ttfamily jenkins} user with 47110\+:47110 ids should be created as this is what is expected in Docker images. {\ttfamily useradd -\/u 47110 jenkins} Additionally a public key authentication should be set up so the jenkins master can establish an SSH connection with the node. If the node should be able to interact with Docker the jenkins user should be added to the {\ttfamily docker} group.

Nodes should be set to only build jobs matching their labels and to be online as much as possible. As for labels {\ttfamily gitmirror} should be if you want to cache repositories on this node. If Docker is available the {\ttfamily docker} label should be set.

All files and folders in the Node under {\ttfamily /home/jenkins} should be owned by user {\ttfamily jenkins}.\hypertarget{doc_BUILDSERVER_md_autotoc_md741}{}\doxysection{Understanding Jenkins Output}\label{doc_BUILDSERVER_md_autotoc_md741}
Our Jenkins build uses parallel steps inside a single build job to do most of the work. To reliably determine which stages failed it is best to look over the build results in the Jenkins Blue Ocean view. It is the default View opened when accessing the build results from Git\+Hub. For libelektra the URLs are \href{https://build.libelektra.org/job/libelektra/}{\texttt{ https\+://build.\+libelektra.\+org/job/libelektra/}} and \href{https://build.libelektra.org/blue/organizations/jenkins/libelektra/branches/}{\texttt{ https\+://build.\+libelektra.\+org/blue/organizations/jenkins/libelektra/branches/}} Failed stages are marked in red. On selecting a stage you can further expand all steps in the stage. Of interest should be one of the first steps which echos out the Docker image used to run the stage. You also want to look for whatever failed (which should be in a step also marked red to indicate failure).\hypertarget{doc_BUILDSERVER_md_autotoc_md742}{}\doxysection{Reproducing Build Server Errors Locally}\label{doc_BUILDSERVER_md_autotoc_md742}
First you have to determine which image is used. This is described above in {\itshape Understanding Jenkins output}.

Afterwards you can download it from our registry via {\ttfamily docker pull}. Pay attention that you have to use {\bfseries{hub-\/public.\+libelektra.\+org}} as this subdomain does not require authentication for GET operations used by the Docker client. As an example\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{docker pull hub-\/public.libelektra.org/build-\/elektra-\/alpine:201809-\/791f9f388cbdff0db544e02277c882ad6e8220fe280cda67e6ea6358767a065e}

\end{DoxyCode}


You can also rebuild the images locally, which is useful if you want to test changes you made to the Dockerfiles themselves. Locate which Dockerfile you need by looking up the reference the stage that used it in the Jenkinsfile. For {\itshape alpine} this would be {\ttfamily DOCKER\+\_\+\+IMAGES.\+alpine}. You can search for this entry in the Jenkinsfile to find that this image is build from the context {\ttfamily ./scripts/docker/alpine/$\ast$} and uses {\ttfamily ./scripts/docker/alpine/$\ast$/\+Dockerfile} as a Dockerfile. Now you can build the image as described in \href{https://master.libelektra.org/scripts/docker/README.md\#building-images-locally}{\texttt{ scripts/docker/\+README.\+md}}.

You can find more information on how to use our images in \href{https://master.libelektra.org/scripts/docker/README.md\#testing-elektra-via-docker-images}{\texttt{ scripts/docker/\+README.\+md}}.

Alternatively, you can follow the \mbox{\hyperlink{doc_tutorials_run_all_tests_with_docker_md}{tutorial}}.\hypertarget{doc_BUILDSERVER_md_autotoc_md743}{}\doxysection{Modify Test Environments}\label{doc_BUILDSERVER_md_autotoc_md743}
You can also modify the test environments (update a dependency, install a new dependency, ...) by editing the Dockerfiles checked into SCM. Determine which ones you need to modify by tracing which images are used for what stages via the {\ttfamily DOCKER\+\_\+\+IMAGES} map used in our Jenkinsfile. The {\ttfamily docker\+Init} function should be a good start point.

Following docker best practises you should try to minimize layer count when possible. Our docker images are quite large and hence take a long time to build so make sure to test any modifications locally first.\hypertarget{doc_BUILDSERVER_md_autotoc_md744}{}\doxysection{Triggers}\label{doc_BUILDSERVER_md_autotoc_md744}
All Triggers are described in the configuration of the respective build jobs.

The \href{https://build.libelektra.org/job/libelektra/}{\texttt{ libelektra}} build is triggered for all branches of the libelektra repository except for {\ttfamily debian}. Additionally, all open branches in forks targeting libelektra\textquotesingle{}s repository via PRs are going to be build. Pushes to any of those branches will trigger a new build automatically.

The \href{https://build.libelektra.org/job/libelektra-daily/}{\texttt{ daily build}} and \href{https://build.libelektra.org/job/libelektra-monthly/}{\texttt{ monthly build}} are executed according to a cron schedule.

The \href{https://build.libelektra.org/job/libelektra-release/}{\texttt{ release pipeline}} is triggered manually with optional arguments.

The following phrases can be used as comments to manually trigger a specific build\+:


\begin{DoxyItemize}
\item jenkins build \href{https://build.libelektra.org/job/libelektra/}{\texttt{ libelektra}} please
\item jenkins build \href{https://build.libelektra.org/job/libelektra-daily/}{\texttt{ daily}} please
\item jenkins build \href{https://build.libelektra.org/job/libelektra-monthly/}{\texttt{ monthly}} please
\end{DoxyItemize}

Additionally {\ttfamily jenkins build all please} can be used to trigger all build jobs relevant for PR\textquotesingle{}s. This is not necessary anymore as all relevant tests have been moved into the libelektra job.\hypertarget{doc_BUILDSERVER_md_autotoc_md745}{}\doxysection{Authorization}\label{doc_BUILDSERVER_md_autotoc_md745}
If you are not yet authorized, the following question will be asked (by user @markus2330)\+: \begin{DoxyVerb}Can one of the admins verify if this patch should be build?
\end{DoxyVerb}
 Then one of the admins (sorted by activity)\+:


\begin{DoxyItemize}
\item @sanssecours
\item @markus2330
\item @beku
\item @\+Bernhard\+Denner
\item @fberlakovich
\item @manuelm
\end{DoxyItemize}

need to confirm by saying\+: \begin{DoxyVerb}.*add\W+to\W+whitelist.*
\end{DoxyVerb}
 or if just the pull request should be checked\+: \begin{DoxyVerb}.*build\W+allow.*
\end{DoxyVerb}
 \hypertarget{doc_BUILDSERVER_md_autotoc_md746}{}\doxysection{Issues with the Build Environment}\label{doc_BUILDSERVER_md_autotoc_md746}
If you have issues that are related to the build system you can open a normal issue and tag it with {\ttfamily build} and {\ttfamily question}. If you feel like your inquiry does not warrant an issue on its own, please use \href{https://issues.libelektra.org/160}{\texttt{ our buildserver issue}}. 