Please check the Laravel support policy table for supported Laravel and PHP versions.

Require the package using Composer

composer require stackkit/laravel-google-cloud-tasks-queue

Add a new queue connection to config/queue.php

'cloudtasks' => [
    'driver' => 'cloudtasks',
    'project' => env('STACKKIT_CLOUD_TASKS_PROJECT', ''),
    'location' => env('STACKKIT_CLOUD_TASKS_LOCATION', ''),
    'queue' => env('STACKKIT_CLOUD_TASKS_QUEUE', 'default'),
    
    // Required when using AppEngine
    'app_engine'            => env('STACKKIT_APP_ENGINE_TASK', false),
    'app_engine_service'    => env('STACKKIT_APP_ENGINE_SERVICE', ''),
    
    // Required when not using AppEngine
    'handler'               => env('STACKKIT_CLOUD_TASKS_HANDLER', ''),
    'service_account_email' => env('STACKKIT_CLOUD_TASKS_SERVICE_EMAIL', ''),
    'signed_audience'       => env('STACKKIT_CLOUD_TASKS_SIGNED_AUDIENCE', true),
    
    // Optional: The deadline in seconds for requests sent to the worker. If the worker
    // does not respond by this deadline then the request is cancelled and the attempt
    // is marked as a DEADLINE_EXCEEDED failure.
    'dispatch_deadline' => null,
    'backoff' => 0,
],

Update the QUEUE_CONNECTION environment variable

QUEUE_CONNECTION=cloudtasks

Now that the package is installed, the final step is to set the correct environment variables.

Please check the table below on what the values mean and what their value should be.

Typically a Laravel queue has a worker that listens to incoming jobs using the queue:work / queue:listen command. With Cloud Tasks, this is not the case. Instead, Cloud Tasks will schedule the job for you and make an HTTP request to your application with the job payload. There is no need to run a queue:work/listen command.

• The "Min backoff" and "Max backoff" options in Cloud Tasks are ignored. This is intentional: Laravel has its own backoff feature (which is more powerful than what Cloud Tasks offers) and therefore I have chosen that over the Cloud Tasks one.
• Similarly to the backoff feature, I have also chosen to let the package do job retries the 'Laravel way'. In Cloud Tasks, when a task throws an exception, Cloud Tasks will decide for itself when to retry the task (based on the backoff values). It will also manage its own state and knows how many times a task has been retried. This is different from Laravel. In typical Laravel queues, when a job throws an exception, the job is deleted and released back onto the queue. In order to support Laravel's backoff feature, this package must behave the same way about job retries.

Experimental

The dashboard works by storing all outgoing tasks in a database table. When Cloud Tasks calls the application and this package handles the task, we will automatically update the tasks' status, attempts and possible errors.

There is probably a (small) performance penalty because each task dispatch and handling does extra database read and writes. Also, the dashboard has not been tested with high throughput queues.

To make use of it, enable it through the .env file:

STACKKIT_CLOUD_TASKS_DASHBOARD_ENABLED=true
STACKKIT_CLOUD_TASKS_DASHBOARD_PASSWORD=MySecretLoginPasswordPleaseChangeThis

Then publish its assets and migrations:

php artisan vendor:publish --tag=cloud-tasks
php artisan migrate

The dashboard is accessible at the URI: /cloud-tasks

Set the GOOGLE_APPLICATION_CREDENTIALS environment variable with a path to the credentials file.

More info: https://cloud.google.com/docs/authentication/production

If you're not using your master service account (which has all abilities), you must add the following roles to make it works:

1. App Engine Viewer
2. Cloud Tasks Enqueuer
3. Cloud Tasks Viewer
4. Cloud Tasks Task Deleter
5. Service Account User

This package verifies that the token is digitally signed by Google. Only Google Tasks will be able to call your handler.

More information about OpenID Connect:

https://developers.google.com/identity/protocols/oauth2/openid-connect