Continuous forward compatibility checking of extensions for Drupal 12, 13, etc

We still keep improving the ecosystem readiness and tooling with each new major Drupal core version. Drupal 11 is to be released in a few weeks on the week of July 29 (so probably the first days of August) and already almost half of the top 200 modules are ready. But we need to keep thinking ahead.

The Project Update Bot (originally built by Ted Bowman at Acquia and since then very actively owned and improved by Björn Brala at SWIS) posted into more than 7600 project issue queues on Drupal.org with merge request suggestions to improve and in many cases solve compatibility with the upcoming major version. 

The bot is a clever combination of Upgrade Status and drupal-rector with some custom decision logic. So humans can also run those tools! But what if we automate it even more? What if we help pre-empt forwards incompatible code getting into modules in the first place? 

We already have CSS linting, JS linting, spell checking and various other code quality checking tools to help keep code quality with each change. Why not integrate Upgrade Status as well? What if you could get this kind of report in merge requests and scheduled jobs?

Image

What if you would even get inline feedback in a merge request about forward incompatible practices (already known at the time of the merge request)?

All right, this is not just an idea but a reality you can use today and it is a real Open Source success story I think!

First, Bart Langelaan from Popup Plus proposed with some initial code that we add Codeclimate JSON support to Upgrade Status, so it can be integrated into GitLab. It took me some rearchitecting the export formats and drush integration to make this cleanly integrate but we did it with the help of Kirill Roskolii from Catalyst.

Then I started an innocent Slack thread, which accumulated 134 replies. Moshe Weitzman from Tag1 Consulting helped kick us off. Once we had a working GitLab CI snippet, we started discussing the idea of building integration into the Drupal.org GitLab CI templates themselves. This was actively picked up and refined by Björn Brala at SWIS, Fran Garcia-Linares at the Drupal Association and Jonathan Smith.

Tada! The result is Upgrade Status checking with integrated native GitLab CI integration is now built into the Drupal.org templates. You can take advantage of this by enabling the optional job in your .gitlab-ci.yml

variables:
  RUN_JOB_UPGRADE_STATUS: '1'

Using this would get you a front row seat in forwards compatibility. Your future contributors would get feedback on whether their added code is compatible with the next major version of Drupal core. This could greatly reduce the gap of contributed modules being ready for upcoming major versions of Drupal core.

Beyond all the fantastic people listed above (and the ones I forgot to mention, sorry!), this is thanks to the extensible and versatile GitLab CI system Drupal.org is now using exclusively for contributed projects.

How does this compare to running tests on the next major version?

How does this compare to the also very useful OPT_IN_TEST_NEXT_MAJOR variable? That will run tests using the next major version of Drupal and fail in case of incompatibilities. There are a few differences:

Ideally you would use RUN_JOB_UPGRADE_STATUS to keep your codebase forward compatible and OPT_IN_TEST_NEXT_MAJOR once the next major version branch is close enough to release, to prove that your tests also pass on the next major version.