Skip to content

Instantly share code, notes, and snippets.

Last active October 1, 2019 11:19
What would you like to do?
Drupal 9 compatibility drupalci-.yml
# 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 to verify any
# existing deprecation errors are addressed.
# Learn to make one for your own project:
# phpcs will use core's specified version of Coder.
sniff-all-files: true
halt-on-fail: false
# 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.
types: 'Simpletest,PHPUnit-Unit,PHPUnit-Kernel,PHPUnit-Functional'
testgroups: '--all'
suppress-deprecations: false
types: 'PHPUnit-FunctionalJavascript'
testgroups: '--all'
suppress-deprecations: false
nightwatchjs: { }
Copy link

Note: the important part is:

 suppress-deprecations: false

Copy link

manuee commented Apr 8, 2019

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?
For example, you have run_tests.js, whereas core has run_tests.javascript

Just wanted to clarify this since this is linked from and it'd probably be getting copy pasted it into patches for projects :)

Copy link

Two suggested changes, captured here (not married to any of this wording).

  1. Update the gist description to include some context / "why" are we asking you to do this.
  2. 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.

Copy link

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).

Copy link

mradcliffe commented Apr 10, 2019

  # 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!

Copy link

heddn commented Apr 10, 2019

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.

Copy link

@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.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment