Disallow unattended updates if performed by automated_cron

The test fails in CronFrequencyValidatorTest::testAutomatedCronValidation because it enables the Automated Cron module while doing cron update. I think we can remove that test as our module is currently incompatible with Automated Cron.

See MR comments

@kunal.sachdev is out for a while i'll take this up.

porting @Wim.leers comments

he helped me to figure out a way forward here,

1. because it is physically impossible for a validator to show a validation result that depends on the TERMINATE event (because it happens after the status report page has rendered!)
2. recover the functional test coverage from #3362978: Module does not work with Automated Cron

#11

I am exactly sure of the context of @wim leers comments but...

because it is physically impossible for a validator to show a validation result that depends on the TERMINATE event (because it happens after the status report page has rendered!)

I assume this is referring to this version of the validor that I committed

The logic around setTerminateCalled in the version has nothing to with the status report it only affects PreCreateEvent::class => 'validatePreCreate', and PreCreate will never affect the status report.

This PreCreate will ensure that if the user does not disable Automated Cron and the cron update gets invoke anyways by this module will not run. It will still be logged because \Drupal\automatic_updates\CronUpdateStage::performUpdate will log and email any errors

#12:

Ah, I get it now! This would work if automated cron itself was triggered during KernelEvents::TERMINATE, because then all of Automatic Updates' Stage-related events would be dispatched after that.

So then both approaches are equivalent. I think mine is clearer because it is able to put a clear early return in automatic_updates_cron(), while yours is more difficult to understand the flow for. (Especially the automatic logging/emailing you mention is non-trivial to see.)

But … no strong opinion.

BTW, if the reasoning behind your approach had had documentation, @omkar.podey and I wouldn't have spent half an hour trying to come up with an alternative approach. Neither of us had deciphered your advanced wizardry! 🙈 If you switch to that approach, please add clear docs 🙏

Improving title accuracy. And I think this is an alpha target?

I think mine is clearer because it is able to put a clear early return in automatic_updates_cron(), while yours is more difficult to understand the flow for

I personally like mine because all the logic is contained in 1 validator.

BTW, if the reasoning behind your approach had had documentation, @omkar.podey and I wouldn't have spent half an hour trying to come up with an alternative approach. Neither of us had deciphered your advanced wizardry!

Sorry I literally figured it out 5 minutes before my EOD yesterday and could only push it up. I should have written some quick comments on the code but didn't realize that it was that hard to understand

i need the logic on testing 'kernel::terminate' @ted.bow, and my local test site is having issues so i am trying to fix that.

@Wim.leers approach already has test coverage.

I just thought of simple way to test my approach

Generally I think this looks good. Some suggestions and cleanup...

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