[PP-1] Implement experimental cron updates for contrib in automatic_updates_extensions

This is already fairly big. And it's not yet done.

IMHO we should extract

@todo Implement a ReleaseChooser and VersionPolicy Validator.

into a separate issue. Based on @tedbow's comment at https://git.drupalcode.org/project/automatic_updates/-/merge_requests/84..., I see no reason why that would not be possible?

After this lands, we should tackle #3355620: [PP-1] Pave the path for contrib updates: automatically limit the staged updates to those modules without DB updates.

@omkar.podey asked me to look at this to figure out why tests are failing for him.

When I ran \Drupal\Tests\automatic_updates_extensions\Kernel\CronExtensionUpdateStageTest::testUpdateStageCalled, this is what I got:

TypeError : Double\EventDispatcherInterface\P1::dispatch(): Return value must be of type object, null returned

This makes absolute perfect sense. When routes are rebuilt, the event dispatcher is invoked by the routing system. That, as far as I know, is how routes are collected in the first place.

But, immediately before the test runs cron, it does this:

    // Since we're just trying to ensure that all of Package Manager's services
    // are called as expected, disable validation by replacing the event
    // dispatcher with a dummy version.
    $event_dispatcher = $this->prophesize(EventDispatcherInterface::class);
    $event_dispatcher->dispatch(Argument::type('object'))->willReturnArgument(0);
    $this->container->set('event_dispatcher', $event_dispatcher->reveal());

No wonder our fake event dispatcher here is not cutting the mustard -- the system expects the event dispatcher to be functional, but we just replaced it with a fake thing.

What we should probably do here is, rather than replace the event dispatcher entirely, we should simply disable all subscribers to Package Manager's events. It'll be a pain, but we could do it with \Symfony\Component\EventDispatcher\EventDispatcherInterface::getListeners and \Symfony\Component\EventDispatcher\EventDispatcherInterface::removeListener.

Discussed during a meeting just now. Next steps here:

1. Get tests to pass (PHPCS etc., plus the new kernel test should pass)
2. Update the issue summary with a list of concrete questions for @tedbow to decide whether it should be included in automatic updates for contrib modules (e.g. e-mails getting sent)
3. Write a build test and get it to pass.

Update the issue summary with a list of concrete questions for @tedbow to decide whether it should be included in automatic updates for contrib modules (e.g. e-mails getting sent)

This is going to require a thorough top-down review of the entire AUE module from me, to generate this list of questions. When all tests are written and passing, assign this issue to me to do that.

Write a build test and get it to pass.

A little expansion on what this should entail: it should create a test site with three installed contrib extensions (two modules and a theme). The theme, and one of the modules, should have available updates; the other module shouldn't. The things with updates should get updated during cron; the other thing should be unchanged.

Tests are all green now, now working on handling multiple contrib module updates at once.

Also for now without the release chooser we are looking at the recommended key for target release.

#12: Thanks for elaborating 🙏😊

#13: Great! 🚀

#14: That sounds fine! 👍

So the problem right now is that i. don't think the logger is working properly, because i can't see the message being logged from modules/contrib/automatic_updates/automatic_updates_extensions/src/CronExtensionUpdateStage.php:371.

I was trying to observe logs at modules/contrib/automatic_updates/automatic_updates_extensions/tests/src/Build/CronModuleUpdateTest.php:134.

i have some file put contents which i have commented for now to see if all the methods are called as i expect them to be, which are in the pattern file_put_contents('/Users/omkar.podey/

assigning to @ted.bow for the logger.

AFAICT #3355628 would also simplify the writing of the build test for this issue, because there's better information to act on after the build test fails. See #3355628-12: Package Manager should keep an audit log of changes it applied to the active codebase.

The url for release history needs to be replaced while using the build test project, so it's able to get the alpha module release history.
$config['update.settings']['fetch']['url'] = 'http://temp.test/build-temp/test-release-history'; ---> to be changed in settings.php

@tedbow mentioned in Slack:

ted.bowman  6 hours ago
@Omkar Podey sorry I was not able to get back to this issue till the end of my day and then I ran to some unrelated technical issues.

ted.bowman  6 hours ago
If you want a break from it I can take most tomorrow to work on it.  Otherwise feel free to look at it again

Reflecting that.

Crediting myself for https://git.drupalcode.org/project/automatic_updates/-/merge_requests/84... — which I discovered while pairing with @omkar.podey for ~2.5 hours yesterday 🤠

The update_test.settings config override caused Drupal to think that it was always version 1.0.0 of the alpha module that was installed, even after updating!

So i got to test the build test project and the module is getting updated but the handlePostApply isn't getting called as the curl is failing in triggerPostApply.