Drupal 9 compatibility drupalci-.yml

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: {  }

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.