Problem/Motivation
To allow proper testing of the Drupal 11 compatibility issues and fixes the 'Next Major' PHPunit job needs some customisations. The Gitlab composer job already automatically updates a module's own composer.json to claim compatibility with Drupal 11, but many of the thrird-party dependency modules used in testing do not yet have a Drupal 11 release. We have used the _LENIENT_ALLOW_LIST to get these modules installed during the Composer job, but in the PHPunit job they cannot be enabled, and we get many errors of the Unable to install modules: module 'commerce_product' is incompatible with this version of Drupal core.
Proposed resolution
Create a secondary composer.json which has additional/alternative repositories for modules which do not have a D11 release. These will point to the D11 compatibility merge request branches.
| Comment | File | Size | Author |
|---|
Issue fork scheduler-3463494
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
jonathan1055 commentedThis will be tested and committed first, before the other D11 issues.
Credit to @vishalkhode for providing the alternative repo information from #3434325-28: Drupal 11 compatibility fixes [2.x]. Not all of it was used, I picked the minimum necessary.
Comment #6
jonathan1055 commentedThe PHPunit tests now run, which is the intention of this commit. None of the jobs pass yet, but that will be done in the other issues.
The additional
composer_next_major.jsonwill remain in the repo for testing, but may need review and adjustment in due course. The third-party modules will eventually have their own Drupal 11 release, and then that happens the additional vsc repos can be removed.Comment #7
jonathan1055 commentedThis was working, and the Next Major composer job was passing green. But one of the dependencies must have changed because now we get
Now that we are using this Next Major job properly, and relying on it in MRs to allow PHPstan and PHPunit to run, we need to make the job fail, so that the others do not run if it the dependencies can't be loaded. Otherwise we get misleading messages such as
in the PHPstan job, and
in PHPunit
Comment #10
jonathan1055 commentedThis avoids the problem of the pipeline status remaining as 'blocked' and never appearing to finish.
Comment #12
jonathan1055 commentedSummarizing and removing the excess messages, it seems to come down to:
Has this changed from before?
https://www.drupal.org/project/inline_entity_form
Comment #14
chandu7929 commentedYes, now the temp commit has been removed: https://git.drupalcode.org/project/commerce/-/merge_requests/279/diffs?c.... Hopefully, we will get the D11 fix for IFE soon.
Meanwhile, the VCS path can be used to unblock the D11 failure.
Comment #19
jonathan1055 commentedThanks for linking to that commit. Yes I saw there was activity on Commerce and IEF yesterday.
I have created a new MR158 trying to add the IEF vcs path like you suggested, but we now get the slightly different error:
Comment #20
jonathan1055 commentedWe need to override that latest Commerce commit that reverts back to
"drupal/inline_entity_form": "^1.0@RC || ^3.0@RC"I have now added a specifc commit, the one before the link you gave above. We need to use 279/diffs?commit_id=0f7a58fe15f7c810f683c01f2808c9e958f6c377
Comment #21
chandu7929 commentedThat's right, but you also have to provide repository with following changes:
Comment #22
jonathan1055 commentedYes, that is already in, from before:
3463494-inline-entity-form/composer_next_major.json#L21-24
The message we now get is
The first line shows that the previous commit is being targetted, as required. But then the second message just has
drupal/commerce dev-3462426-drupal-11-compatibilitywhich does not have the commit #, so it still thinks ^1 || ^3 and we get the error.Comment #23
chandu7929 commentedWe can try removing this line https://git.drupalcode.org/project/scheduler/-/merge_requests/158/diffs#...
Comment #24
jonathan1055 commentedMaybe, but I don't think that would help.
I have found this in the Composer docs https://getcomposer.org/doc/04-schema.md#package-links
The large warning box includes "the composer.json metadata will still be read from the branch name you specify before the hash". So whilst we would be getting the correct source for Commerce at that commit, the metadata still comes from HEAD of that branch (thus it ignores the commit that changed it). So in this case it is not going to be possible to do it.
I think we will have to wait for those issues to be progressed. Do you know why that temporary commit was removed, to go back to ^1 ||| ^3. That has really blocked our testing, and I think it will block other projects too.
#3462426: Drupal 11 compatibility fixes for commerce
#3438428: Automated Drupal 11 compatibility fixes for inline_entity_form
Comment #25
vishalkhode commented@jonathan1055 Maybe we should fake composer to treat our branch as the stable release. Let me try that, and see if it works.
Comment #26
chandu7929 commentedYes, I think @jsacksick has merge the commerce changes and waiting to IEF to be merge and release.
I am also following up on IEF D11 issue to get it merge and release so that it can unblock other dependent modules to run their D11 CI.
If it takes time then we can ask @jsacksick to put that comment back for the time being.
Comment #27
vishalkhode commentedIt worked and CI is passing now. Hence, requesting review.
Comment #28
chandu7929 commentedThanks Vishal, now D11 tests are failing:https://git.drupalcode.org/issue/scheduler-3463494/-/jobs/2223977
Comment #30
jonathan1055 commentedThank you @vishalkhode, I did not know about faking a repo to be named as another one, using 'as'. That's a great tip, and exactly what we need here.
Comment #31
jonathan1055 commentedI've created issues to fix the deprecation warnings in getSubscribedEvents() in two 3rd-party modules that Scheduler uses
entity
#3465393: Add 'array' return type in Drupal\entity\EventSubscriber\EntityDuplicateSubscriber
rules
#3465805: Add 'array' return type in Drupal\rules\EventSubscriber\GenericEventSubscriber
The MR repos can be added to composer_next_major.json to improve the testing at Next Major.
Comment #33
jonathan1055 commentedRules MR #3465805: Add 'array' return type in Drupal\rules\EventSubscriber\GenericEventSubscriber has been committed, so that change can be reverted to just use
"^4@dev"Comment #36
jonathan1055 commentedThis is now going to used for any D11 testing, not just 'next major', so amending the title.
Comment #40
jonathan1055 commentedBack-ported to 1.x branch just to see if that can also be compatible with Drupal 11. Need this info before making a 2.x release for D11.
https://git.drupalcode.org/project/scheduler/-/commit/63b7e0318d47976213...