# include.drupalci.main.yml - This parent include contains nested includes for all DrupalCI test features. As long as you include this, any future includes added by the Drupal Association will be accessible to your pipelies automatically.
# View this file to see what nested includes are provided.
# As long as you include this, any future includes added by the Drupal Association will be accessible to your pipelines automatically.
# View these include files at https://git.drupalcode.org/project/gitlab_templates/
# - Recommended (default) - `ref: $_GITLAB_TEMPLATES_REF` - The Drupal Association will update this value to the recommended tag for contrib.
# - Latest - `ref: main` - Get the latest additions and bug fixes as they are merged into the templates.
# - Minor or Major latests - `ref: 1.x-latest` or `ref: 1.0.x-latest` - Get the latest additions within a minor (mostly bugfixes) or major (bugs and new features).
# - Fixed tag - `ref: 1.0.1` - Set the value to a known tag. This will not get any updates.
ref:$_GITLAB_TEMPLATES_REF
file:
-'/includes/include.drupalci.main.yml'
# EXPERIMENTAL: For Drupal 7, remove the above line and uncomment the below.
# - '/includes/include.drupalci.main-d7.yml'
-'/includes/include.drupalci.variables.yml'
-'/includes/include.drupalci.workflows.yml'
################
# Variables
#
# The include file include.drupalci.main.yml in this template includes a include.drupalci.variables.yml
# - These variables provide 'Semantic Labels' to help you automatically track the current supported and development versions of Drupal, as well as the current min/max system requirements for PHP, database, etc.
# - If this file is updated, your testing configuration will automatically follow these changes.
# Pipeline configuration variables
#
# Overriding variables
# - To override one or more of these variables, simply declare your own variables keyword.
# - Keywords declared directly in .gitlab-ci.yml take precedence over include files.
# Each job is assigned to a stage, defining the order in which the jobs are executed.
# Jobs in the same stage run in parallel.
#
# If all jobs in a stage succeed, the pipeline will proceed to the next stage.
# If any job in the stage fails, the pipeline will exit early.
################
stages:
################
# Build
#
# In the Build stage we are assembling our test environment:
# * Selecting the core version to test against
# * Selecting php version
# * Selectig the database, and configuring it
# * Plus any additional build steps, like composer runs, etc
# Wherever possible, we use variables defined in: include.druaplci.variables.yml so that the configuration can stay up to date with current Drupal Core development.
# The validate stage includes any codebase validation that we want to perform before running functional tests. These are items we may want to fail-fast on, before doing a full test-run.
################
-validate
################
# Test
#
# The test phase actually executes the functional tests, as well as gathering results and artifacts.
################
-test
################
# Jobs
#
# Jobs define what scripts are actually executed in each stage.
#
# The 'rules' keyword can also be used to define conditions for each job.
# # @TODO: Use rules to define core version to test against, allow overriding default on manual run with variables. (Perhaps with 'variables in variables')
