Render.yaml to run SQL init script

1

Hey there,

I’m creating a render.yaml to use the Deploy to Render button on my open-source Firebase alternative project.

I’m looking at a way to run an initial SQL script that creates one database schema and some system tables.

I’m in the Blueprint specifications docs and I’m not finding anything related to that.

Is there a way to do that without too much work around?

For instance, Heroku’s app.json has a scripts section with a postdeploy event where running init scripts makes sense.

Of course I could add that to the app startup, but I feel like it’s better place to have that in the IaC definition.

Any pointer would be highly appreciated.
Thanks

1 Like
2

Hi Dominic,

Thanks for reaching out.

Our Preview Environments (similar to a Heroku Review Apps) can utilize an initialDeployHook attribute in the render.yaml, to run a script at creation time, unfortunately, this isn’t used on the first/button deployment of a blueprint.

I’ve added this to our feedback site as a feature request, please feel free to upvote/comment; https://feedback.render.com/features/p/utilise-initialdeployhook-on-deploy-to-render-buttons

Please let us know if we can assist any further.

Kind regards

Alan

3

Thanks Alan, that’s unfortunate.

Thinking in terms of workaround than. Would there be a way to use either the cron or the background worker service type to accomplish this?

It feels a bit dirty, but the cron, maybe it could somehow grab the current date and have the longest possible schedule, since the script do CREATE X IF NOT EXISTS so running that say one a month would not be “terrible”, dirty, but not terrible haha.

Any thoughts on that? What would be the easiest way to run psql with the connectionstring env variable of the database section with -f filename.sql?

Thanks for your time/help

4

Instead of another service maybe you could put together a build script that has the condition checks and runs the psql command if required. These checks, however you implement them, would obviously need to be be pretty watertight as to not affect the database adversely on a subsequent deploy.

Jobs can also be useful to run one-off tasks, although these require the service ID and authentication, so would be a little trickier to incorporate into an automated deploy currently.

Hope that helps

Alan

1 Like