Jobby Cron Bundle Laravel Package

Getting Started

1. Install and register manually. There is no Flex recipe, so after composer require imper86/jobby-cron-bundle you must add the bundle class to config/bundles.php yourself (Imper86\JobbyCronBundle\Imper86JobbyCronBundle::class => ['all' => true] — confirm the exact FQCN from composer show / src/).
2. Read three files first, in this order: src/DependencyInjection/Configuration.php (the config tree and every supported job key), src/DependencyInjection/*Extension.php (service IDs and aliases), and src/Command/* (the console command name and its arguments). These are the only reliable docs — the README is thin and the package is lightly maintained.
3. Confirm the command name with bin/console list | grep -i jobby rather than guessing.
4. First use case: migrate a single line from your crontab into Symfony. Create config/packages/jobby_cron.yaml with one job, then replace the crontab entry with a single line:

   * * * * * cd /path/to/app && php bin/console <jobby-command> >> var/log/jobby.log 2>&1
   

   Jobby reads the cron expression itself, so every job runs through that one entry point.

Implementation Patterns

• Config-driven jobs (the default path). Job keys mirror Jobby's native YAML format:

  jobby_cron:
      jobs:
          nightly_import:
              command: 'php bin/console app:import --env=prod'
              schedule: '0 3 * * *'
              output: '%kernel.project_dir%/var/log/import.log'
              enabled: true
              maxRuntime: 1800
              email: '[email protected]'
  

  Verify each key against Configuration.php before relying on it — the bundle may rename or nest jobs.
• Wrap Symfony commands as jobs. Point command at bin/console app:whatever so the job reuses your DI container, DB connections, and mailer. Prefer this over raw shell scripts; you keep testability and logging.
• Target a single job. Most Jobby wrappers expose --job=<name> (or positional). Use this in deploy hooks and for manual runs without triggering every job.
• Programmatic jobs. If you need runtime-derived jobs (e.g., one per tenant), inject the configured Jobby\Jobby service, call add() before run(), and let the bundle handle the rest. This is the extension seam when YAML isn't expressive enough.
• Output routing. Set output to a file under var/log/ and let Symfony's Monolog handle rotation, rather than relying on cron email. Keep alerting (email) separate from output capture.
• Locking across hosts. Jobby uses a lockfile; on multi-node setups put it on shared storage, otherwise each node runs the job.

Gotchas and Tips

• Maintenance risk. 6 stars, 0 dependents, low score. Pin an exact version in composer.json, audit the command and extension classes once, and be prepared to fork. Don't assume Symfony 7 compatibility — check composer.json constraints.
• No recipe = no auto-config. You will get "there is no extension able to load the configuration for jobby_cron" if the bundle isn't registered or the config key doesn't match the extension alias. The alias is in the Extension class, not necessarily the package name.
• Cron environment differs from your shell. php may not be on PATH, APP_ENV won't be dev, and the working directory is whatever cron gives you. Always cd into the project and use absolute paths for bin/console, lockfiles, and output.
• Timezone. Cron expressions are evaluated in the PHP process timezone, not the system one. Set date.timezone explicitly in the CLI php.ini if schedules look shifted.
• maxRuntime kills blindly. Fine for batch imports; dangerous if a job is a queue worker or holds a transaction. Set generously or omit.
• Stale locks. A crashed job can leave the lockfile behind and silently skip subsequent runs. Know where it lives and document manual cleanup.
• Output buffering. Jobby captures stdout/stderr in memory before writing; a chatty job can exhaust memory. Redirect verbose jobs to a file with output and keep command quiet.
• Email alerts vs. Symfony Mailer. Jobby's built-in mailer integration predates Symfony Mailer. If alerts don't arrive, wire up a custom notifier around the command rather than fighting the built-in transport.
• Extension points. Decorate the Jobby service or add a compiler pass to register jobs from other bundles (e.g., a job-owning module registering its own schedule). This is cleaner than one giant jobby_cron.yaml.
• Debugging. Run the command manually with -vvv, check var/log/ for both the job output and Symfony logs, and verify the schedule parses (a malformed cron expression can silently disable a job).