Problem/Motivation
ComposerProjectTemplatesTest is currently fails in HEAD when using the 7.4.x/7.3.x php containers.
This is due to the fact that the containers are built every day, and on Oct 28th, Composer 2 was released, thus upgrading those containers specifically.
If we build any new containers, HEAD will break.
Steps to reproduce
Run a core test using 7.4.x-dev or 7.3.x-dev php containers:
See https://www.drupal.org/pift-ci-job/1879647
Proposed resolution
The version of composer installed on the container should not be the one core tests rely on. We should change any invocations of 'composer' to ./vendor/bin/composer to ensure that we are using the version of composer that our dev dependencies specify for our tests.
We should open *another* followup to determine why our test fails in composer 2, or fix it as part of
https://www.drupal.org/project/drupal/issues/3128631
Remaining tasks
Write a patch
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3182188
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 #2
greg.1.anderson commentedYeah, this is a good idea. Currently it doesn't really matter if you use Composer 1 or Composer 2 cli in the tests, but it would be better to use the right one (Composer 1 on older versions of Drupal), and fixing this is just a PATH issue.
Comment #3
MixologicArgh. This might be complicated by the fact that our vendor cleanup script cleans up our bin dir for local composer...
Comment #4
andypostFor CI better to ship specific (preconfigured) version to prevent failures if composer download fail and skip buggy releases
+1 to use PATH for that, d-ci could set vendor/bin as priority
Comment #5
MixologicDrupal core has tests that test composer, and its own dependencies therein. Core should *not* use what ships with drupalci, it should only use what it downloads as part of composer install.
Comment #7
xjmComment #8
Mixologicignore the pass in 7.4
7.4 MR testing is broken right now. Thats my other critical.
Comment #9
MixologicFor now, I have pinned the container composer to composer 1 in the 7.3/7.4/8.x containers, so these tests will work again, but we need to upgrade them to use their own site local composer still so that we can use composer 2 on the testbots.
Comment #12
xjmDemoting to major since we implemented a workaround.
Comment #17
bradjones1Rebased. Ran into this because I was trying to replicate a test failure, but I mostly run my tests in a container which does not have composer in the PATH, and it's not present in the install. Not quite sure what the "right" thing to do here, though I understand/agree with all the trade-offs already discussed. Worked around it by running the test with the "local" php interpreter which has composer in its PATH, instead.