[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 📌 [PP-1] Pave the path for contrib updates: automatically limit the staged updates to those modules without DB updates Postponed .

I talked to @omkar.podey a while ago about working on this

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

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

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 it's just 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.

@omkar.podey I look at this a little but didn't have time to figure it out.

I push 1 commit that will let you run the build test but exit early with a drupal site built that you can use afterwards to just run cron manually and use xdebug to investigate further.

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

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';

@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 current problem in the build test project it's failing on require

  - Root composer.json requires drupal/alpha 1.1.0, it is satisfiable by drupal/alpha[1.1.0] from path repo (/private/tmp/build_workspace_b909895e9128fad83a04958a09c84e98euR8Li/fixtures_temp_zQkobUMtRXTtDRyjEc63) but drupal/alpha[1.0.0] from path repo (/private/tmp/build_workspace_b909895e9128fad83a04958a09c84e98euR8Li/fixtures_temp_zQkobUMtRXTtDRyjEc634) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.

Postponed on 📌 For web cron updates run each stage life cycle phase in a different request Closed: won't fix which is going to re-write unattended updates