Fix php_version in Drupal 7 pipelines

The cause is actually unrelated to any GitLab templates changes, it is what the error message says - Composer 1 support was completely dropped at packages.drupal.org https://www.drupal.org/drupalorg/blog/ending-packagesdrupalorg-support-f... →

Any containers containing Composer 1, or D7 overrides reverting back to Composer 1 should be updated to Composer 2.

I was able to fix this in one project by updating the PHP Version from 5.6 to 8.1. I believe 5.6 must still have Composer 1 in the container, since it is ancient.

In this case, it looks like _D7_DRUPAL_COMPOSER_NEEDED: 1 is reverting to Composer 1 at https://git.drupalcode.org/project/scheduler/-/blob/7.x-1.x/.gitlab-ci.y...

Ah Thank you. Yes I just compared the logs in detail and can see before we had

Warning from https://packages.drupal.org/7: New Drupal.org packages & releases ARE NOT AVAILABLE FOR COMPOSER 1!!
Composer 1 support will be dropped after October 1, 2024. You should upgrade to Composer 2 now. 

and now it says

Warning from https://packages.drupal.org/7: Drupal.org packages ARE NO LONGER AVAILABLE FOR COMPOSER 1!!!
Composer 1 is NOT supported. You should upgrade to Composer 2 now! 

I saw the change we made to _TARGET_PHP and thought it could be related. I guess the packages change wasn't made exactly on 1 October, but sometime between then and today.

_D7_DRUPAL_COMPOSER_NEEDED was added for Drupal 7 contrib projects that have their own composer.jon, I can't recal the details right now, but clearly that's going to have to be revisited.

Let’s go with a D7-variable separate from the other ones if we need to have a specific version of php.

@fjgarlin I think you have probably replied from e-mail or on phone, and have not seen the update here by drumm. It's not a php version problem, but is caused by dropping Composer 1 support entirely.

Phone 🙂 yup i missed two comments (too slow to type)

It can wait until Monday :-)

For my scenario, the solution is really simple. I only set _D7_DRUPAL_COMPOSER_NEEDED=1 because doing this means that the modules required for testing are moved from $CI_PROJECT_DIR/vendor/drupal (where they are initially placed) to $CI_PROJECT_DIR/$_WEB_ROOT/sites/all/modules which is where Drupal 7 core expects them to be. But in switching to Composer 2 the modules are still downloaded just the same. So I think we need to do the move from vendor/drupal to sites/all/modules regardless of which composer version is being used.

I don't know specifically what other needs there was to use Composer version 1. The issue that added _D7_DRUPAL_COMPOSER_NEEDED was 🐛 D7 contrib pipeline tests fail when requiring a 3rd-party contrib module Fixed so we can check back to find out our reasoning and decision process from there.

First commit tested on Scheduler here
Since finding the probelms I have already committed a custom composer after_script to move these modules, so that is removed in the test.

We also need to give a message in the log and I think there is no point in reverting Composer to version 1 as that can't be used now. The message can refer users to this issue and ask for problems to be reported here.

Downstream pipeline: https://git.drupalcode.org/project/api/-/jobs/3046591
The D7 api project uses this scenario.

We have in the code the following

      if [ "$COMPOSER_VERSION" == "2" ]; then
        if [ "$_D7_DRUPAL_COMPOSER_NEEDED" == "1" ]; then
          # Revert to Composer version 1, see https://www.drupal.org/project/composer/issues/3178950
          echo "Composer 2 is installed, reverting to Composer 1 because _D7_DRUPAL_COMPOSER_NEEDED=$_D7_DRUPAL_COMPOSER_NEEDED"
          composer self-update --1
        else
          echo "Composer 2 is installed, setting allow-plugins"
          composer config --no-plugins allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
        fi
      fi

We will need to change it to NOT force composer 1.

I think we should also try to detect if we are on composer 1 (ie: very old image), and then try to force composer 2 coposer self-update --2 in that case.

For API module, we should go ahead and mark the D7 version unsupported and can forget about testing it.

I think it would be okay to not support very old images with composer 1 only. If someone is in that situation, hopefully they can use a new image, like I did for project_composer, or can do the self-update themselves by adding the command to their own .gitlab-ci.yml

I went ahead and marked 7.x-2.x unsupported. As long as we don't have other alternative for downstream project, we'll keep it there as it's useful to discover bugs in D7.

As for the composer 1 images, I guess these are linked to PHP 5.6 and I agree that we shouldn't need to worry about supporting that. We just need to clean up the code from the templates here that _forces_ composer 1. It will keep composer 2 and if it fails it fails.

Thanks for the feedback in #11 - 13, I will work on that.

Regarding the test failures in #10, those were unrelated to this MR, and caused me to raise 📌 Review D7 pipelines with D11 shift changes Active which is now fixed.

I've made the changes discussed above, (a) to remove the reverting to composer 1, and (b) update to composer 2 if one 1.

Basic test witht _D7_DRUPAL_COMPOSER_NEEDED=0
https://git.drupalcode.org/project/scheduler/-/jobs/3081121

As above but with _D7_DRUPAL_COMPOSER_NEEDED=1
https://git.drupalcode.org/project/scheduler/-/jobs/3081530

With _D7_DRUPAL_COMPOSER_NEEDED=1 and _TARGET_D7_PHP=5.6
https://git.drupalcode.org/project/scheduler/-/jobs/3085137

All works OK for Scheduler, but this module did not need drupal/composer, so will be good to see the downstream pipelines. Maybe I will try to search for other modules which had _D7_DRUPAL_COMPOSER_NEEDED: 1 and see if we can test on them too.

This is ready for review and feedback.

The code looks good and the tests above too. Downstream pipeline on the D7 project: https://git.drupalcode.org/issue/gitlab_templates-3480296/-/pipelines/31...

I needed to update the _TARGET_PHP and _TARGET_DB_VERSION on the D7 file. Running again: https://git.drupalcode.org/project/gitlab_templates/-/pipelines/313405

Merged. Thanks!

The API phpunit failed with

PHP Fatal error:  Cannot declare class Composer\Autoload\ClassLoader, because the name is already in use in /builds/project/api/vendor/drush/drush/commands/composer/vendor/composer/ClassLoader.php on line 43
Drush command terminated abnormally due to an unrecoverable error.   [error]
Error: Cannot declare class Composer\Autoload\ClassLoader, because
the name is already in use in
/builds/project/api/vendor/drush/drush/commands/composer/vendor/composer/ClassLoader.php,

I left in the move of vendor/drupal/composer to vendor/drush/drush/commands/composer
https://git.drupalcode.org/issue/gitlab_templates-3480296/-/blob/3480296...
But I guess that needs looking at too?

[edit - I see you have made another change since I wrote this comment, but leaving it here for reference]

That error is more of a warning and it has been there for a while. See this from August for example: https://git.drupalcode.org/project/api/-/jobs/2355569

So nothing that this change might have brought. As it is D7 API and things are running and we are no longer supporting that branch I've left it as it is.

OK, thanks for the info. So long as it was not caused by the changes I made then that's great.

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