Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Travis integration: Difference between revisions

From MoodleDocs
m (→‎Moodle plugins: Add a link to a recent useful discussion)
m (Note about plan not to migrate this page to the new developer resources. See template for more info.)
(15 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{Template:WillNotMigrate}}
{{obsolete}}
Given the two notes below, you probably don't want to read this page. [[Github actions integration]] is much more likely to be what you want.
<div class="errorbox">Travis [https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom has announced] that '''travis-ci.org will be closed down completely on December 31st 2020''', with travis-ci.com becoming the unified place for all projects. More information can be found at:
* [https://docs.travis-ci.com/user/migrate/open-source-repository-migration Migrating repositories to travis-ci.com]
* Moodle Tracker: MDLSITE-6246</div>
<div class="errorbox">Travis [https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing has announced], November 2, 2020, that '''travis-ci.com won't be (unlimitedly) free anymore''', with everybody getting some credits (processing time) once and, after using them, you must change to some of their (paid) plans. Few weeks later, November 24, 2020, [https://blog.travis-ci.com/oss-announcement they have published an update] specifically for Open Source. There, they recommend to contact them ''"for anything relating with your open source account"''. Up to you!
More information can be found at:
* Moodle Tracker: MDL-70265</div>
== Moodle core ==
== Moodle core ==


Line 5: Line 17:
Moodle is regularly tested against a matrix of Databases, PHP Versions, and operating systems, however many developers do not have the resources available to run on many of these combinations before pushing an issue for integration as they are time-consuming to both set up and to run.
Moodle is regularly tested against a matrix of Databases, PHP Versions, and operating systems, however many developers do not have the resources available to run on many of these combinations before pushing an issue for integration as they are time-consuming to both set up and to run.


There are many Continuous Integration tools available to developers, and Travis-CI is just one of those available freely to the Open Source community.
There are many Continuous Integration tools available to developers, and Travis-CI is just one of those available to the Open Source community.


Since version 3.0, Moodle includes a Travis configuration file in its repository. This configuration file configures and controls a Travis build across a matrix of testing environments. This allows developers pushing patches to Moodle to have their code unit tested before it reaches integration. The hope is that the availability of this integration should reduce the number of unit test failures seen during Integration.
Since version 3.0, Moodle includes a Travis configuration file in its repository. This configuration file configures and controls a Travis build across a matrix of testing environments. This allows developers pushing patches to Moodle to have their code unit tested before it reaches integration. The hope is that the availability of this integration should reduce the number of unit test failures seen during Integration.


Note: Moodle HQ uses the Jenkins CI platform internally and this should be seen as the canonical CI server for Moodle. The Travis integration provided is to provide early warning to developers of any issues with their code.
Note: Moodle HQ uses the Jenkins CI platform and this should be seen as the [https://ci.moodle.org/ canonical CI server for Moodle]. The Travis integration aims is to provide early warning to developers of any issues with their code.


=== Usage ===
=== Usage ===


Travis-CI is freely available and is usually configured to run automatically when pushing code, but it must be configured before first use.
Travis-CI is available and is usually configured to run automatically when pushing code, but it must be configured before first use.


For the purpose of this documentation, it is assumed that you are pushing to a public Moodle repository on GitHub. Other integrations are supported, but the free service available from Travis is only available to public repositories.
For the purpose of this documentation, it is assumed that you are pushing to a public Moodle repository on GitHub. Other integrations are supported, but the service available from Travis is only available to public repositories.


=== Setup ===
=== Setup ===


# [https://travis-ci.org/auth Sign in to Travis CI] using your GitHub account
# [https://travis-ci.com/auth Sign in to Travis CI] using your GitHub account
# Once you’re signed in, and the initial synchronisation of your GitHub repositories has completed, go to your [https://travis-ci.org/profile profile page]
# Once you’re signed in, and the initial synchronisation of your GitHub repositories has completed, go to your [https://travis-ci.com/profile profile page]
# Enable Travis CI for your clone of the Moodle repository [[File:moodle-travis-enable.png]]
# Enable Travis CI for your clone of the Moodle repository [[File:moodle-travis-enable.png]]
# Click on the cog icon to configure the Integration
# Click on the cog icon to configure the Integration
# Ensure that "Build only if .travis.yml is present" is enabled [[File:moodle-travis-settings.png]]
# Ensure that "Build pushed branches" is enabled [[File:moodle-travis-settings-2020.png]]
# Email notifications will be sent by default to the committer and the commit author. If you want to turn off email notifications for this repository, you can define an environment variable with name MOODLE_EMAIL and "no" as value.
# By default, the following jobs will be executed for each branch sent to github:
## GRUNT: 1 job that will check that all your javascript and scss has been properly built (see [[Grunt]]) and is part of the patch.
## CITESTS: 1 job that will perform a lightweight linting of your branch.
## PHPUNIT: 1 job that will run all the unit tests on your branch (using the lowest PHP version supported by the branch and PostgreSQL as database).
# If you want to change those defaults, you can use the following environment variables:
## MOODLE_DATABASE: With value "mysqli" to switch your runs to that database. With value "all" to run both PostgreSQL and MySQL unit tests.
## MOODLE_PHP: With value "all", to run the unit tests both with the lowest and the highest PHP versions supported by the branch.
Note that adding more jobs will increase the time needed (and the credits consumed) for processing each branch, so be careful picking your fav configuration.
[[File:environment_variables.png|Define an environment variable]]
 


=== How do I start a build? ===
=== How do I start a build? ===
Line 31: Line 54:
== Moodle plugins ==
== Moodle plugins ==


See [https://blackboard-open-source.github.io/moodle-plugin-ci/ Moodle Plugin CI repository] for setup instructions.
See [https://moodlehq.github.io/moodle-plugin-ci/ Moodle Plugin CI repository] for setup instructions.


Related discussions:
Related discussions:
Line 45: Line 68:
Specifically for the codechecker command, you can ignore a single line, a section of a file or the whole file by using specific PHP comments. For details see this [[CodeSniffer]] wiki page.
Specifically for the codechecker command, you can ignore a single line, a section of a file or the whole file by using specific PHP comments. For details see this [[CodeSniffer]] wiki page.
In addition, you can ignore additional files by defining IGNORE_PATHS and/or IGNORE_NAMES environment variables in your .travis.yml file. These environment variables wont work for Grunt tasks, but will for everything else. Example:
In addition, you can ignore additional files by defining IGNORE_PATHS and/or IGNORE_NAMES environment variables in your .travis.yml file. These environment variables wont work for Grunt tasks, but will for everything else. Example:
<code php>
<syntaxhighlight lang="php">
env:
env:
  global:
  global:
Line 54: Line 77:
   - DB=pgsql
   - DB=pgsql
   - DB=mysqli
   - DB=mysqli
</code>
</syntaxhighlight>
Both environment variables take a CSV value. For IGNORE_PATHS, it takes relative file paths to ignore. File paths can be a simple string like foo/bar or a regular expression like /^foo\/bar/. For IGNORE_NAMES, it takes file names to ignore. File names can be a simple string like foo.php, a glob like *.php or a regular expression like /\.php$/.
Both environment variables take a CSV value. For IGNORE_PATHS, it takes relative file paths to ignore. File paths can be a simple string like foo/bar or a regular expression like /^foo\/bar/. For IGNORE_NAMES, it takes file names to ignore. File names can be a simple string like foo.php, a glob like *.php or a regular expression like /\.php$/.


If you need to specify ignore paths for a specific command, then you can define additional environment variables. The variable names are the same as above, but prefixed with COMMANDNAME_. Example:
If you need to specify ignore paths for a specific command, then you can define additional environment variables. The variable names are the same as above, but prefixed with COMMANDNAME_. Example:


<code php>
<syntaxhighlight lang="php">
env:
env:
  global:
  global:
Line 69: Line 92:
   - DB=pgsql
   - DB=pgsql
   - DB=mysqli
   - DB=mysqli
</code>
</syntaxhighlight>
In the above example, we are adding the cli path to our ignore paths for the PHPUnit command (this is also how you can ignore files for code coverage). Please note that this is a complete override and there is no merging with IGNORE_PATHS and IGNORE_NAMES. So, in the above, the PHPUnit command would not ignore the file names defined in IGNORE_NAMES.
In the above example, we are adding the cli path to our ignore paths for the PHPUnit command (this is also how you can ignore files for code coverage). Please note that this is a complete override and there is no merging with IGNORE_PATHS and IGNORE_NAMES. So, in the above, the PHPUnit command would not ignore the file names defined in IGNORE_NAMES.


== See also ==
== See also ==


* [[Talk:Travis Integration]] for previous Travis dev docs
* [[Github actions integration]]: For information about the, also supported, integration with GitHub Actions.


[[Category:Developer tools]]
[[Category:Developer tools]]

Revision as of 12:25, 19 April 2022


Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.


Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.


Given the two notes below, you probably don't want to read this page. Github actions integration is much more likely to be what you want.

Travis has announced that travis-ci.org will be closed down completely on December 31st 2020, with travis-ci.com becoming the unified place for all projects. More information can be found at:
Travis has announced, November 2, 2020, that travis-ci.com won't be (unlimitedly) free anymore, with everybody getting some credits (processing time) once and, after using them, you must change to some of their (paid) plans. Few weeks later, November 24, 2020, they have published an update specifically for Open Source. There, they recommend to contact them "for anything relating with your open source account". Up to you!

More information can be found at:

Moodle core

Background

Moodle is regularly tested against a matrix of Databases, PHP Versions, and operating systems, however many developers do not have the resources available to run on many of these combinations before pushing an issue for integration as they are time-consuming to both set up and to run.

There are many Continuous Integration tools available to developers, and Travis-CI is just one of those available to the Open Source community.

Since version 3.0, Moodle includes a Travis configuration file in its repository. This configuration file configures and controls a Travis build across a matrix of testing environments. This allows developers pushing patches to Moodle to have their code unit tested before it reaches integration. The hope is that the availability of this integration should reduce the number of unit test failures seen during Integration.

Note: Moodle HQ uses the Jenkins CI platform and this should be seen as the canonical CI server for Moodle. The Travis integration aims is to provide early warning to developers of any issues with their code.

Usage

Travis-CI is available and is usually configured to run automatically when pushing code, but it must be configured before first use.

For the purpose of this documentation, it is assumed that you are pushing to a public Moodle repository on GitHub. Other integrations are supported, but the service available from Travis is only available to public repositories.

Setup

  1. Sign in to Travis CI using your GitHub account
  2. Once you’re signed in, and the initial synchronisation of your GitHub repositories has completed, go to your profile page
  3. Enable Travis CI for your clone of the Moodle repository moodle-travis-enable.png
  4. Click on the cog icon to configure the Integration
  5. Ensure that "Build pushed branches" is enabled moodle-travis-settings-2020.png
  6. Email notifications will be sent by default to the committer and the commit author. If you want to turn off email notifications for this repository, you can define an environment variable with name MOODLE_EMAIL and "no" as value.
  7. By default, the following jobs will be executed for each branch sent to github:
    1. GRUNT: 1 job that will check that all your javascript and scss has been properly built (see Grunt) and is part of the patch.
    2. CITESTS: 1 job that will perform a lightweight linting of your branch.
    3. PHPUNIT: 1 job that will run all the unit tests on your branch (using the lowest PHP version supported by the branch and PostgreSQL as database).
  8. If you want to change those defaults, you can use the following environment variables:
    1. MOODLE_DATABASE: With value "mysqli" to switch your runs to that database. With value "all" to run both PostgreSQL and MySQL unit tests.
    2. MOODLE_PHP: With value "all", to run the unit tests both with the lowest and the highest PHP versions supported by the branch.

Note that adding more jobs will increase the time needed (and the credits consumed) for processing each branch, so be careful picking your fav configuration. Define an environment variable


How do I start a build?

It won't build immediately after setup. Builds start automatically when you push a change.

Moodle plugins

See Moodle Plugin CI repository for setup instructions.

Related discussions:

Ignoring files and folders

For some of the code analysis tools, it is important to ignore some files within the plugin because they might not be fixable, like a third party library. The all code analysis commands in this project ignore files and directories listed in the thirdpartylibs.xml plugin file. See https://docs.moodle.org/dev/Plugin_files#thirdpartylibs.xml for more info.

Ignoring files

Specifically for the codechecker command, you can ignore a single line, a section of a file or the whole file by using specific PHP comments. For details see this CodeSniffer wiki page. In addition, you can ignore additional files by defining IGNORE_PATHS and/or IGNORE_NAMES environment variables in your .travis.yml file. These environment variables wont work for Grunt tasks, but will for everything else. Example:

env:
 global:
  - MOODLE_BRANCH=MOODLE_35_STABLE
  - IGNORE_PATHS=vendor/widget,javascript/min-lib.js
  - IGNORE_NAMES=*-m.js,bad_lib.php
 matrix:
  - DB=pgsql
  - DB=mysqli

Both environment variables take a CSV value. For IGNORE_PATHS, it takes relative file paths to ignore. File paths can be a simple string like foo/bar or a regular expression like /^foo\/bar/. For IGNORE_NAMES, it takes file names to ignore. File names can be a simple string like foo.php, a glob like *.php or a regular expression like /\.php$/.

If you need to specify ignore paths for a specific command, then you can define additional environment variables. The variable names are the same as above, but prefixed with COMMANDNAME_. Example:

env:
 global:
  - MOODLE_BRANCH=MOODLE_35_STABLE
  - IGNORE_PATHS=vendor/widget,javascript/min-lib.js
  - IGNORE_NAMES=*-m.js,bad_lib.php
  - PHPUNIT_IGNORE_PATHS=$IGNORE_PATHS,cli
 matrix:
  - DB=pgsql
  - DB=mysqli

In the above example, we are adding the cli path to our ignore paths for the PHPUnit command (this is also how you can ignore files for code coverage). Please note that this is a complete override and there is no merging with IGNORE_PATHS and IGNORE_NAMES. So, in the above, the PHPUnit command would not ignore the file names defined in IGNORE_NAMES.

See also