mirrored from https://gitlab.com/project-march/march
-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy path.gitlab-ci.yml
74 lines (71 loc) · 3.39 KB
/
.gitlab-ci.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
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
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
# Before you change anything in this or any related file, it is highly recommended to read the
# reference on https://docs.gitlab.com/ee/ci/yaml/ and related pages. The configuration
# of the GitLab CI/CD won't make much sense without the information on those pages.
# Either run a pipeline for a MR or for a branch, but not both to prevent duplicate
# pipelines.
# See https://docs.gitlab.com/ee/ci/yaml/index.html#switch-between-branch-pipelines-and-merge-request-pipelines
# for more details
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: always
- if: '$CI_PIPELINE_SOURCE == "schedule"'
when: always
# To run a pipeline after a merge for all the protected branches e.g. gait.
# To add a protected branch go to https://gitlab.com/project-march/march/-/settings/repository -> Protected branches.
# Note: Don't remove ' == "true"', it is needed. The statements otherwise checks for the existence of the boolean.
- if: '$CI_COMMIT_REF_PROTECTED == "true"'
when: always
- when: never
variables:
# Define how submodules are handled. See https://docs.gitlab.com/ee/ci/runners/README.html#git-submodule-strategy
GIT_SUBMODULE_STRATEGY: recursive
# The different stages of the pipeline. They will occur in this order.
# See https://docs.gitlab.com/ee/ci/yaml/README.html#stages for more explaination
# on how this should be interpreted.
stages:
- Build container
- Documentation
- Lint code
- Build code
- Test code
# - Static analysis on code
# GitLab defines different job types, depending on how the job is scheduled.
# Right now, we use two types: 1) branches, 2) merge_requests
# and 3) scheduled pipelines
#
# 1) Branches
# Pipelines labeled "branches" are executed on the latest commit of a branch. All
# jobs that are scheduled conditionally based on the file changes in the
# latest commit (the "rules" keyword,
# see https://docs.gitlab.com/ee/ci/yaml/README.html#ruleschanges)
#
# 2) Merge requests
# Pipelines labeled "merge_requests" are executed when commits are pushed to a
# merge request. This pipeline runs on the difference between the target branch
# and the source branch. The "rules" keywords covers ALL changes that differ
# between the two branches.
#
# 3) Scheduled pipelines
# Pipelines labeled "schedule" are executed on certain times of the day, as defined
# on GitLab. These are the same as branch pipelines but then they are executed based
# on the time of the day, instead of when a new commit has been pushed.
#
# In short: branches = only latest commit, but when a new commit is pushed
# merge_requests = all commits in in merge request
# schedule = only latest commit, but when a predefined time of day is reached
#
# An overview of all the different types can be
# found on https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
# under the variable "CI_PIPELINE_SOURCE".
#
# You will see these three types in almost any job definition.
# To make the main .gitlab-ci.yml file easier to follow, the actual job definitions
# are split into different files. Each file specifies the jobs of a stage.
include:
- local: /.gitlab/pipeline/build-container.yml
- local: /.gitlab/pipeline/documentation/docs.yml
- local: /.gitlab/pipeline/lint-code.yml
- local: /.gitlab/pipeline/build-code.yml
- local: /.gitlab/pipeline/test-code.yml
# - local: /.gitlab/pipeline/static-analysis.yml