# * The GitLab Acceleration Initiative participants
# * DrupalSpoons
################
...
...
@@ -14,55 +14,67 @@
################
# Guidelines
#
# This template is designed to give any Contrib maintainer everything they need to test, without requiring modification. It is also designed to keep up to date with Core Development automatically through the use of include files that can be centrally maintained.
#
# However, you can modify this template if you have additional needs for your project.
# * Fail fast
# * Provide helpful user feedback
################
################
# Includes
#
# Additional configuration can be provided through includes.
# One advantage of include files is that if they are updated upstream, the changes affect all pipelines using that include.
# One advantage of include files is that if they are updated upstream, the changes affect all pipelines using that include.
#
# Includes can be overriden by re-declaring anything provided in an include, here in gitlab-ci.yml
# 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.
# The stages for core are different than those of contrib.
# - '/includes/include.drupalci.main.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.
# - 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.
#
# 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.
# - 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.
# 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.
-build-validate# This phase checks that the configuration being used for the build is valid.
-build
################
# Validate
#
# 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')
# 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.
################
-🪄 Lint# Code quality checks
################
# Test
#
# The test phase actually executes the tests, as well as gathering results and artifacts.
$this->markTestSkipped("The test wasn't able to connect to your webdriver instance. For more information read core/tests/README.md.\n\nThe original message while starting Mink: {$e->getMessage()}");
$this->fail("The test wasn't able to connect to your webdriver instance. For more information read core/tests/README.md.\n\nThe original message while starting Mink: {$e->getMessage()}. Mink driver args are ".getenv('MINK_DRIVER_ARGS_WEBDRIVER'));
}
else{
throw$e;
}
}
catch(\Exception$e){
$this->markTestSkipped('An unexpected error occurred while starting Mink: '.$e->getMessage());
$this->fail('An unexpected error occurred while starting Mink: '.$e->getMessage());
