Announcing cancellable activities and crons

Feature announcement: You can now cancel Platform.sh activities through the CLI and management console.

Last year we released activity scripts, custom scripts that you can upload to your projects to run in response to any project or environment activity. In March we announced parallel activities, a queue that allows two simultaneous processes across your environments.

Today we're announcing another change to your activities—you can now cancel them. We’ve extended our API so that pending activities can be cancelled through the management console and the CLI if they’re running longer than you'd expect them to. Additionally, in_progress crons can also be cancelled while they’re running.

Cancellable activities give you even greater control over your project's events. To use the feature, just run platform activity:cancel ACTIVITY_ID with the CLI. (You can always retrieve the unique ACTIVITY_ID and its current status withplatform activity:list.)

Cancellable crons

Crons play an important role in your applications, and we’ve spent some time in the past covering how they should be scheduled, and whether they should be scheduled with crons or run on worker containers. For a long time, this has been the syntax for crons in your .platform.app.yaml file:

crons:
  mycommand:
    spec: "*/19 * * * *"
    cmd: <command here>

With this definition, you've scheduled a command to run every multiple of 19 minutes after the hour, right after the build phase (the file system is completely read-only, and there are no mounts) under the environment.cron activity type.

To allow you to define commands for cancelling crons, we’ve changed their syntax in .platform.app.yaml:

crons:
  mycommand:
    spec: "*/19 * * * *"
    commands:
      start: <command here>
      stop: <command here>
    shutdown_timeout: 10

The first change you'll see is that the cmd key has been moved to commands.start key. Since it's replicating the previous cmd attribute, it's the only required definition in command. Same as before, everything defined in commands.start will run when the cron is triggered.

Stopping crons gracefully

There are also two new keys available: commands.stop and shutdown_timeout. commands.stop allows you to define a way to shut down the cron task—finishing an active item in a large list of tasks, for example—gracefully. With this definition in place, you can cancel a running cron task using that stop command through the management console by selecting the Stop run option from the activity's dropdown.

With the CLI you can retrieve the currently running cron's ID with the platform activity:list command and then cancel it using platform activity:cancel ACTIVITY_ID. It’s optional, and If you don't provide a stop command, cancelling the activity will send a SIGTERM signal to the process.

The last new attribute, shutdown_timeout (which is also optional), introduces an automatic safeguard against long-running crons. If a timeout is not specified the default value of the timeout is 10, which will send a SIGKILL to the process to force terminate the cron after it has run for 10 seconds.

Together these enhancements make your crons more configurable and better controlled. (But don’t worry, we’ll still continue to support the legacy cmd syntax.)