Multi repo Preview Environment


I’m new to preview environments.
I have several repositories with this structure :

  • banana-front
  • banana-back

Is there a way to trigger the same preview environment containing two Pull Requests on distincts repositories ?
I tried to make a PR with the same name on each repo but there is the date on the environment name, so I created two Preview Environment instead


Hi @Tactless7,

Indeed it’s possible. Not out of the box. But with a bit of work on your side, it’s something that it is possible to put in place. Basically, you’ll need to do a custom integration with your CI and the Qovery API to spin up a new environment and update your Qovery repositories to target the appropriate branches. Then you can implement your custom logic. I can provide guidance on how to use our API for this use case. But can you tell me what CI or what VCS (GitHub? GitLab?) you use?


Thanks for your answer
We are using Github Actions. Do you have some documentation on this ? We may work on it later as we have few time to dedicate for now
For now, we are using feature branches as “Preview Environnements”

Hi @Tactless7 , I can write a guide explaining how you can do it since we have customers that made this kind of integration. I can’t promise to make it for this week but I can do it for next week if that works for you.

1 Like

Hi @rophilogene, I’m working on preview environment too and we have many application like front / back that are not in same project and different repo. For example we have something like that

  • Project front
    • React application 1 (Repo front 1 - Dockerfile)
    • React application 2 (Repo front 2 - Dockerfile)
  • Project back
    • Api application 1 (Repo back 1 - container)
    • Consumer application 1 (Repo back 1 - container)
    • Api application 2 (Repo back 2 - Dockerfile)

When I made a PR PR-A for Api application 1 I would like to trigger a preview environment for Project front and Project back. For consumer application I think there is nothing more to do because it’s same repo.

I need to deploy Repo front 1 and Repo front 2 with the same version as the one in our staging environment if there is no PR with same name as the one that trigger the launch of preview env (PR-A) and all applications in Project back with the same rules.

As you can see I have the application type provided (container or Dockerfile), container is container that I build on my CI and Dockerfile is container build by Qovery on deploy.

For Dockerfile application it’s easy because Qovery handle everything but how can I specify the container tag to use for the preview environment that is not the same that the one on staging ?*

Hi @Orkin ,

I’m not sure to fully understand the question but I’ll try to start from the last point " how can I specify the container tag to use for the preview environment": If you have a new version of the Consumer application and you want to spawn a preview env for testing, you can trigger the creation of the preview environment for containers via the CI by calling this endpoint with the new image tag to use. From here Qovery will find the blueprint environment having the preview env feature activated and spawn a preview env where the Consumer app is using the new image tag

Let me know if anything is missing from my answer

Hi @a_carrano thanks for your reply !

Yes I think it can work, but it’s is possible to deploy multiple container with same or different tag within the same preview environment. For example I would like to deploy a preview environment for my consumer application and api application (same tag or not), deploy the front application with an other PR but with the same pattern (we have a PR pattern convention that match our sprint task).

Maybe with a full use case it will be more simple. We have a feature that need consumer update, api update and front update. Api and consumer (for us) it’s on the same repository so it’s same PR. Both PR for front and back are with the pattern feature/AB-XXXX so I would like a preview environment for this complete feature (back and front). The first PR (back) will start the preview environment with the right container tag. So the preview environment will start with new container tag for consumer and api application and the front with the normal tag (same as staging environment for example). Just after the PR is open for the front app and I will trigger to update the same preview environment with the new front app container tag to be able to test the feature with all involved applications.

Maybe it’s better like this ?