Hello. I was reading the following post and was super excited to see the part about reduced build times! After immediately deploying to our infrastructure, it unfortunately appeared that our services still built the new image individually. I read the documentation linked in the post and am not exactly sure the reasoning. Is it because all of the different envs have autodeploy so the image doesn’t exist upon the initial trigger and starts building everywhere? The image in the post suggests it should build once and deploy everywhere, which is what I was hoping for. If there are other configurations in my application/env I need to check to make sure we can fully utilize this new feature, please let me know! Our different services all use the same “Git repository, Dockerfile, commit Id and root path” as the post suggests. Thanks.
Hi @colin , can you share the web console URL of the environment where you tried this? I’ll review your pipeline 
Hi @colin ,
I’ll try to explain a little bit more the feature (And add this information to the documentation).
You are right that the problem comes from “the image doesn’t exist upon the initial trigger.” This verification step is done just before starting to build the app’s image.
Since the requests are received in parallel (one for each app in auto-deploy), for all the deployment requests the image does not exist, which triggers the build phase for all of them.
A small diagram to explain it:
two apps A and B are configured on Qovery pointing to a repo X
- a commit is pushed on the repo X. Git(hub/lab) inform Qovery about the new commit
- Qovery starts the deployment of the two apps separately and checks the existence of the image. At this moment, the image does not exist and thus both deployments move forward with the build phase.
- Qovery starts building the image for each application and pushes it onto the repository.
As you see, every deployment is independent and the build choice is only based on the existence or not of the image on the container registry at the very beginning.
The optimization we released is rather useful when you are cloning an environment (since the image has already been built once) or if you have multiple applications from the same repo in multiple stages of the same environment (since the image has been built on a previous stage).
I had a look at your setup, I suppose that you want to keep isolated your environments and do not want to merge them.
I have only two solutions in mind right now:
- deploy via github actions: turn off the auto-deploy and instead trigger via a pipeline on github the deployments in two steps. In the first steps, only one application will be deployed, allowing to push the new image in the registry. The second step will trigger the deployment of every other application (which will make them skip the build since the image is already there)
- deploy containers: if you are already building the images on your side, you could directly deploy them instead of making them deploy by Qovery (but this requires some migration on your apps since the switch is not straightforward)
we will dig further to see what we can do on our side as well but it is not going to be an easy task (technically speaking). I have added an item on the public roadmap to track it.
I hope that all is clear now, let me know if you need more information
Is there currently or will you be doing a post about how to deploy via github actions? That sounds incredibly useful to our team.
Hi Colin,
we don’t have a real migration guide.
The pre-requisite here is to re-create all your applications to make them point to the container registry containing your application images.
Once this is done, you can use your github/gitlab workers to trigger the deployment on Qovery.
There is a guide explaining how to deploy your applications via github actions here GitHub Actions | Docs | Qovery
I hope this helps.
Alessandro
Point of clarification. In the 2 options you presented above, it sounded like the first option didn’t need to point the applications at a container registry. You just trigger one deploy and it builds in qovery, and once it is complete you deploy everywhere else. Is that not correct?
Oh sorry, I misread and focused on the second point.
Indeed the first one requires managing the deployments directly on github/lab without using the auto-deploy feature.
Let’s say you have a repository X and 3 Qovery apps pointing to it (A,B,C), what you can do is configure a github action that will be triggered when a PR is merged on the repo X. The auto-deploy feature should be disabled in all the applications.
The github action will have to:
- trigger the deployment on Qovery of the application A
- trigger the deployments of B and C
in step 1 Qovery will build the application while on step 2 Qovery will re-use the image built on the first step.
The cons I see on this solution are:
- the total deployment time will increase since you have to wait for the first deployment to complete
- potential additional cost on GitHub since you run the actions the whole deployment time
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.