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

Command icon 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

Mixologic created an issue. See original summary.

greg.1.anderson’s picture

Yeah, 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.

Mixologic’s picture

Argh. This might be complicated by the fact that our vendor cleanup script cleans up our bin dir for local composer...

andypost’s picture

For 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

Mixologic’s picture

Drupal 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.

xjm’s picture

Priority: Normal » Critical
Mixologic’s picture

ignore the pass in 7.4

7.4 MR testing is broken right now. Thats my other critical.

Mixologic’s picture

For 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.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

xjm’s picture

Priority: Critical » Major

Demoting to major since we implemented a workaround.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

bradjones1 made their first commit to this issue’s fork.

bradjones1’s picture

Rebased. 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.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.