If I understand correctly I think the workflow I have in mind would be possible with the API.
We’re using a continuous deployment git flow, so we only have one production branch (main) and then we open PR to implement features/bug fixes. As soon as a PR is merged into main, it’s deployed in production. As we have no layer between our PR and our production branch, it’s very important for us to be as qualitative as possible in each PR, which means having a strong test suite and preview environments mirroring the production environment to have as much confidence as we can in the code we produce.
We’re using a render.yaml to declare our whole infrastructure on Render, including the
What we miss today is a way to manually deploy the preview environments on demand, because there are a lot of situations where we don’t want it to be deployed as soon as the PR is opened :
- Draft PR
- PR that doesn’t need a preview environment (doc, tiny fixes…)
What we’d like is to control (with Github Actions) when the preview environment is deployed on each PR, and being able to suspend/resume/delete it too.
For example we could do it using comments on the PR :
In order to support this workflow, we would need these functionalities available when using the API :
- Trigger a deploy/suspend/resume/delete preview environment based on the current PR
- Query the current preview environment status
- For the “resume” state, if we resume the preview environment and there were commits in between, I expect it to be up to date with the current PR code. And to be updated for each future push, exactly like how deploy works.
If I understand correctly, as you don’t plan to enable preview environment control with the API right now, we would have to declare 2 different render.yaml file? (one for the production and one for all the preview environments? Will the preview environments still be isolated from each other with this approach?)