Add and configure cronjobs

Last updated:
Edit on GitHub

This document shows how to add and configure cronjobs in Jenkins.

We use Jenkins for cronjob scheduling. Compared to Crontab, there are several benefits:

  • Jobs are queued and can be manually executed.
  • Job definitions are under version control and can be changed by any developer.
  • Console output is available for debugging.

Add a new job and run it

Jobs are defined in config/Zed/cronjobs/jenkins.php.

This file contains an array defining the jobs.

// Send emails every 10 minutes
$jobs[] = [
    'name'                  => 'send-mails',
    'command'               => '$PHP_BIN vendor/bin/console mail:send-mail',
    'schedule'              => '*/10 * * * *',
    'enable'                => true,
    'stores'                => ['DE', 'FR'],
];

To import this configuration to Jenkins, run vendor/bin/console scheduler:setup. In a production environment, this is part of the default Normal deployment process.

When you remove jobs from config/Zed/cronjobs/jenkins.php, the application cannot detect the removal, so the removed jobs stay in Jenkins in their last state.

To stop them, do so manually or through a support request.

Cronjob configuration

For each job you can define several configurations:

KEY TYPE PURPOSE ✓
name string Name of the job. yes
command string The console command that is executed. yes
schedule string Expression that defines the job schedule (how often the job runs). The schedule string is compatible with the cronjob schedule definition—for example, 0 * * * * means run once each hour at minute 00. If the environment is in development, return an empty string—on the development environment, cronjobs run manually only. yes
enable bool Enable or disable jobs. yes
stores array An array of stores where the job is executed. yes

When you do not use Jenkins for job scheduling, there is no locking between concurrently running commands.

Troubleshoot Jenkins errors

If during console command execution any request to Jenkins API fails, the command exits with a non-zero status and reports the affected job together with the Jenkins HTTP error and response.

For example:

Scheduler Status: ERROR
- DE_consume-queue
Scheduler Error: Job "DE_consume-queue": Jenkins request POST ... failed with HTTP 400 Bad Request. Jenkins error: A job already exists with the name "DE_consume-queue".