Workflows to notify developers by email when there is an update to Cloud Run services. — Part 2

The mass adoption of Cloud Run has led to changes in the way many people work. Changes that impact development environments and sometimes require challenges.

Here we will see how to improve our previous architecture by removing the Cloud Run service that was acting as an intermediary between Eventarc and Workflow.

The message of the notifications, will include several information related to the Cloud Run service that has been updated.

Let’s move on to the configuration of our system.

Activation of the necessary APIs

gcloud services enable run.googleapis.com
gcloud services enable eventarc.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable workflows.googleapis.com
gcloud services enable secretmanager.googleapis.com

Creation of a Service for the final test

Let’s deploy the image us-docker.pkg.dev/cloudrun/container/hello on Cloud Run with the service name hello.

Leave the rest of the settings as default.

Enabling cloud Audit logs

To receive events from a service, you must enable Cloud Audit Logs.

In Cloud Console, select IAM & Admin followed by Audit Logs in the top left menu. In the list of services, check Cloud Run Admin API :

Select Data Write and click SAVE to save your choice.

Configuration of service accounts for Workflows

To use Workflows, we will need a workflow-push-mail service account that will have the following role:

Eventarc Event Receiver : Receive the events.

Secret Manager Secret Accessor : with this role we can access the environment variable SENDGRID_API_KEY .

To register the variable SENDGRID_API_KEY in Secret Manager, select Security followed by Secret Manager in the top left menu. Then click on CREATE SECRET and put the name of your variable and the value of the secret. Leave the rest of the settings as default.

Create our workflow

In the following workflow, we will retrieve the information from the Cloud Run service that triggered the event. Then, we will send them to the developers by email.

• serviceImage: the image that has been deployed.
• serviceCreator: the coordinates of the person who made the update.
• serviceRegion: the Cloud Run service region.
• dateCreation: the date and time of the Cloud Run service update.
• serviceName: the Cloud Run service name.
• revisionName: the name of the latest revision of the Cloud Run service.
• serviceUrl: the Cloud Run service url.

Now we’ll configure Eventarc.

Configuration of service accounts for Eventarc

We will create a service account that we will call event-trig-workflow that will have the roles:

Eventarc Event Receiver : Receive the events.

Workflows Invoker : Access to run workflows and manage executions.

Create an Eventarc trigger

Before you start, you should know that if you use a single region for your Eventarc trigger, only events from Cloud Run services in that region will be captured. If you want to support all your Cloud Run services, you should use the global region.

Now, let’s proceed to the configuration of our Eventarc trigger with the service account event-trig-workflow . We’ll use our previous workflow as the destination source.

It’s time to test our configuration. To do so, you just have to update the hello service we deployed first (for example, change the maximum number of requests per container) and you will receive an email.

For sending mail from workflow, I used the article of Guillaume Laforge.

You can use a function (Cloud Functions) to send the mails. You will just have to call your function and pass him the information to retrieve. If you are interested here is an article that can help you👇.

Workflows Tutorial | Cloud Functions Documentation | Google Cloud

Thanks to you for reading and to my mentor guillaume blaquiere for the advice.