Step 24: Running Crons

Running Crons

Crons are useful to do maintenance tasks. Unlike workers, they run on a schedule for a short period of time.

Cleaning up Comments

Comments marked as spam or rejected by the admin are kept in the database as the admin might want to inspect them for a little while. But they should probably be removed after some time. Keeping them around for a week after their creation is probably enough.

Create some utility methods in the comment repository to find rejected comments, count them, and delete them:

patch_file

  1. --- a/src/Repository/CommentRepository.php
  2. +++ b/src/Repository/CommentRepository.php
  3. @@ -6,6 +6,7 @@ use App\Entity\Comment;
  4.  use App\Entity\Conference;
  5.  use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
  6.  use Doctrine\Persistence\ManagerRegistry;
  7. +use Doctrine\ORM\QueryBuilder;
  8.  use Doctrine\ORM\Tools\Pagination\Paginator;
  10.  /**
  11. @@ -16,6 +17,8 @@ use Doctrine\ORM\Tools\Pagination\Paginator;
  12.   */
  13.  class CommentRepository extends ServiceEntityRepository
  14.  {
  15. +    private const DAYS_BEFORE_REJECTED_REMOVAL = 7;
  16. +
  17.      public const PAGINATOR_PER_PAGE = 2;
  19.      public function __construct(ManagerRegistry $registry)
  20. @@ -23,6 +26,29 @@ class CommentRepository extends ServiceEntityRepository
  21.          parent::__construct($registry, Comment::class);
  22.      }
  24. +    public function countOldRejected(): int
  25. +    {
  26. +        return $this->getOldRejectedQueryBuilder()->select('COUNT(c.id)')->getQuery()->getSingleScalarResult();
  27. +    }
  28. +
  29. +    public function deleteOldRejected(): int
  30. +    {
  31. +        return $this->getOldRejectedQueryBuilder()->delete()->getQuery()->execute();
  32. +    }
  33. +
  34. +    private function getOldRejectedQueryBuilder(): QueryBuilder
  35. +    {
  36. +        return $this->createQueryBuilder('c')
  37. +            ->andWhere('c.state = :state_rejected or c.state = :state_spam')
  38. +            ->andWhere('c.createdAt < :date')
  39. +            ->setParameters([
  40. +                'state_rejected' => 'rejected',
  41. +                'state_spam' => 'spam',
  42. +                'date' => new \DateTime(-self::DAYS_BEFORE_REJECTED_REMOVAL.' days'),
  43. +            ])
  44. +        ;
  45. +    }
  46. +
  47.      public function getCommentPaginator(Conference $conference, int $offset): Paginator
  48.      {
  49.          $query = $this->createQueryBuilder('c')

Tip

For more complex queries, it is sometimes useful to have a look at the generated SQL statements (they can be found in the logs and in the profiler for Web requests).

Using Class Constants, Container Parameters, and Environment Variables

7 days? We could have chosen another number, maybe 10 or 20. This number might evolve over time. We have decided to store it as a constant on the class, but we might have stored it as a parameter in the container, or we might have even defined it as an environment variable.

Here are some rules of thumb to decide which abstraction to use:

  • If the value is sensitive (passwords, API tokens, …), use the Symfony secret storage or a Vault;
  • If the value is dynamic and you should be able to change it without re-deploying, use an environment variable;
  • If the value can be different between environments, use a container parameter;
  • For everything else, store the value in code, like in a class constant.

Creating a CLI Command

Removing the old comments is the perfect task for a cron job. It should be done on a regular basis, and a little delay does not have any major impact.

Create a CLI command named app:comment:cleanup by creating a src/Command/CommentCleanupCommand.php file:

src/Command/CommentCleanupCommand.php

  1. namespace App\Command;
  3. use App\Repository\CommentRepository;
  4. use Symfony\Component\Console\Command\Command;
  5. use Symfony\Component\Console\Input\InputInterface;
  6. use Symfony\Component\Console\Input\InputOption;
  7. use Symfony\Component\Console\Output\OutputInterface;
  8. use Symfony\Component\Console\Style\SymfonyStyle;
  10. class CommentCleanupCommand extends Command
  11. {
  12.     private $commentRepository;
  14.     protected static $defaultName = 'app:comment:cleanup';
  16.     public function __construct(CommentRepository $commentRepository)
  17.     {
  18.         $this->commentRepository = $commentRepository;
  20.         parent::__construct();
  21.     }
  23.     protected function configure()
  24.     {
  25.         $this
  26.             ->setDescription('Deletes rejected and spam comments from the database')
  27.             ->addOption('dry-run', null, InputOption::VALUE_NONE, 'Dry run')
  28.         ;
  29.     }
  31.     protected function execute(InputInterface $input, OutputInterface $output): int
  32.     {
  33.         $io = new SymfonyStyle($input, $output);
  35.         if ($input->getOption('dry-run')) {
  36.             $io->note('Dry mode enabled');
  38.             $count = $this->commentRepository->countOldRejected();
  39.         } else {
  40.             $count = $this->commentRepository->deleteOldRejected();
  41.         }
  43.         $io->success(sprintf('Deleted "%d" old rejected/spam comments.', $count));
  45.         return 0;
  46.     }
  47. }

All application commands are registered alongside Symfony built-in ones and they are all accessible via symfony console. As the number of available commands can be large, you should namespace them. By convention, the application commands should be stored under the app namespace. Add any number of sub-namespaces by separating them by a colon (:).

A command gets the input (arguments and options passed to the command) and you can use the output to write to the console.

Clean up the database by running the command:

  1. $ symfony console app:comment:cleanup

Setting up a Cron on SymfonyCloud

One of the nice things about SymfonyCloud is that most of the configuration is stored in one file: .symfony.cloud.yaml. The web container, the workers, and the cron jobs are described together to help maintenance:

patch_file

  1. --- a/.symfony.cloud.yaml
  2. +++ b/.symfony.cloud.yaml
  3. @@ -52,6 +52,15 @@ hooks:
  5.          (>&2 symfony-deploy)
  7. +crons:
  8. +    comment_cleanup:
  9. +        # Cleanup every night at 11.50 pm (UTC).
  10. +        spec: '50 23 * * *'
  11. +        cmd: |
  12. +            if [ "$SYMFONY_BRANCH" = "master" ]; then
  13. +                croncape symfony console app:comment:cleanup
  14. +            fi
  15. +
  16.  workers:
  17.      messages:
  18.          commands:

The crons section defines all cron jobs. Each cron runs according to a spec schedule.

The croncape utility monitors the execution of the command and sends an email to the addresses defined in the MAILTO environment variable if the command returns any exit code different than 0.

Configure the MAILTO environment variable:

  1. $ symfony var:set MAILTO=[email protected]

You can force a cron to run on your local machine:

  1. $ symfony cron comment_cleanup

Note that crons are set up on all SymfonyCloud branches. If you don’t want to run some on non-production environments, check the $SYMFONY_BRANCH environment variable:

  1. if [ "$SYMFONY_BRANCH" = "master" ]; then
  2.     croncape symfony app:invoices:send
  3. fi

Going Further

This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.