silverstripe/silverstripe-crontask

Easily setup tasks to be run by using cron expressions

silverstripe-crontask's Issues

Update Travis configuration for SS4 builds

See other core modules for an example, we need to move away from using travis-support now.

Release v1.2

Release a stable 1.2.0 tag so that 55d52fb can be used. Whether to start with beta/rc is an exercise for the reader.

Error during install: no controller registered

Hi, I am trying to install SilverStripe on a local Linux desktop with PHP Version 8.0.8 and I am receiving an error message similar to #42:

$ composer create-project silverstripe/installer silverstripe
# well done
$ cd silverstripe
# create .env, set the database connection
$ vendor/bin/sake dev/bulid

ERROR [Emergency]: Uncaught Exception: Error: no controller registered in SilverStripe\Dev\DevelopmentAdmin for: bulid
IN GET dev/bulid
Line 162 in /var/www/sandbox/silverstripe/vendor/silverstripe/framework/src/Dev/DevelopmentAdmin.php

Source
======
  153:         }
  154: 
  155:         if ($controllerClass && class_exists($controllerClass)) {
  156:             return $controllerClass::create();
  157:         }
  158: 
  159:         $msg = 'Error: no controller registered in ' . static::class . ' for: ' .
       $request->param('Action');
  160:         if (Director::is_cli()) {
  161:             // in CLI we cant use httpError because of a bug with stuff being in the output already,
       see DevAdminControllerTest
* 162:             throw new Exception($msg);
  163:         } else {
  164:             $this->httpError(404, $msg);
  165:         }
  166:     }
  167: 
  168: 

Trace
=====
SilverStripe\Dev\DevelopmentAdmin->runRegisteredController
RequestHandler.php:323

SilverStripe\Control\RequestHandler->handleAction
Controller.php:286

SilverStripe\Control\Controller->handleAction
RequestHandler.php:202

SilverStripe\Control\RequestHandler->handleRequest
Controller.php:212

SilverStripe\Control\Controller->handleRequest
Director.php:360

SilverStripe\Control\Director->SilverStripe\Control\{closure}
VersionedHTTPMiddleware.php:41

SilverStripe\Versioned\VersionedHTTPMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
LoginSessionMiddleware.php:29

SilverStripe\SessionManager\Middleware\LoginSessionMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
ConfirmationMiddleware.php:254

SilverStripe\Control\Middleware\ConfirmationMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
ConfirmationMiddleware.php:254

SilverStripe\Control\Middleware\ConfirmationMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
PasswordExpirationMiddleware.php:84

SilverStripe\Security\PasswordExpirationMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
BasicAuthMiddleware.php:68

SilverStripe\Security\BasicAuthMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
AuthenticationMiddleware.php:61

SilverStripe\Security\AuthenticationMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
ExecMetricMiddleware.php:20

SilverStripe\Control\Middleware\ExecMetricMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
CanonicalURLMiddleware.php:190

SilverStripe\Control\Middleware\CanonicalURLMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
HTTPCacheControlMiddleware.php:42

SilverStripe\Control\Middleware\HTTPCacheControlMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
ChangeDetectionMiddleware.php:28

SilverStripe\Control\Middleware\ChangeDetectionMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
FlushMiddleware.php:27

SilverStripe\Control\Middleware\FlushMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
RequestProcessor.php:66

SilverStripe\Control\RequestProcessor->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
SessionMiddleware.php:20

SilverStripe\Control\Middleware\SessionMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
AllowedHostsMiddleware.php:60

SilverStripe\Control\Middleware\AllowedHostsMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
TrustedProxyMiddleware.php:176

SilverStripe\Control\Middleware\TrustedProxyMiddleware->process
HTTPMiddlewareAware.php:62

SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}
HTTPMiddlewareAware.php:65

SilverStripe\Control\Director->callMiddleware
Director.php:369

SilverStripe\Control\Director->handleRequest
HTTPApplication.php:117

SilverStripe\Control\HTTPApplication::SilverStripe\Control\{closure}

call_user_func
HTTPApplication.php:136

SilverStripe\Control\HTTPApplication->SilverStripe\Control\{closure}
HTTPMiddlewareAware.php:65

SilverStripe\Control\HTTPApplication->callMiddleware
HTTPApplication.php:137

SilverStripe\Control\HTTPApplication->execute
HTTPApplication.php:116

SilverStripe\Control\HTTPApplication->handle
cli-script.php:22

[2022-03-12 11:42:29] error-log.ERROR: Uncaught Exception Exception: "Error: no controller registered in SilverStripe\Dev\DevelopmentAdmin for: bulid" at /var/www/sandbox/silverstripe/vendor/silverstripe/framework/src/Dev/DevelopmentAdmin.php line 162 {"exception":"[object] (Exception(code: 0): Error: no controller registered in SilverStripe\\Dev\\DevelopmentAdmin for: bulid at /var/www/sandbox/silverstripe/vendor/silverstripe/framework/src/Dev/DevelopmentAdmin.php:162)"} []

Better integration with queuedjobs

There's a couple of things that could be done to this module to make it work more nicely with queuedjobs.

• Come bundled with a crontask for running the job queue
• Reduce the amount of boilerplate needed to do crontask that adds a buildtask-execution to the job queue (a handy pattern for managing your background tasks)

This might be facilitated with #9

Example with Sera + rationale

In the README there is the following statement:

Warning: Observe that the crontask module doesn't to any scheduling. If the run time is more than one
minute, it might start another process that interferes with the still running process.

It would be great to pad this out a bit with a rationale and an example using Sera. E.g.

Warning: Ensure that a custom CronTask doesn't do any scheduling of its own. If a custom CronTask itself forks other sub tasks or is itself long running (i.e. > 1m), the server's cron-job might start another process that interferes with any existing and running processes. This can be mitigated by running the module's cron-job less frequently or proxying the module's cron-jobs through the "Sera" module, which implements a form of DML (Distributed Mutex Locking) e.g.

* * * * * sera 60 $( www-data /usr/bin/php /path/to/silverstripe/docroot/framework/cli-script.php dev/cron )

Abandoned composer-module is required

In composer a module is required mtdowling/cron-expression. This module seems to be abandoned (use dragonmantank/cron-expression instead).

Package mtdowling/cron-expression is abandoned, you should avoid using it. Use dragonmantank/cron-expression instead.

But I actually can't find any use of their code in this module?

Make a new release

There are a number of new commits in master vs the current stable 1.1.0 tag. Perhaps time for a new minor/patch release?

New minor release

We need to tag a new minor release to replace a package in the current stable tag that has been abandoned:
#57

This will be done as part of the upcoming CMS quarterly release (which goes stable in June). Creating this issue for planning purposes.

PR

• https://github.com/silverstripe/silverstripe-crontask/releases/edit/untagged-3faa904a236b9da4bd06#

Get rid of "will run at" messages by default

2017-11-13 16:12:02 - UpdateAddonsCron will run at 2017-11-13 16:30:00.
2017-11-13 16:12:02 - SilverStripeElasticaReindexCron will run at 2017-11-13 17:00:00.
2017-11-13 16:12:02 - CacheHelpfulRobotDataCron will run at 2017-11-14 01:00:00.
2017-11-13 16:12:02 - BuildAddonsCron will run at 2017-11-13 18:00:00.
2017-11-13 16:11:02 - UpdateSilverStripeVersionsCron will run at 2017-11-13 16:20:00.
2017-11-13 16:11:02 - UpdateAddonsCron will run at 2017-11-13 16:30:00.
2017-11-13 16:11:02 - SilverStripeElasticaReindexCron will run at 2017-11-13 17:00:00.
2017-11-13 16:11:02 - CacheHelpfulRobotDataCron will run at 2017-11-14 01:00:00.

This is a lot of log noise.

I think the messages should only be shown if you use /dev/cron?debug=1 rather than just /dev/cron

No 3.0 branch

I've done the change in my fork 0.1 branch, but pull requests can't pull to a new branch as far as I can see.
Create it and I will send a PR.

Also, please give me full administrative access over this repository too ^.^

php 8 requirement too narrow

The composer.json locks this package's php 8 requirement to exactly 8.0.0. Although I haven't done extensive testing, everything seems to be working fine for me on php 8.0.9 (as you'd expect of a patch version change), and the travis CI runs the phpunit tests against 8.0.2.

Is it possible to bump the php version requirements to something like "^8.0" so this project can be used on php 8 projects that aren't exactly 8.0.0?

Fix test failures due to bad code coverage upload

@robbieaverill :P

Example with Sera + rationale

In the README there is the following statement:

Warning: Observe that the crontask module doesn't to any scheduling. If the run time is more than one
minute, it might start another process that interferes with the still running process.

It would be great to pad this out a bit with a rationale and an example using Sera. E.g.

Warning: Ensure that a custom CronTask doesn't do any scheduling of its own. If a custom CronTask itself forks other sub tasks or is itself long running (i.e. > 1m), the server's cron-job might start another process that interferes with any existing and running processes. This can be mitigated by running the module's cron-job less frequently or proxying the module's cron-jobs through the "Sera" module, which implements a form of DML (Distributed Mutex Locking)

Clarification on 'long running jobs'

This is more of a question really (/suggestion of clarification in the README);

Do I understand correctly if:

• I let crontask check for due tasks every minute, and
• I have a task "SendMails" scheduled to run every 5 minutes

When task "SendMails" is started at 17:10 and to be running for 3 minutes, it will be re-started at 17:11?

Because that's what I understand from the README (but I see that the module also keeps track of tasks it has started etc). Or is it indeed the case that a task will only be re-run at the next scheduled interval (e.g. in the above example "SendMails" will be re-run at 17:15, whether it is still running or not).

dev/cron fails: Error: no controller registered in SilverStripe\Dev\DevelopmentAdmin for: cron

$ vendor/bin/sake dev/cron '' flush=1
ERROR [Emergency]: Uncaught Exception: Error: no controller registered in SilverStripe\Dev\DevelopmentAdmin for: cron
IN GET dev/cron
Line 133 in /Users/robbieaverill/dev/demo.silverstripe.org/vendor/silverstripe/framework/src/Dev/DevelopmentAdmin.php

Source
======
  124:         }
  125: 
  126:         if ($controllerClass && class_exists($controllerClass)) {
  127:             return $controllerClass::create();
  128:         }
  129: 
  130:         $msg = 'Error: no controller registered in '.__CLASS__.' for: '.$request->param('Action');
  131:         if (Director::is_cli()) {
  132:             // in CLI we cant use httpError because of a bug with stuff being in the output already,
       see DevAdminControllerTest
* 133:             throw new Exception($msg);
  134:         } else {
  135:             $this->httpError(500, $msg);
  136:         }
  137:     }
  138: 
  139: 

Trace
=====
SilverStripe\Dev\DevelopmentAdmin->runRegisteredController(SilverStripe\Control\HTTPRequest)
RequestHandler.php:320

SilverStripe\Control\RequestHandler->handleAction(SilverStripe\Control\HTTPRequest, runRegisteredController)
Controller.php:282

When running vendor/bin/sake dev/cron

Use an Injector registry

Right now, you need a separate class for each cronjob, and any class that exists will be automatically run. This is simpler, but also less flexible. For example, you can't create a class CronRunBuildTask class that takes a build task as a wrapper.

That way, you could mix and match simple CronTask implementations with configured ones:

CronTaskController:
  tasks:
    - %$SyncHourlyTask
    - %$Namesace\Class\I\Just\Want\To\Use\Without\Arguments

Injector:
  SyncHourlyTask:
    class: CronRunBuiskTask
    properties:
      Schedule: "* * * * 0"
      BuildTask: FilesystemSyncTask

If you wanted to support the old way of running all implementors of the interface, you could have a config option for that:

CronTaskController:
  tasks: [ "*" ]

how to test a cron task?

More a question than an issue, but is there a way to manually trigger a task? For example I have a cron that runs monthly, but I want to test that it works before the next month. Can I trigger a task without waiting a month? Maybe something like vendor/bin/sake dev/cron triggerNow=MyCronTask which would ignore the task's schedule and just run the task now.

Add LoggerInterface argument to process.

It would be nice if the process() method could be passed a Psr\Log\LoggerInterface object for it to send it status output to.

That way, process implementors can provide a range of output at debug, info, and notice level and the logger can decide what to do.

Coupled to this, I would suggest that the dev/cron action has a suitable logger injected into it, and perhaps defaults to a logger that dumps notice-and-above level errors to stdout. Making monolog a composer dependency might be the easiest solution for that. (Requiring monolog ~1.11 will ensure that you get a PSR-3 complaint version).

This would need to be a major version bump of the crontask module as it would change its interface.

Tasks are only run on time == runtime

It only checks if current time === run time - if a job missed it's run time (because some other job took longer than a minute) it wouldn't rerun.

Reported by @hafriedlander