Problem/Motivation

This project declares core_version_requirement: ^10.4 || ^11 and has never been executed on Drupal 10. Not in CI, not on a site, not in a kernel run.

.gitlab-ci.yml opens by naming the problem — "This module declares ^10.4 || ^11, so the current core version is not the whole of what it claims to support" — and then opts into previous minor only, which is 11.3. Next major is deliberately excluded, with a measured reason recorded beside it. Previous major is not excluded; it is simply absent. So of the range the project page advertises, current is 11.4, previous minor is 11.3, and the entire 10.x half runs nowhere.

It is not a theoretical gap. content_credentials.module branches on \Drupal::VERSION around getOriginal(), because that method exists only from 11.2 while the property it replaces is removed in 12. Neither spelling covers the declared range alone, and the 10.4 branch has only ever been reasoned about.

Proposed resolution

Opt in, and make it actually run:

OPT_IN_TEST_PREVIOUS_MAJOR: 1
_AUTORUN_PREVIOUS_MAJOR: 'push'

Both halves are needed. OPT_IN_TEST_* only makes a variant exist; _AUTORUN_* decides whether it runs, and every non-current variant defaults to none, which leaves the composer job waiting for a human and the phpunit job reporting Skipped. That is exactly how the previous-minor opt-in sat decorative for weeks in this project before anyone noticed.

Unlike next major, this variant can resolve: drupal/ai_disclosure declares ^10.4 || ^11, and provemark/content-credentials requires PHP ^8.3, which Drupal 10.4 permits.

Remaining tasks

  1. Enable both variables.
  2. Read the result per job, not by pipeline status.
  3. If it is red, fix what it found. If it cannot be made green, narrowing the declared range to ^11 is the honest alternative — a project should not advertise support it does not test.

API changes

None.

Data model changes

None.

Comments

maurice1969 created an issue. See original summary.

  • maurice1969 committed 329b6f0e on main 
    Issue #3622764 by maurice1969: run the previous major, half the declared...

  • maurice1969 committed 329b6f0e on 1.0.x 
    Issue #3622764 by maurice1969: run the previous major, half the declared...

  • maurice1969 committed b389071d on main 
    Issue #3622764 by maurice1969: declare ^11, the range that is actually...

  • maurice1969 committed b389071d on 1.0.x 
    Issue #3622764 by maurice1969: declare ^11, the range that is actually...
maurice1969’s picture

maurice1969 commented
Status: Active » Fixed

Answered, and the answer was the alternative in the third remaining task. Fixed in b389071; the opt-in itself was 329b6f0.

What the variant reported

Pipeline 959015: composer (previous major) failed, with phpstan (previous major) and phpunit (previous major) skipped behind it. The variant did run rather than sitting Manual, so the two-variable opt-in was correct.

Why it cannot be made to pass

Not a constraint that can be loosened. The two core-dev packages require PHPUnit versions with no overlap:

  • Drupal 10.4 — phpunit/phpunit ^9.6.13
  • Drupal 11.4 — phpunit/phpunit ^11.5.50

PHPUnit 9 has no attributes, and every test in this project is written with #[Group(...)] and #[RunTestsInSeparateProcesses]. The previous-major runner uses whichever PHPUnit the site's core-dev brings, so that half of the declared range could not have been tested whatever the composer constraints said.

One step there is reasoned rather than measured, and the ADR says so: the job log could not be read — the section is collapsed and the raw endpoint is blocked — so the PHPUnit conflict was reproduced locally rather than lifted from the failing job. The incompatibility is measured; that it is the cause of that particular job failing is inference.

Decision

core_version_requirement is now ^11, and the previous-major opt-in is out again rather than left red on a public project page. Three options were weighed and the other two are recorded rather than dropped: carrying a suite that also runs under PHPUnit 9, which is honest but expensive and makes the tests worse to read; and leaving ^10.4 || ^11 declared and untested, which is the state this issue existed to end.

The cost is real and is named in the ADR: Drupal 10.4 and 10.6 sites cannot install this module, including sites whose ai_disclosure — which declares ^10.4 || ^11 — would allow it.

Widening again is a decision with a prerequisite rather than a config toggle: first decide to run the suite on PHPUnit 9.

Both pipelines green afterwards, nine jobs each, read per job: 959025 and 959026.

Marking fixed.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.