User Tools

Site Tools


services:gitlab:gitlab-runner

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
services:gitlab:gitlab-runner [2021/05/19 10:00] hoffmac00services:gitlab:gitlab-runner [2021/07/28 21:36] hoffmac00
Line 1: Line 1:
-====== Shared GitLab Runner of the Physics department ======+====== Shared GitLab Runners of the Physics Department ======
  
 All repositories have the ability to use the shared GitLab Runners. They can be used to compile, test and deliver code automatically. They must not be used for numerical computations. All repositories have the ability to use the shared GitLab Runners. They can be used to compile, test and deliver code automatically. They must not be used for numerical computations.
  
-===== Intro into GitLab CI (Continuous Integration) =====+===== Intro to GitLab CI (Continuous Integration) =====
  
 If CI is enabled and there is a push event, GitLab will automatically start a pipeline. A pipeline will run a series of specified jobs on the code and report errors it encounters. Using pipelines, you can see if a change causes an issue with existing code and you can test it for different environments. This works for all branches as well as merge requests or on a schedule. If CI is enabled and there is a push event, GitLab will automatically start a pipeline. A pipeline will run a series of specified jobs on the code and report errors it encounters. Using pipelines, you can see if a change causes an issue with existing code and you can test it for different environments. This works for all branches as well as merge requests or on a schedule.
Line 27: Line 27:
 </code> </code>
  
-This will define a job called **test** and in that job it will run ''%%./testscript%%'' from the root of the project. If this testscripts exits successfully, the job will succeed and so will the pipeline.+This will define a job called **test** and in that job it will run ''%%./testscript%%'' from the root of the project. If this testscript exits successfully, the job will succeed and so will the pipeline.
  
-Often you want to store the results of a job, for example to use it in further jobs. For this, you can use //artifacts//. Below is a sample configuration which will build a $LaTeX$ project with bibtex to a PDF and upload the resulting PDF to our GitLab instance.+Often you will want to store the results of a job, for example to use it in further jobs. For this, you can use //artifacts//. Below is a sample configuration that will build a $LaTeX$ project with bibtex to a PDF and upload the resulting PDF to our GitLab instance.
  
 <code yaml> <code yaml>
Line 202: Line 202:
   * buster   * buster
   * bullseye   * bullseye
-  * sid 
   * stable (stable release, installed on workstations)   * stable (stable release, installed on workstations)
   * testing (next stable release)   * testing (next stable release)
Line 209: Line 208:
  
 Available variants: Available variants:
-  * base (simplest variant e.g. for simple shell scripts)+  * base (most simple variant e.g. for simple shell scripts)
   * dev (for C/C++ projects)   * dev (for C/C++ projects)
   * python (comes with the same python libs as the workstations)   * python (comes with the same python libs as the workstations)
services/gitlab/gitlab-runner.txt · Last modified: 2022/07/08 15:58 by hoffmac00

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki