Port Ultimate Cron to Drupal 8

Ok, thanks for the quick feedback.

We have our monthly Drupal 8 Contrib Port sprints today (http://www.md-systems.ch/node/816), so maybe I'll start something today and if not, possibly next month.

Yes, ctools plugins/exportables should make for a pretty good starting point to convert it to plugins/config entities for 8.x.

Did found some time, so started the port: https://github.com/md-systems/ultimate_cron

Obviously far from complete, but I did move a lot of code around, converted the ctools plugins and started converting the ctools exportable to a config entity.

Miro making promises again that I'll have to keep? ;)

Yeah, it's that repository, but there wasn't too much activity since I started, had lots of other modules to port :)

We're still working on this. There are some major things in the port that I'm currently not yet happy about and wanted to ask @gielfeldt for some feedback or at least inform about the current plans:

* In 7.x, cron job discovery was very dynamic and could change any time depending on what hook_cronapi() returns. Cron jobs are config entities in 8.x and config doesn't really support that kind of dynamic change. So, we're dropping that, instead, modules can provide config entities for default configuration. We still look automaticallly for cron hooks in new (and soon also existing modules again) and create config entities for them if they don't exist yet. Not sure yet about automatically deleting, currently going for marking them as broken/missing in the UI and just allow to delete.

* I'm not sure about logging and launcher both being plugins that are configured per-job. Are there really use cases for that? Making them globally configured services would IMHO allow us simplify certain parts a lot.

* We've also started the currently not yet ported (global) settings, and the plan there is also to drop that plugin that and just implement them directly. Also related to the next point.

* Things are often nested in many method calls and many of hose also invokes multiple hooks and callbacks on plugins. To give you an example, this is the call chain until we actually invoke a cron callback:
1. UltimateCron::run() (replacement for the core service)
2. SerialLauncher::launchJobs()
3. SearialLauncher::runThread()
4. CronJob::launch() (the cronjob config entity)
5. SerialLauncher::launch()
6. CronJob::run()
7. LauncherBase::run()
8. CronJob::invoke()

And multiple of those methods trigger hooks and callbacks. That's very hard to follow and understand if you're trying to debug something. For example that we go back between the cron job and the launcher multiple times. I think one of the reasons for all those plugin callbacks are the settings plugins, haven't seen any other implementation of those. I'd like to try and simplify that a bit.

Any thoughts/opinions on those points? Thanks

Ah, another thing are all those background job, shutdown and other attempts at improving automatic cron. We've only touched what we had to of that. I honestly think that if you use a module like ultimate cron, then you probably need to have a reliable cron invocation and shouldn't rely on users visiting your site to trigger it.

Drupal 8 even moved that feature into a separate, completely optional module now. So it can be disabled or a better implementation can be provided by a contrib module that doesn't have to mess with replacing what's in core. One thing that is really nice in 8.x is that all cron invocations go through the cron service, and we just replace that and then every single way to call cron (drush, ui, callback) goes through that.

Given that, I think it would make a lot of sense to move all those things into either an optional submodule (that would likely look completely different to what is in 7.x) or even a different project. And remove it from this module.

Ok!

I'm finally happy enough to push this to D8, which is what I just did. I've also created an 8.x-2.x release and will hide 8.x-1.x from the overview. Hope that's OK with you, but since it's obviously not working at all, I guess that's not very controversial ;)

Some notes on the things above for what we've done for now:

* Implemented as suggested above, removed the add form but added a discover local action if a manual update is necessary (e.g. code changes). It's automatically discovered for newly installed modules. Currently only hook_cron() is supported, those additional hooks for automatic configuration to e.g. run every 1h are not yet supported, not sure if all that complexity is worth it?

* Logger and laucher are still per-job plugins for now

* The global setting Ui has been ported but it's not dynamic yet and not actually used yet. So that definitely needs more work.

* Nothing done yet to simplify the amount of nested calls going on. There are also some hidden bugs there, currently job runs are always considered to be manually started.

There's a bunch of cleanup and porting of missing pieces going on, but the parts that are ported are working fairly well. Nobody reported any major or critical issues so far.

I'll start working on the current issues more actively in the next days and weeks, with the goals of releasing at least a beta release. I'm not the original maintainer, so I'll move ahead the way I see fit, unless we get any feedback otherwise from @gielfeldt.

Marking this as fixed.

I will do that after going through the current issues.

Keep in mind that issues should always be reported and tested against the latest dev snapshot anyway.