gitlab-ci.yml 3.33 KB
Newer Older
1
default:
2
3
  # Always retry a failed job, so it has a chance to recover from a faulty machine, network or timing issue
  retry: 1
4
5
  # Any job taking longer than this is considered 'failed'
  timeout: 30m
6

7
variables:
8
  # When a branch derives from main or 10.4 or something, composer stumbles
9
10
11
12
  # 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
13
14
15
16
  # 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
17
18
19
  # 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
20
21
22
  # 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
23
24
25
26
27
28

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.
29
  # Examples: main-composer, main-composer-js, main-composer-min-js, 10.4-composer
30
31
  # 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.
32
  # The default key is: "Cache everything created by a 'composer install' for main branch.
33
34
  # 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.
35
  key: main-composer
36
37
38
39
40
41
42
  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.
43
  - name: docker:20.10.14-dind
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
    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'
65
  - local: 'Build/gitlab-ci/pre-merge/acceptance-application.yml'
66
67
68
69
70
71
72
  - 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'
73
  - local: 'Build/gitlab-ci/nightly/acceptance-application.yml'
74
  - local: 'Build/gitlab-ci/nightly/functional.yml'