-
Notifications
You must be signed in to change notification settings - Fork 638
/
gitlab-ci.yml
74 lines (68 loc) · 3.32 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
default:
# Always retry a failed job, so it has a chance to recover from a faulty machine or timing issue
retry: 1
# Any job taking longer than this is considered 'failed'
timeout: 30m
variables:
# When a branch derives from main or 10.4 or something, composer stumbles
# if the repos has been 'shallow cloned', can't determine the source branch
# and fails with package conflicts. Having a full clone by setting depth 0
# prevents this, so we don't need to fiddle with COMPOSER_ROOT_VERSION env var.
GIT_DEPTH: 0
# Remove the usage of umask 0000 call for jobs executed with docker executor.
# gitlab repo clones otherwise lead to funny file permissions,
# which especially confuses runTests.sh -s checkPermissions
FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR: 1
# Each script line from will be in a collapsible section in the job output
# and show the duration of each line.
FF_SCRIPT_SECTIONS: 1
# The project directory will be cleaned up at the end of the build with a
# series of git clean commands, with our git fetch strategy.
FF_ENABLE_JOB_CLEANUP: 1
cache:
# Default caching of .cache directory if a job does not override it.
# General rule: Keep them as small as possibles since that is less unpack work.
# Jobs that do the same thing, should use the same key. Jobs that derivate from
# defaults, should have an own cache.
# Examples: main-composer, main-composer-js, main-composer-min-js, 10.4-composer
# For job runtime, it does not matter much if there are many caches,
# it is more important that single jobs don't unpack too much every time.
# The default key is: "Cache everything created by a 'composer install' for main branch.
# This means jobs using this default key should not create additional stuff in .cache
# directory, for instance by calling a 'yarn install' or 'composer min' or similar.
key: main-composer
paths:
- .cache
services:
# Each job starts two containers: This dind container that starts a docker
# daemon, plus a casual container that executes runTests.sh for single jobs
# to start containers within the dind container.
- name: docker:20.10-dind
alias: docker
# This is *never* overridden in single jobs. All jobs start a 'dind' service
# so runTests.sh starts 'sub' containers within the dind container, and this
# main entry point container executes runTests.sh to start containers.
image: typo3/core-testing-docker:latest
stages:
# Stages for pre-merge
- main
# Stages for nightly
- integrity
- unit
- acceptance
- functional
include:
# Pre-merge tests are triggered by pushing to changes to gerrit.
# A push to gerrit has a change-id and a patch-set, a gerrit-gitlab-adapter
# turns this into a branch 'change-patchset' which executes the pipeline
- local: 'Build/gitlab-ci/pre-merge/acceptance-install.yml'
- local: 'Build/gitlab-ci/pre-merge/acceptance-application.yml'
- local: 'Build/gitlab-ci/pre-merge/integrity.yml'
- local: 'Build/gitlab-ci/pre-merge/functional.yml'
- local: 'Build/gitlab-ci/pre-merge/unit.yml'
# Nightly tests are triggered by gitlab schedules
- local: 'Build/gitlab-ci/nightly/integrity.yml'
- local: 'Build/gitlab-ci/nightly/unit.yml'
- local: 'Build/gitlab-ci/nightly/acceptance-install.yml'
- local: 'Build/gitlab-ci/nightly/acceptance-application.yml'
- local: 'Build/gitlab-ci/nightly/functional.yml'