Update Composer Stager to 2.0-rc2 to fix failing build tests

Failed asserting that 'Composer version 2.7.4 2024-04-22 21:17:03' contains
"for debug".

I put a debug assert just to see if the Composer version was the problem but this is the same version I have locally and it passes.

More debugging on gitlabci because I can't get it to fail locally

1. I tested running the composer command to update the module in \Drupal\Tests\package_manager\Build\PackageUpdateTest::testPackageUpdate on the active codebase using runComposer() to see if that would update correctly and it did. Want to be sure it was not something with how the repo was set up and it was not aware of the new version of the module
2. Now I am testing whether the module was actually update in the stage. Trying to determine if the staged update happened correctly and it just not copy back correctly. If this is the problem could it be a different version of rsync on gitlab ci?

So for some \Drupal\Tests\package_manager\Build\PackageUpdateTest::testPackageUpdate failing because the update is not happening on the active codebase all though we get no errors before this assertion.

What seems to be happening is the module is updated in the stage but it is not getting copied back to the active.

This just seemed to start failing without a related commit.

ok things I have tried.

1. Check to see if runComposer() directly in the test would update the package, it does
2. Checking to see if the module actually gets updated in the stage, it does. But the active code does not reflect the update
3. making sure there is not new version of rsync being using, There is not gitlabci is using 3.2.3
4. Check in \Drupal\package_manager\StageBase::apply if the committer has errorOutput even though it does not through and exception
5. Increase the timeout in \Drupal\package_manager_test_api\ApiController::createAndApplyStage sent to \Drupal\package_manager\StageBase::apply and then on to Composer Stager.
6. Reverted back Composer-Stager 2-beta5
7. Check if the composer version on gitlab CI different than my local. It is not but also don't think this would be the issue because I confirm the composer require is working in the stage
8. Move
   

   // The post-apply event subscriber in updated_module 1.1.0 should have
       // created this file.
       // @see \Drupal\updated_module\PostApplySubscriber::postApply()
       $this->assertSame('Bravo!', file_get_contents($this->getWorkspaceDirectory() . '/project/bravo.txt'));

   up in the test to confirm the event was fired

9. Return string(now array from \Drupal\package_manager_test_api\ApiController::finish) so even if we get a 200 response code we know it is from the expected location

PackageInstallTest passes. So for some reason on apply() new code gets moved over to the active site but update code does not. The both rely on composer require

unrelated, just need to upload a logo 🙈

phenaproxima → closed merge request !1066

I merged !1066 manually so that we can proceed with getting to the actual debugging, now that we're collecting rsync output on GitLab CI.

Now that we are logging rsync output and collecting it in our CI artifacts, we can see why this is happening.

This is rsync's only output during the commit stage:

building file list ... done
./
composer.json
composer.lock
vendor/
vendor/composer/autoload_classmap.php
vendor/composer/autoload_static.php
vendor/composer/installed.json
vendor/composer/installed.php
vendor/phpstan/extension-installer/src/GeneratedConfig.php
web/autoload.php
web/modules/contrib/
web/modules/contrib/main_module/
web/modules/contrib/main_module/composer.json
web/modules/contrib/main_module/main_module.info.yml
web/modules/contrib/main_module/main_module_submodule/
web/modules/contrib/main_module/main_module_submodule/main_module_submodule.info.yml
web/sites/default/

updated_module didn't even get moved around!

Ted, Travis, and I spent some time working on this today. Indeed, rsync was not copying the files...because it doesn't think they changed. Why not? Because they are identical in size, and Symfony recently introduced a change into the Filesystem component which preserves the modification time on copy.

Although this is a bug that would occur exceptionally rarely in the wild, it could occur, and would be extremely hard to debug at that point. Therefore, to prevent it, we decided that it's best for rsync to use checksumming (the --checksum option) to determine if a file has changed. We did some light performance testing and, for our use case of copying many small files, the impact seems to be negligible.

So, Travis is adding that to Composer Stager and releasing rc2. We'll update to that, and thus fix the problem.

phenaproxima → credited TravisCarden → .

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