README.md 2.28 KB
Newer Older
Florian Hindenlang's avatar
Florian Hindenlang committed
1
2
3
# Getting started
This is a project to get started on the gitlab CI for compiling and testing code.

Florian Hindenlang's avatar
Florian Hindenlang committed
4
5
6
7
The master branch has a very rudimentary `.gitlab-ci.yml` file to build the project once.

You find the  branches `testlevel*`  with increasing test complexity in the script `.gitlab-ci.yml`.

Florian Hindenlang's avatar
Florian Hindenlang committed
8
Important things:
Florian Hindenlang's avatar
Florian Hindenlang committed
9
-  Explanations of the YAML syntax of the file **.gitlab-ci.yml** [found here](https://docs.gitlab.com/ce/ci/yaml)
Florian Hindenlang's avatar
Florian Hindenlang committed
10
- commits to not check: add `[CI skip]` in the commit message
11
- you can disable the email notifications under your personal notification settings in the gitlab
Florian Hindenlang's avatar
Florian Hindenlang committed
12

Florian Hindenlang's avatar
Florian Hindenlang committed
13

Florian Hindenlang's avatar
Florian Hindenlang committed
14
15
16
17
18
19
20
21
22
23
## Setup a local runner:
- Installation of a local runner [found here](https://docs.gitlab.com/runner/install/) be sure to install the version <= 1.11.4  
  `sudo apt-get install gitlab-ci-multi-runner=1.11.4`  
  since the mpcdf gitlab version is 8.17
- After installation of the runner, execute **in your home directory**
         gitlab-runner register  
  follow the steps with the url and token given on the `Settings->CI/CD pipeline` of your project on the gitlab page
- then start the runner
         gitlab-runner run  
  You should see the runner on the gitlab page  `Settings->CI/CD pipeline`
Florian Hindenlang's avatar
Florian Hindenlang committed
24

Florian Hindenlang's avatar
Florian Hindenlang committed
25
## Tags:
Florian Hindenlang's avatar
Florian Hindenlang committed
26
Tags only make sense if there are multiple runners. 
Florian Hindenlang's avatar
Florian Hindenlang committed
27
28
They allow to choose on which runner the job will be executed.

Florian Hindenlang's avatar
Florian Hindenlang committed
29
If the runner can run untagged jobs, you would not need tags, but we recommend to use at least one tag for the job, corresponding to the tag(s) of the runner. 
Florian Hindenlang's avatar
Florian Hindenlang committed
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

The tags are used to select a specific runner. Note the following:
1. Each job is assigned to only **one** runner!
1. If job has no tag
    - one runner must be configured to run untagged jobs 
1. Job has tags
    - **all** tags of a job **must match** a subset of the tags of **one** runner

Each job can have one or multiple tags, here an example:
```
job_1:
  stage: build
  tags:
    - tag1_runnerA
job_2:
  stage: build
  tags:
    - tag1_runnerB
job_3:
  stage: build
  tags:
    - tag1_runnerA
    - tag2_runnerA
```
- runner A  has the tags `tag1_runnerA` and `tag2_runnerA` ... and therefore runs  `job_1` and `job_3`
- runner B  has the tags `tag1_runnerB` and `tag2_runnerB` ... and therefore runs only `job_2`
- **Careful**, the tag list should contain only tags of **one** runner!
- **Careful**, different runners cannot have the same tag!