-
-
Save josephdpurcell/1c78367cedc15a075e4231a5a685ced9 to your computer and use it in GitHub Desktop.
# This file customizes the steps that DrupalCI will use when testing this project. | |
# | |
# The primary customization provided here is to check for deprecation errors. It is recommended | |
# to do this only when you've used https://github.com/mglaman/drupal-check/ to verify any | |
# existing deprecation errors are addressed. | |
# | |
# Learn to make one for your own drupal.org project: | |
# https://www.drupal.org/drupalorg/docs/drupal-ci/customizing-drupalci-testing | |
build: | |
assessment: | |
validate_codebase: | |
phplint: | |
container_composer: | |
phpcs: | |
# phpcs will use core's specified version of Coder. | |
sniff-all-files: true | |
halt-on-fail: false | |
testing: | |
# run_tests task is executed several times in order of performance speeds. | |
# halt-on-fail can be set on the run_tests tasks in order to fail fast. | |
# suppress-deprecations is false in order to be alerted to usages of | |
# deprecated code. | |
run_tests.standard: | |
types: 'Simpletest,PHPUnit-Unit,PHPUnit-Kernel,PHPUnit-Functional' | |
testgroups: '--all' | |
suppress-deprecations: false | |
run_tests.js: | |
types: 'PHPUnit-FunctionalJavascript' | |
testgroups: '--all' | |
suppress-deprecations: false | |
nightwatchjs: { } |
Two suggested changes, captured here https://gist.github.com/webchick/828d5cbb2f306e4a5e7121241a7e5175 (not married to any of this wording).
- Update the gist description to include some context / "why" are we asking you to do this.
- Add a comment to the top of the file that explains what this file is for.
I think this will be many module authors' first introduction to drupalci.yml (it certainly was mine!) so if we're planning to mass-produce patches against passing modules, we should take care to help bring maintainers up to speed.
Update the gist description to include some context / "why" are we asking you to do this.
Here's a stab.
Adding this custom DrupalCI configuration will fail tests when your project uses deprecated code to raise awareness of any compatibility issue with Drupal 9 or greater.
Does suppressing deprecations fail the build or is it soft? I can see an issue with wanting to maintain compatibility with current Drupal 8 releases that only have the deprecated code (ConfigurableInterface being a notable example that will break if used now on 8.6 sites).
# This file customizes the steps that DrupalCI will use when testing ths project.
This made sense to me, @webchick. And I didn't even notice the typo ths
until I pasted it in here and saw my spellchecker underline it!
Also, based on conversation in Slack, adding suppress-deprecations: false
to drupalci.yml files right is not encouraged. It takes a lot of system resources and would run on every patch. So adding it to every contrib project would drastically increase the budget for testbots.
@heddn I don't think suppress-deprecations: false
is expensive. It's if you turn on the drupal-check implementation - i.e. you enable phpstan code checking.
I think the point made (by @goba) was that suddenly turning DrupalCI on for thousands of new projects (if we ask sprinters to add patches for the "known good" modules) would be the resource hog.
Thanks for this, looking to do this on the modules I'm maintaining and helping out with. Question came up after looking at core's file, seems like it's different?
https://git.drupalcode.org/project/drupal/blob/HEAD/core/drupalci.yml
For example, you have
run_tests.js
, whereas core hasrun_tests.javascript
Just wanted to clarify this since this is linked from https://pantheon.io/blog/your-module-ready-drupal-9-click-here-find-out and it'd probably be getting copy pasted it into patches for projects :)