Background Processes

Mint supports background processes for running commands alongside the defined run command for task. The most common use case is running docker compose to run services necessary for your application. See Mint's docker documentation for more information on using Docker with background processes. Specifying background processes is better than using the background feature of bash since Mint will capture and display logs from the background processes.

Example using Docker

tasks:
  - key: packages
    run: |
      sudo apt-get update
      sudo apt-get install netcat redis-tools
      sudo apt-get clean

  - key: ping-redis
    use: [packages]
    docker: true
    background-processes:
      - key: redis
        run: docker run -p 6379:6379 index.docker.io/library/redis:latest
        ready-check: nc -z localhost 6379
    run: |
      redis-cli ping

You'll see the PONG response from Redis in your Mint task logs.

Ready Checks

The ready-check script is optional.

If it is not specified, the run script for the task will start running immediately after all of the background processes have been started. If your run script needs a background service to be ready, such as a database process actively listening for connections, not having a ready-check script could result in a race condition where the run script could execute before the background service is ready. To prevent this problem, add a ready-check script to your background processes. Once the ready check for all background processes has passed, the run script will execute.

When a ready-check is specified, Mint will wait for the ready-check to pass before starting the next background process.

Ready Check Timeouts

You can configure a timeout for the ready check to pass like this:

background-processes:
  - key: redis
    docker: true
    run: docker run -p 6379:6379 index.docker.io/library/redis:latest
    ready-check:
      run: nc -z localhost 6379
      timeout-seconds: 20

If a timeout is not specified, the default timeout is 60 seconds. In practice, it's uncommon to lower the timeout. The ability to override the default timeout mostly exists for scenarios where a background process may need more than the default of 60 seconds to start. The overall task timeout (configured via timeout-minutes on the task definition, default of 10 minutes) will still apply, and is inclusive of the background processes.