This message was deleted.

your image should be publically available, so create it locally and push it to a repo

In my setup, I'm setting up a cloud build trigger to do the build/push step, then the cloud run action to run it. The cloud build can trigger a new revision too if you want

I've been doing something similar, but using Github Actions--

docker/build-push-action@v3

to build and push it to Google Artifact Registry, then using that action's output as an env var in my pulumi action. But that doesn't seem to be working as I thought it would. Perhaps I should use the pulumi docker module instead to get the digest by hand in the script, like in the example

Do you need to have pulumi as the "deployment" mechanism? Google lets you pub/sub on artifact registry push, and then trigger a new revision. Usually I let the Infra-as-code (pulumi), set up the process, but it doesn't need to be invoked in order to deploy, that is entirely triggered by git events (push to a specific branch, or a tag)

So you just use pulumi up to create the service the first time and apply any env, secret, other container settings like ram and cpu and concurrency etc? But then deploy fresh revisions pointing to new builds using Google tools?

Yep, that's exactly how I do it. I set an ignore on the image field in the cloud run action spec, so that pulumi doesn't mind if the image changes, and doesn't try to override it.

Maybe that's simpler.

It's working for me, but that doesn't mean it's "correct" 🙂

Well, the way I'm doing it is not working, much to my chagrin after I finally noticed.

Cloud run has been rather finnicky for me. If the cloud run instance fails to start up, it seems to hang in Pulumi

In my case, I needed to use

autogenerate_revision_name=True

-- Pulumi was trying to update an existing, running revision, instead of deploying a new one.

👍