open-lms-open-source / moodle-plugin-ci Goto Github PK

For example, the following string is detected as valid

$something['pluginname'] = 'Foo plugin';

while the correct would be $string[...]

It seems that PHPUnit on Travis CI is not able to follow namespaces to autoload classes?

As an example, see the error here - https://travis-ci.org/PoetOS/moodle-local_globalfilter/jobs/246285948#L518

The error indicates it cannot find the "external_api" class for the line:
class external extends \external_api {

But, this works fine when using PHPUnit on the Moodle site itself.

Thoughts?

Review and then integrate https://github.com/mrmark/joule-plugincheck as a new command, like moodle-plugin-ci codereview

The project should be moved into moodlerooms Github account and should be managed similarly to https://github.com/moodlerooms/moodle-coding-standard.

The point of the new standard is to add additional checks that do not make sense for the Moodle coding standard, but are required by Moodlerooms or Moodle partners in general.

Adressing this discussion :
https://moodle.org/mod/forum/discuss.php?d=341823

An example of this is the undescored variable names.
there are plenty of locations where core team use vars with underscore in core. Is the standard code checker of Moodle HQ so strict ? Most of the actual core code would not pass many rules.

I was able to make travis.yml changes that generates coverage files and uploads the output the coveralls.io. You can see an example output here: https://coveralls.io/jobs/12048046

My yml can be found in a dummy test plugin here https://github.com/merrill-oakland/moodle-local_coverage/blob/master/.travis.yml

I think it would be good to integrate the code coverage capability in moodle-plugin-ci, so people can do it much more cleanly.

There are two parts to code coverage. First, generating a coverage report with phpunit, and second doing something with the report.

Note: xdebug has to be running for this to work. xdebug slows everything down, so I save the xdebug.ini file, remove xdebug, then just before phpunit, I add the xdebug.ini back in.

For generating the report, I:

• Create a directory to hold the logs
• Inject XML in phpunit.xml telling phpunit to enable logging (this is optional, there is a command line option for phpunit that could be used)
• Inject XML in phpunit.xml that tells phpunit what code files to include and exclude. This is required for phpunit to work with code coverage on. We should be able to include the plugin folder, and exclude the lang dir, but it would be good if there would be a way for a plugin dev to put commands in their travis to manipulate the include/exclude

There are many formats for coverage reports. I used clover coverage xml file because of the next step that I used, but there are various formats, including a set of html pages that phpunit can make.

The problem is that now the report is on a temp travis machine, so we need to ship it off somewhere. I choose to use coveralls.io, which has a web service that receives the data and makes pretty graphs and badges and history. That being said, we just need to ship the reports somewhere (anywhere).

I used the composer project satooshi/php-coveralls. I also need to do some tickery because of our directory structure. So after a successful run, I:

• Install php-coveralls
• I make a .coveralls.yml file for php-coveralls. There are some command line flags that should make it possible to not do this, but they seem to be buggy.
• cd into the plugin directory
• Execute coveralls

I'm starting a Moodle plugin integration with instant messaging tools, I'm doing well step by step, in order to understand the workings of this new route Travis integration tool.

But when I started pernalizar the configuration file passed to receive the error message:

 3/5 [================>-----------]  60% 6 secs [Install mod_instantcontrol]PHP Fatal error:  Class 'core_component' not found in /home/travis/build/ci/src/Bridge/Moodle.php on line 93
Fatal error: Class 'core_component' not found in /home/travis/build/ci/src/Bridge/Moodle.php on line 93

My Travis file is:

language: php

sudo: false

cache:
  directories:
    - $HOME/.composer/cache

php:
 - 5.5

env:
 global:
  - MOODLE_BRANCH=MOODLE_22_STABLE
 matrix:
  - DB=mysqli

before_install:
  - phpenv config-rm xdebug.ini
  - cd ../..
  - composer selfupdate
  - composer create-project -n --no-dev moodlerooms/moodle-plugin-ci ci ^1
  - export PATH="$(cd ci/bin; pwd):$(cd ci/vendor/bin; pwd):$PATH"

install:
  - moodle-plugin-ci install

script:
  - moodle-plugin-ci phplint
  - moodle-plugin-ci phpcpd
  - moodle-plugin-ci phpmd
  - moodle-plugin-ci codechecker
  - moodle-plugin-ci csslint
  - moodle-plugin-ci shifter
  - moodle-plugin-ci jshint
  - moodle-plugin-ci validate
  - moodle-plugin-ci phpunit
  - moodle-plugin-ci behat

Below is the window with the full message.

The link to my project, which inda is even an embryo, is this: https://github.com/LMSeXT/Moodle_Instant_Control

Thanks.

Unable to get shifter validation in travis. Is there something wrong with this? Or is it me?

https://travis-ci.org/MoodleFreak/moodle_mod_openwebinar/jobs/139252483

I'm not sure what is going on, but I'm hitting this:

$ moodle-plugin-ci install

 4/7 [================>-----------]  57% 9 secs [Install dependencies]

                                                                                                                                                                                                                                                                                                                      

  [Symfony\Component\Process\Exception\ProcessFailedException]                                                                                                                                                                                                                                                        

  The command "composer install --no-interaction --prefer-dist" failed.                                                                                                                                                                                                                                               

  Exit Code: 1(General error)                                                                                                                                                                                                                                                                                         

  Working directory: /home/travis/build/moodle                                                                                                                                                                                                                                                                        

  Output:                                                                                                                                                                                                                                                                                                             

  ================                                                                                                                                                                                                                                                                                                    

  Error Output:                                                                                                                                                                                                                                                                                                       

  ================                                                                                                                                                                                                                                                                                                    

  Loading composer repositories with package information                                                                                                                                                                                                                                                              

  Failed to clone the [email protected]:moodlehq/moodle-behat-extension.git repository, try running in interactive mode so that you can enter your GitHub credentials                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                      

    [RuntimeException]                                                                                                                                                                                                                                                                                                

    Failed to execute git clone --mirror '[email protected]:moodlehq/moodle-behat-extension.git' '/home/travis/.composer/cache/vcs/git-github.com-moodlehq-moodle-behat-extension.git/'                                                                                                                                  

                                                                                                                                                                                                                                                                                                                      

  install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...  

                                                                                                                                                                                                                                                                                                                      

install [--moodle MOODLE] [--data DATA] [--repo REPO] [--branch BRANCH] [--plugin PLUGIN] [--db-type DB-TYPE] [--db-user DB-USER] [--db-pass DB-PASS] [--db-name DB-NAME] [--db-host DB-HOST] [--not-paths NOT-PATHS] [--not-names NOT-NAMES] [--extra-plugins EXTRA-PLUGINS]

The command "moodle-plugin-ci install" failed and exited with 1 during .

Your build has been stopped.

Would that be that there are too many requests coming from Travis? Or is it the branch?

This particular failure happened on 2.7 and 2.8 with PHP 5.4, but I've noticed it happening with other combinations.

Full build: https://travis-ci.org/FMCorz/moodle-block_xp/builds/273875512

Code that is using https://phpunit.de/manual/current/en/appendixes.annotations.html#appendixes.annotations.expectedException requires atleast phpunit 5.2. Request you to update the dependency to atleast 5.2.*

We've been writing a Moodle plugin for a while now and one of our extension requires us to inherit from the class user_filter_number which unfortunately uses a camleCase naming scheme for one function (getOperators). Since we're deriving from that class and have to implement said function, the moodle plugin CI is always marking our builds as failed, due to this check not matching the coding guidelines.

I've spent a lot of time, trying to figure out how the code checker works with moodle-plugin-ci and whether there is a way to ignore one specific function or check, but so far, I've not been able to find anything. Is there a way?

Currently in a situation where it would be desirable to run a plugin against unreleased development branches.

Ideally a repository URL could be specified in the configuration if it differs from 'git://github.com/moodle/moodle'. Loosening the validation on branch names if this custom URL is used would also be nice.

• Installing moodlehq/moodle-local_ci (1.0.2): Cloning 45db61329d
  45db61329db76a136dd8d9c6d1fa349035e663d9 is gone (history was rewritten?)

[RuntimeException]
Failed to execute git checkout '45db61329db76a136dd8d9c6d1fa349035e663d9' -- && git reset --hard '45db61329db76a136dd8d9c6d1fa349035e663d9' --
fatal: reference is not a tree: 45db61329db76a136dd8d9c6d1fa349035e663d9

Right now the phpunit execution uses the --testsuite option, using the main generated phpunit.xml file.

While that's ok for the majority of plugins... (_test.php files under component/tests) dir... it maybe insufficient for a number of cases:

• Plugins having subplugins (want everything to be executed together).
• Plugins having "tests" directories in non-standard places (for example, the codechecker has tests under the "moodle/tests" directory (every standard its own tests).

So basically this is about to switch from current approach to, recursively, look for any "tests" directory within the plugin and run any _test.php file within them.

This can be easily achieved by:

1. install phpunit with the --buildcomponentconfigs option. That creates a default phpunit.xml within all the components looking for any tests directory within it.
2. run phpunit with the --configuration option pointing to the plugin base directory, so the specialized phpunit.xml will be used and all tests will be run.

Not sure if this should be a general change of behavior or something to be supported by the phpunit "executor" via flag/option. For your consideration.

Ciao :-)

Just sharing thoughts on version 2 of this tool. Feel free to provide feedback or concerns. This will simmer for a while as I wont get to it anytime soon.

Due to changes in tooling for Moodle 3.2, I thought it was time to consider making a version 2 of this tool to support Moodle 3.2 or later. Reason for the version 2 is to avoid a potentially confusing and buggy code base filled with version switches. In addition, the available commands would get confusing as they would start to become Moodle version specific. So, opting for the route that will provide clarity, ease of use and ease of maintenance.

So, version 1 of this tool would remain to support Moodle 2.7 to 3.1 and likely will not receive much attention in the way of new features. Moodle 3.1 is a LTS release, so hopefully that doesn't come back to haunt me.

Version 2 would have these high level changes:

• Remove jshint command, no replacement, instead encourage usage of AMD modules.
• Remove shifter command, replaced by new grunt command
• Remove csslint command, replaced by new grunt command
• Add a grunt command. The usage would be moodle-plugin-ci grunt task1 task2 etc. We could also default it to appropriate tasks based on files in the plugin. This would wrap known tasks with extra functionality, like build directory validation for YUI and AMD modules. Would also support running tasks if your plugin has a Gruntfile.js.
• Modify the codechecker command to only process PHP files.
• Add Mustache lint: https://github.com/moodlehq/moodle-local_ci/tree/master/mustache_lint
  • Makes sure the template is parsable.
  • Makes sure the example context (custome moodle thing) is valid json and present (for the template library purposes).
  • Then if has example context, it runs html validator on it.
  • ESLint is run on the JS in the template.
  • Might be able to just pull down local_ci and run this: https://github.com/moodlehq/moodle-local_ci/blob/master/mustache_lint/mustache_lint.php#L40
• Upgrade save points might be a good add: https://github.com/moodlehq/moodle-local_ci/tree/master/tests/fixtures/check_upgrade_savepoints
• Let's add https://github.com/wimg/PHPCompatibility to code sniffer and use --runtime-set testVersion CURRENT_PHP_VERSION

I've run into an admittedly unlikely problem in which the default installation path of moodle causes a conflict in my GitLab CI environment. Our internal Moodle projects are all in a "moodle" group, which means builds are cloned to /builds/moodle/<name of project>/. This means the moodle directory isn't empty when the installer runs, so the build fails. Being able to set an environment variable for the installation path gets around this issue.

Hi Mark,
I am quite new to the TravisCI thing and I've got some problems with fully coping the mustache tests.

My current issues:

• I've got this warning: https://travis-ci.org/moodleuulm/moodle-theme_boost_campus/jobs/248291912#L489
  However, within the colums2.mustache file there is no role="banner" declared:
  https://github.com/moodleuulm/moodle-theme_boost_campus/blob/master/templates/columns2.mustache.
  Furthermore this is role="banner" is Core basis.
  So I do not know how to handle this warning.
• If there are warnings I cannot solve within the plugin I would need to be able to comment them out. Unfortunately I don't know the basis for the tests (eslint??) so I could find the needed commands.

Maybe you can help me?

Kind regards, Kathrin

We want plugins to install cleanly without PHP notices/warnings and without Moodle debugging messages. If either of these happens, the Travis CI build should fail.

This could help MDL-51187.

Hi @mrmark

I am opening https://tracker.moodle.org/browse/MDL-60330 - I'd appreciate any feedback I can get.

Is it hard to to use custom rules to the checker? I'd like to put some pressure in prettier code in my plugins and the only actually code changes needed would be in tools, possible mostly on this plugin.

ps I mentioned this plugin in Moodle Moodle Australia 2017 as an awesome tool for TDD.

It seems redundant for PHP_CodeSniffer to check .js files since JSHint has that covered, I'm also unclear where the JS rules are defined for phpcs, I think they may just be PHP_CodeSniffer builtin rules? Or the subset of the PHP rules that don't bail out on seeing unfamiliar code?

Hi Mark,

More of a question... how can I pass options to PHPCPD in the .travis.yml file please, like:

  - moodle-plugin-ci phpcpd --exclude /home/travis/build/moodle/theme/shoelace/classes/output/core_renderer_maintenance.php

as I get:

0.09s$ moodle-plugin-ci phpcpd --exclude /home/travis/build/moodle/theme/shoelace/classes/output/core_renderer_maintenance.php

  [RuntimeException]                      
  The "--exclude" option does not exist.  

phpcpd [<plugin>]
The command "moodle-plugin-ci phpcpd --exclude /home/travis/build/moodle/theme/shoelace/classes/output/core_renderer_maintenance.php" exited with 1.

Cheers,

Gareth

The commit adds a PHPUnit testcase with a static method like

public static function setUpBeforeClass() {
    // ...
}

This is part of PHPunit API - https://phpunit.de/manual/current/en/fixtures.html

This leads to thrown codechecker error:

Public method name "foo_bar_testcase::setUpBeforeClass" must be in lower-case letters only.

I believe that the cibot prechecker running at tracker.moodle.org does not raise this so there might be a way to achieve the same behaviour.

This is a new project to which I've just added Behat tests, but selenium doesn't start: https://travis-ci.org/mackensen/moodle-tool_coursedates/builds/255679371. Here's the raw output:

$ moodle-plugin-ci behat
 RUN  Behat features for tool_coursedates
Running single behat site:
Moodle 3.2.4+ (Build: 20170714), bc60c1a2eb8bc21d78494faf1b9bda0e7042ad7f
Php: 5.6.24, pgsql: 9.3.17, OS: Linux 4.8.12-040812-generic x86_64
Server OS "Linux", Browser: "firefox"
Started at 20-07-2017, 22:28
Selenium server is not running, you need to start it to run tests that involve Javascript. More info in http://docs.moodle.org/dev/Acceptance_testing#Running_tests

Talking about awesomeness, I saw while working in the codechecker integration that code-coverage had been added. So, temporally, I switched to dev-master and started playing with it.

It worked great out of the box, just generate the coverage report, upload it and done.

But I faced a problem that, while I assume it's not a real problem for the vast majority of plugins... i think it can affect some. Here it is:

the local_codechecker does contain some external "libraries" (/pear and /PHPCompatibility) and I excluded them by using the thirdpartylibs.xml definition. Perfect so far.

Then, there is the /moodle directory, where the standard (ruleset and own sniffs) are. Those sniffs are written following the phpcs own standard, not moodle one... so in my .travis.yml file I added:

IGNORE_PATHS=moodle/tests/fixtures,moodle/Sniffs

and done. Perfect!

But now, those ignore paths are somehow also used by phpunit/code coverage and it causes the moodle sniffs not to appear as covered, when surely are the most covered in the plugin.

Then, I tried a number of combinations, to see if I could define the ignore paths individually, moving it to before_install (from env) and exporting it, moving it to the script section. adding them to every line before calling to moodle-plugin-ci... and all my attempts ended without success, with the moodle/Sniffs directory being completely ignored.

I looked for examples out there but have failed to find any way to change those environment values. So this is just to know:

1. if there is any way to specify different ignore_paths by moodle-plugin-ci invocation. Looking to source code i was not able to imagine why my exports were not working to be honest, maybe I'm missing something obvious.
2. if not, ask for it. I'm sure there is a valid use case for that, not only in the codechecker, that I agree is a non-standard plugin, but potentially in others.

Ciao :-)

Behat 3 has been recently added for 3.1 (current master) and up, so I bet that all jobs working against that branch will start to fail because the (used) --ansi option has been changed to --colors.

Not sure if solution is to just get rid of it or, alternatively, based on MOODLE_BRANCH or on composer's behat-extension version (1.x vs 3.x), proceed with one option or the other.

You can see all the master jobs failing (apart from other things to fix, it's wip, eh!) @ https://travis-ci.org/stronk7/moodle-local_codechecker/builds/117060405 . Older branches are running it ok.

Hi Mark,

One of my builds just failed when it did not before at this stage with this:

Nothing has changed at my end. I think something has changed at TravisCI but I'm not sure.

Kind regards,

Gareth

Hi Mark,

this is a more severe case, related to this discussion :
https://moodle.org/mod/forum/discuss.php?d=341765

We often in a plugin set have plugins that need each other. Moodle allows circular dependencies to be defined and install components properly. (this may lead to other issues when wanting to uninstall but this is another topic)

the travis-ci setup with plugin-ci breaks on such cross loading.

The rules in csslint are generally good, but some aren't appropriate for Moodle for various reasons (e.g. they assume they're operating on an entire sites CSS, rather than just one part of it) . Adding the following to the command line will leave only the more actionable recommendations.

--ignore=adjoining-classes,box-sizing,box-model,overqualified-elements,bulletproof-font-face,compatible-vendor-prefixes,selector-max-approaching,fallback-colors,floats,ids,qualified-headings,selector-max

You can see on this log that the pdepend library that phpmd uses is throwing errors to do with undefined constants on PHP7:

https://travis-ci.org/danmarsden/moodle-plagiarism_urkund/jobs/91730002

This is the upstream bug, which seems to have been fixed and released already:

pdepend/pdepend#213

Not clear if it's made it's way to PHPMD or not yet

Suggestion:

• Error if definition is missing
• Warn if it is not a major version

Could be related to: https://tracker.moodle.org/browse/MDL-59562

Hi,

I am just in the process of integrating your very helpful moodle-plugin-ci framework into our set of Moodle plugins.

Getting started was just a matter of minutes, now I am in the process of refining the build process according to our needs.

One major thing which gives me a headache is the moodle-plugin-ci validate step. I am aware that moodle-plugin-ci uses local_codechecker and even if we will do our best to adapt our existing code to make local_codechecker happy, for some pieces of existing code errors or warnings can't be avoided without making the code more ugly or more complicated than before. We could argue if the plugin developer or the local_codechecker rules are to blame, but at the moment my only question is:

Is there a way to have the codechecker step run during the build, to have it output errors and warnings in the Travis build log (just like I would see them if I run local_codechecker locally), but to have it fail gracefully, i.e. to make sure that codechecker warnings and errors don't let the whole Travis build fail?

PS: I am also aware that I could add some PHP_CodeSniffer syntax to the affected code lines to have local_codechecker ignore it, but for the same reasons as described above I don't want to make the code more ugly than necessary.

Thanks in advance,
Alex

But this variable and it's underscores are part of PHP core: http://php.net/manual/en/reserved.variables.httpresponseheader.php

Is there any way to configure travis to ignore rules?

Hi Mark,

I have some PHPUnit tests for the Essential theme which set values in the database. Using PHPUnit with the script gives: https://travis-ci.org/gjb2048/moodle-theme_essential/jobs/98341673#L336-L350 - however when I run locally its fine. Therefore the Database has not been set-up by the script. I tried and failed to use the bits from Moodle 3.0's .travis.yml (https://github.com/moodle/moodle/blob/MOODLE_30_STABLE/.travis.yml#L69-L138) file to establish a DB for PHPUnit to use but that only caused Travis to baulk at the configuration in .travis.yml.

I did try a '../../' path altering for the config.php file in the script but no joy.

Essential Unit test file refs: https://github.com/gjb2048/moodle-theme_essential/blob/MOODLE_29/tests/toolbox_test.php#L36-L47 and https://github.com/gjb2048/moodle-theme_essential/blob/MOODLE_29/tests/toolbox_test.php#L86-L105

As you mentioned in #7 about passing in options I thought that something might need to change.

Cheers,

Gareth

First, thank you very much for creating this. Really, really helpful. I can't believe I have only just tried this for the first time.

However, I seems it is not applying the right coding style rules. https://travis-ci.org/moodleou/moodle-qtype_oumultiresponse/jobs/117755581 complains

Expected 1 space after "/"; newline found

referring to https://github.com/moodleou/moodle-qtype_oumultiresponse/blob/master/questiontype.php#L254. However, that is a perfectly acceptable place to wrap a line of code in Moodle. Apologies if this is actually a CodeChecker issue like https://tracker.moodle.org/browse/CONTRIB-6146.

block validation seems to require :myaddinstance but not all blocks can be added to the dashboard and this capablity is not relevant.

https://github.com/moodlerooms/moodle-plugin-ci/blob/42bff65dfd13d603c1bb17ddde8f33ae6ffb39e3/src/PluginValidate/Requirements/BlockRequirements.php#L51

core block example: block_activity_modules,
3rd party example: block_attendance

For some reason travis-ci is failing when trying to add an activity with PHP 5.6 - lines like this:
Xpath matching locator "//li[@id='section-1']/descendant::div[contains(concat(' ', normalize-space(@Class) , ' '), ' section-modchooser ')]/span/a" not found.

examples:
https://travis-ci.org/danmarsden/moodle-plagiarism_urkund/jobs/171866485#L441
https://travis-ci.org/danmarsden/moodle-mod_attendance/jobs/176850904#L530

running that test locally on a php 5.6 works fine. - running it with PHP 7 on travis also works fine.

Has anyone else run into this or found a way around it?

Currently running it looks like this:

phpcbf --standard=$HOME/vagrant/www/moodle-plugin-ci/vendor/moodlerooms/moodle-coding-standard/moodle .

We have two options:

1. Create a wrapper command in moodle-plugin-ci that calls phpcs nicely.
2. Somehow add the Moodle coding standard to CodeSniffer's config so you just do phpcbf --standard=moodle /path/to/files/to/fix

I'm thinking the prior would be more user friendly and be less problematic (EG: running it in multiple environments like host vs vagrant).

When running the Moodle Code Checker, I get the message "The use of function error_log() is forbidden". in response to this line.

Why is error_log forbidden? Is there a recommended alternative approach? I don't see anything about this in the Moodle coding style guidelines or the documentation for this plugin.

See https://travis-ci.org/WatershedLRS/moodle-report_watershed

See: https://travis-ci.org/gjb2048/moodle-theme_essential/jobs/224771406 whereby '3.3beta (Build: 20170421)' seems to have upped the Postgress DB version requirement: https://github.com/moodle/moodle/blob/master/admin/environment.xml#L1917.

The coding paradigm you have used is clearly incompatbel with my brain. I find it almost impossible to work out what any given command does.

Therefore, please may I suggest you add the following docs:

• A summary of the folder structure that is created. As far as I can work out, it is all under /home/travis/build/, and the key plugin being tested gets cloned into a sub-path like timhunt/moodle-qtype_coderunner matching the github repo. But, I am currently failing to work out what paths are use for moodle's dirroot and dataroot.

• An overview of the code. E.g. how do I find the code that runs for command moodle-plugin-ci ...? How to I find the configuration values that control that command, like the paths I ask for above?

I have a sub-plugin for the mod_engagement plugin (engagementindicator) - I've added the install of the mod_engagement plugin before the install of my plugin but then when it installs my plugin it fails because it doesn't recognise the plugin type - mod_engagment has a db/subplugins.php file which appears correct but it doesn't get picked up?
Here's the error I get:
https://travis-ci.org/danmarsden/moodle-engagementindicator_attendance/jobs/128007114#L252

Anyone have any ideas on how this might work? - or am I missing something else?

Hi Mark,

Code checker module now failing since around 17:40 GMT 28/1/2016, I don't know if its you or them. Two repositories failing with the same thing:

$ moodle-plugin-ci codechecker
 RUN  Moodle Code Checker on theme_essential
...........PHP Notice:  Undefined offset: 23 in /home/travis/build/ci/vendor/squizlabs/php_codesniffer/CodeSniffer/Tokenizers/PHP.php on line 1000
PHP Stack trace:
PHP   1. {main}() /home/travis/build/ci/bin/moodle-plugin-ci:0
PHP   2. Symfony\Component\Console\Application->run() /home/travis/build/ci/bin/moodle-plugin-ci:68
PHP   3. Symfony\Component\Console\Application->doRun() /home/travis/build/ci/vendor/symfony/console/Application.php:123
PHP   4. Symfony\Component\Console\Application->doRunCommand() /home/travis/build/ci/vendor/symfony/console/Application.php:192
PHP   5. Symfony\Component\Console\Command\Command->run() /home/travis/build/ci/vendor/symfony/console/Application.php:844
PHP   6. Moodlerooms\MoodlePluginCI\Command\CodeCheckerCommand->execute() /home/travis/build/ci/vendor/symfony/console/Command/Command.php:259
PHP   7. PHP_CodeSniffer->process() /home/travis/build/ci/src/Command/CodeCheckerCommand.php:88
PHP   8. PHP_CodeSniffer->processFiles() /home/travis/build/ci/vendor/squizlabs/php_codesniffer/CodeSniffer.php:496
PHP   9. PHP_CodeSniffer->processFile() /home/travis/build/ci/vendor/squizlabs/php_codesniffer/CodeSniffer.php:619
PHP  10. PHP_CodeSniffer->_processFile() /home/travis/build/ci/vendor/squizlabs/php_codesniffer/CodeSniffer.php:1714
PHP  11. PHP_CodeSniffer_File->start() /home/travis/build/ci/vendor/squizlabs/php_codesniffer/CodeSniffer.php:1836
PHP  12. moodle_Sniffs_PHP_CommentedOutCodeSniff->process() /home/travis/build/ci/vendor/squizlabs/php_codesniffer/CodeSniffer/File.php:567
PHP  13. PHP_CodeSniffer_File::tokenizeString() /home/travis/build/ci/vendor/moodlerooms/moodle-coding-standard/moodle/Sniffs/PHP/CommentedOutCodeSniff.php:105
PHP  14. PHP_CodeSniffer_Tokenizers_PHP->processAdditional() /home/travis/build/ci/vendor/squizlabs/php_codesniffer/CodeSniffer/File.php:1447

Cheers,

Gareth

Hi,

I currently face the problem that themes can override Behat step definitions, resulting in failing acceptance tests in Moodle 3.2 on Boost (for a piece of software that is actually working fine).

It would therefore be great if the behat task would allow me to specify a theme that is used for execution. Moodle provides this since version 3.2, either by --suite (https://docs.moodle.org/dev/Running_acceptance_test#Running_behat_with_specified_theme_.28Since_Moodle_3.2.29) or init.php -a (https://docs.moodle.org/dev/Running_acceptance_test#Step_1:_Initialise_acceptance_test_environment) – I have yet to find out which one would work best here.

Maybe the behat task could be extended by a --theme option that could then be passed on?

Thanks!

From one build to the other, Travis CI suddenly from one commit to the other doesn't recognize when a build finishes and just waits 10min till the timeout kicks in.

Here are two logs. The first one errored normally and the second one fails by timing out.
https://travis-ci.org/eXpl0it3r/moodle-mod_studentquiz/jobs/172858581
https://travis-ci.org/eXpl0it3r/moodle-mod_studentquiz/jobs/176369958

And here's a diff of the log, but it has a few "false-positives" due to odd output formatting.
https://www.diffchecker.com/xNvmTiun

Also note that other projects still build fine for me, so I'm rather confused why this one suddenly stopped working. Maybe this is a Travis CI issue, but so far I can't make out what is going wrong.

Link out to https://gist.github.com/Dagefoerde/b8ebf54438b8a77ee4ea73f552fc0a01

Hi Mark,

My IGNORE_PATHS directive is not being processed and now the builds are failing: https://travis-ci.org/gjb2048/moodle-theme_shoehorn/jobs/129531777.

I have not changed anything in the Travis config and everything was fine two days ago.

Kind regards,

Gareth

It would be great if plugin authors could run their unit/behat tests against all supported DB drivers with moodle-plugin-ci.

With https://github.com/moodlehq/moodle-docker it is quite straight forward to do this in the travis environment. I have created an example travis file to show how you can achieve this with a simple mod_workshop example. (Results)

Unfortunately I am not able to work on fitting this into the moodle-plugin-ci infrastructure, but I think it would be a really great addition to improve cross-db compatability across plugins.

https://github.com/danpoltawski/moodle/blob/travis-plugin-test/.travis.yml
https://travis-ci.org/danpoltawski/moodle/builds/277265066

It would be cool to have coverage for PHPDoc compatibility, perhaps leveraging local_moodlecheck.

It seems that (at least in v2), code coverage exclusions are not working in Moodle 3.3 and master.

I'm doing something like:

env:
 global:
  - PHPUNIT_IGNORE_PATHS=cli,db,settings.php,version.php

 matrix:
    # Moodle Master
  - PHPVER=7.0 DB=pgsql MOODLE_BRANCH=master
...
    # Moodle 3.2
  - PHPVER=5.6 DB=pgsql MOODLE_BRANCH=MOODLE_32_STABLE
...
    # Moodle 3.3
  - PHPVER=5.6 DB=mysqli MOODLE_BRANCH=MOODLE_33_STABLE
...

before_install:
...
  - composer create-project -n --no-dev --prefer-dist moodlerooms/moodle-plugin-ci ci ^2
...

install:
  - moodle-plugin-ci install

script:
...
  - moodle-plugin-ci phpunit --coverage-clover
...

after_script:
  - moodle-plugin-ci coveralls-upload
...

And only in MOODLE_32_STABLE runs are the PHPUNIT_IGNORE_PATHS files excluded.

I would assume it has to do with changes made in https://tracker.moodle.org/browse/MDL-55139

GitLab CI uses a .gitlab-ci.yml file similar to the .travis.yml file to run continuous integration jobs.
As GitLab is free and open-source, it would be good to support it too even most developers do not use it yet for most public work, GitLab may be installed inside your organization to host your private projects.
Here the documentation about the .gitlab-ci.yml file:
http://doc.gitlab.com/ce/ci/yaml/README.html