No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

`dependsOn` is the answer for now, but you also might want to consider using an `initContainer` for tasks like DB migration instead of a `Job`

We are running multiple deployments that all depend on the same database, so an `initContainer` is not a great option. This also would require running the database migrations every time a pod restarted, which I wouldn't like very much. :slightly_smiling_face:

Thanks for the reply! Is there a feature request open like what I proposed above? Do you think I should open one?

I don’t know of an open issue, but the pulumi/pulumi repo would be the place for it

If you do want to pursue the `initContainer` route, you could make the migration script idempotent and add it to all relevant Deployments. So the script would run each time, but would be a no-op if the version already matched (or similar)

We’re using something along those lines for our on-prem SaaS

It's idempotent, but I really want a LOT more control than that. If the migration fails for any reason, I really, _really_ don't want my entire production infrastructure limping along repeatedly trying to migrate.

Additionally, having it as its own `Resource` means I can run it on its own, if we have a tricky deploy.

we came to the same conclusion and wrote a dynamic provider for schema migrations