Skip to content

Instantly share code, notes, and snippets.

@josephdpurcell
Last active October 1, 2019 11:19
Show Gist options
  • Save josephdpurcell/1c78367cedc15a075e4231a5a685ced9 to your computer and use it in GitHub Desktop.
Save josephdpurcell/1c78367cedc15a075e4231a5a685ced9 to your computer and use it in GitHub Desktop.
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 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: { }
@josephdpurcell
Copy link
Author

Note: the important part is:

 suppress-deprecations: false

@manuee
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?
https://git.drupalcode.org/project/drupal/blob/HEAD/core/drupalci.yml
For example, you have run_tests.js, whereas core has run_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 :)

@webchick
Copy link

Two suggested changes, captured here https://gist.github.com/webchick/828d5cbb2f306e4a5e7121241a7e5175 (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.

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

@mradcliffe
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!

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

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

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