forked from TYPO3/typo3
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathgitlab-ci.yml
58 lines (54 loc) · 2.63 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
default:
# Always retry a failed job, so it has a chance to recover from a faulty machine, network 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
# The `--pull=never` flag must not be removed.
# All images used by CI-jobs have to be preloaded on the TYPO3 testing
# infrastructure to avoid exceeding rate limits for docker.io or ghcr.io.
CI_PARAMS: "--pull=never"
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 'npm ci' or 'composer min' or similar.
key: main-composer
paths:
- .cache
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/acceptance-application-composer.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/acceptance-application-composer.yml'
- local: 'Build/gitlab-ci/nightly/functional.yml'