.travis.yml

# This is the language of our project.
language: php

# Installs the updated version of PostgreSQL and extra APT packages.
addons:
  postgresql: "9.6"

# Ensure DB and docker services are running.
services:
  - mysql
  - postgresql
  - docker

# Cache Composer's and NPM's caches to speed up build times.
cache:
  directories:
    - $HOME/.composer/cache
    - $HOME/.npm

# Determines which versions of PHP to test our project against.  Each version
# listed here will create a separate build and run the tests against that
# version of PHP.
php:
  - 7.2
  - 7.3
  - 7.4

# This section sets up the environment variables for the build.
env:
  global:
    # This line determines which version branch of Moodle to test against.
    - MOODLE_BRANCH=MOODLE_39_STABLE
  # This matrix is used for testing against multiple databases.  So for
  # each version of PHP being tested, one build will be created for each
  # database listed here.  EG: for PHP 7.3, one build will be created
  # using PHP 7.3 and pgsql.  In addition, another build will be created
  # using PHP 7.3 and mysqli.
  matrix:
    - DB=pgsql
    - DB=mysqli

# Optionally, it is possible to specify a different Moodle repo to use
# (git://github.com/moodle/moodle.git is used by default):
# - MOODLE_REPO=git://github.com/username/moodle.git

# Also, note that, for multi-branch scenarios, where the same plugin
# codebase needs to be tested against multiple branches of Moodle,
# it is possible to remove the `php`, `env/global`, and `matrix`
# sections above and just create a `jobs` section explicitly defining
# which `php`, `MOODLE_BRANCH` and `DB` to use, for example:
#
# jobs:
#   include:
#     - php: 7.3
#       env: MOODLE_BRANCH=MOODLE_39_STABLE    DB=pgsql
#     - php: 7.3
#       env: MOODLE_BRANCH=MOODLE_39_STABLE    DB=mysqli
#     ....
# Note: this also enables to add specific env variables (NODE_VERSION,
# EXTRA_PLUGINS...) per job, if you don't want to do it globally.

# This lists steps that are run before the installation step.
before_install:
  # This disables XDebug which should speed up the build.
  - phpenv config-rm xdebug.ini
  # Currently we are inside of the clone of your repository.  We move up two
  # directories to build the project.
  - cd ../..
  # Update Composer.
  - composer selfupdate
  # Install this project into a directory called "ci".
  - composer create-project -n --no-dev --prefer-dist moodlehq/moodle-plugin-ci ci ^3
  # Update the $PATH so scripts from this project can be called easily.
  - export PATH="$(cd ci/bin; pwd):$(cd ci/vendor/bin; pwd):$PATH"

# This lists steps that are run for installation and setup.
install:
  # Run the default install.  The overview of what this does:
  #    - Clone the Moodle project into a directory called moodle.
  #    - Create a data directory called moodledata.
  #    - Create Moodle config.php, database, etc.
  #    - Copy your plugin(s) into Moodle.
  #    - Run Composer install within Moodle.
  #    - Install the correct (or configured) version of nodejs/npm using NVM.
  #    - Run NPM install in Moodle and in your plugin if it has a "package.json".
  #    - Run "grunt ignorefiles" within Moodle to update ignore file lists.
  #    - If your plugin has Behat features, then Behat will be setup.
  #    - If your plugin has unit tests, then PHPUnit will be setup.
  - moodle-plugin-ci install

# This lists steps that are run for the purposes of testing.  Any of
# these steps can be re-ordered or removed to your liking.  And of
# course, you can add any of your own custom steps.
script:
  # This step lints your PHP files to check for syntax errors.
  - moodle-plugin-ci phplint
  # This step runs the PHP Copy/Paste Detector on your plugin.
  # This helps to find code duplication.
  #  - moodle-plugin-ci phpcpd
  # This step runs the PHP Mess Detector on your plugin. This helps to find
  # potential problems with your code which can result in
  # refactoring opportunities.
  - moodle-plugin-ci phpmd
  # This step runs the Moodle Code Checker to make sure that your plugin
  # conforms to the Moodle coding standards.  It is highly recommended
  # that you keep this step.
  # To fail on warnings use --max-warnings 0
  - moodle-plugin-ci codechecker
  # This step runs Moodle PHPDoc checker on your plugin.
  - moodle-plugin-ci phpdoc
  # This step runs some light validation on the plugin file structure
  # and code.  Validation can be plugin specific.
  - moodle-plugin-ci validate
  # This step validates your plugin's upgrade steps.
  - moodle-plugin-ci savepoints
  # This step validates the HTML and Javascript in your Mustache templates.
  #  - moodle-plugin-ci mustache
  # This step runs Grunt tasks on the plugin.  By default, it tries to run
  # tasks relevant to your plugin and Moodle version, but you can run
  # specific tasks by passing them as options,
  # EG: moodle-plugin-ci grunt -t task1 -t task2
  # To fail on eslint warnings use --max-lint-warnings 0
  - moodle-plugin-ci grunt
  # This step runs the PHPUnit tests of your plugin.  If your plugin has
  # PHPUnit tests, then it is highly recommended that you keep this step.
  - moodle-plugin-ci phpunit
  # This step runs the Behat tests of your plugin.  If your plugin has
  # Behat tests, then it is highly recommended that you keep this step.
  # There are few important options that you may want to use:
  #   - The auto rerun option allows you to rerun failures X number of times,
  #     default is 2, EG usage: --auto-rerun 3
  #   - The dump option allows you to print the failure HTML to the console,
  #     handy for debugging, EG usage: --dump
  #   - The suite option allows you to set the theme to use for behat test. If
  #     not specified, the default theme is used, EG usage: --suite boost
  #   - The profile option allows you to set the browser driver to use,
  #     default is Firefox. If you need Chrome, set '--profile chrome'.
  - moodle-plugin-ci behat