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

7
8
9
10
11
12
variables:
  # 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

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
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: master-composer, master-composer-js, master-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 master 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: 9.5-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:19.03-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
  - early
  - main
  # Stages for nightly
  - integrity
  - unit
  - acceptance
  - functional
  - functional2

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/early.yml'
  - local: 'Build/gitlab-ci/pre-merge/acceptance-install.yml'
  - local: 'Build/gitlab-ci/pre-merge/acceptance-backend.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-backend.yml'
  - local: 'Build/gitlab-ci/nightly/functional.yml'