🇺🇸United States @tedbow

🎉

🙈

I think there could be problems if the log file is within the project route itself

We should open up another MR here to add the log file to the exclusions. I think if we don't on apply the previous version of the log file at the start of the stage would overwrite the one that has the latest entries

tim.plunkett → credited tedbow → .

tedbow → created an issue.

tedbow → created an issue.

@richardrobinson Thanks for working on this! Great start

Thanks @richardrobinson! Looks good🎉

tedbow → made their first commit to this issue’s fork.

tedbow → created an issue.

tedbow → created an issue.

This issue is more advanced the other issues tagged DrupalCon Portland 2024 → but someone is welcome to take it on. Definitely not something that will get done in day though(but please prove me wrong😜)

tedbow → created an issue.

tedbow → created an issue.

tedbow → created an issue.

unrelated, just need to upload a logo 🙈

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

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

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?

Removing "[PP-1] " not postponed as far as reviewing. ✨ Add Alpha level Experimental Package Manager module Needs review still needs to be committed first

Issue summary clean-up

1. Change 3.0.x to 3.1.x
2. Mention 🌱 [policy, no patch] Drop support for Windows in production Needs review as reason not support background updates on Windows

Added screenshots

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.

lauriii → credited tedbow → .

Pushing up the new conversion.

I do expect \Drupal\Tests\package_manager\Kernel\StageBaseTest::testDestroyDuringApply to fail. There is some serialization problem that is not happening the contrib module against 11.x. Not sure why

But I think it is still reviewable

Setting to Needs Review because the PR is passing and posted some responses to Catch's questions

tedbow → made their first commit to this issue’s fork.

Going to self RTBC based of #5, I merged 3.1.x

@phenaproxima thanks. RTBC assuming tests pass

I don't think we need to backport this to 3.0.x since the Sqlite version won't change in 10.x

Since other test issue will pass on 3.1.x and we don't have releases on 3.1.x I going to commit.

Assigning to @phenaproxima for review and clean up if needed.

tedbow → created an issue.

tedbow → created an issue.

tedbow → created an issue.

tedbow → created an issue.

tedbow → created an issue.

This will cause the build tests to skipped for now on the core converted version until we figure out a way to bump up the Sqlite version

I made a follow-up 📌 Bump up Sqlite version gitlabci to be able run build tests on core converted module Active

tedbow → created an issue.

tedbow → changed the visibility of the branch 3441577-core-mr to hidden.

tedbow → created an issue.

tedbow → created an issue.

@phenaproxima thanks!

Addressed @phenaproxima's review

Looks good #4 is correct the explanation of why this is only done on Windows in the comment for \Drupal\Core\File\FileSystemInterface::rmdir

looks good assuming tests pass. Only reason they won't if I can't tell how this affects other parts of parts of gitlabsci file

Looks good if tests pass. Thanks @phenaproxima

tedbow → changed the visibility of the branch 3439664- to hidden.

tedbow → created an issue.

I have pushed the latest changes. The build tests will still fail in this version. I will try figure that out. It is bit difficult to get them passing in both contrib version and core version as the gitlab templates are bit different but should be doable.

@lucian.ilea thanks for filing the issue.

I think there are few problems here

1. \Drupal\package_manager\Validator\ComposerPluginsValidator does not provide a link to a help section about how to allow other composer plugins. I think this is the problem that we should solve first.
2. We have an open issue to determine which and how new plugins should get approved 📌 Determine how new Composer plugins will be supported Active . This has considerations for Drupal core also. We don't allow just any plugins because they can affect files anywhere in your project so that makes staging Composer operations without copying the entire project folder impossible. It is not just a matter of whether the plugin does not conflict now but if we know that plugin will never conflict, at least within the composer version constraint we specify
3. The "scaffold files" problem should be handled in another issue. Also error message should have linked to this documentation page so it would be good place to start https://www.drupal.org/docs/develop/using-composer/using-drupals-compose... →

ckrina → credited tedbow → .

This doesn't need to go into 3.1.x because we not allow running as root then

I am going to commit this because it is just 4 lines and gets 3.1.x passing. I don't see other alternatives

@azizos thanks for the links to the github changes!

I just cleaned up some things and added some test coverage by making on of the packages added in \Drupal\Tests\automatic_updates_extensions\Functional\UpdaterFormTestBase::setUp you a package that does not match the project name. Allo the function tests using this now pass, so I am going to RTBC this

@phenaproxima pointed out we didn't make this a service 🤦🏼

Going to self RTBC this since I copied @phenaproxima's suggestion directly

@phenaproxima re

how do we account for dependencies being updated?

This validator is not concern with dependencies being updated. It only deals with the packages that directly request to be updated. This validator like the one in automatic_updates are really just fail safe in the case that Composer operation succeeded but for some reason the directly requested projects were not updated we should fail.

I added updates to other packages in the test to prove these are allowed.

tedbow → created an issue.

@phenaproxima thanks

tedbow → created an issue.

tedbow → created an issue.

Now that I see 📌 [PP-1] Update to Symfony 7.0 Postponed I realize that Composer Stager would have to be updated to Symfony 7. I made an issue for this https://github.com/php-tuf/composer-stager/issues/350

I assume there is no way Automatic Updates is going to get into Drupal 10.x at this point. Is that correct?

I am not sure how long the Composer Stager work will take. If it is going to take a while would it be useful for me to push up a version of this MR with the Package Manager module without Composer Stager as a dependency? All the tests would fail but it would still be latest code and could be reviewed.

Ok I will update with the latest changes from the contrib module

This could be reviewed. Would need the child issues committed first before we commit this though

Think tests should pass now