Merge pull request #476 from Qovery/chore/updates_2024_10_09

Updates 2024/10/08

website/docs/using-qovery/configuration/environment-variable.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2024-05-22"
+last_modified_on: "2024-10-08"
 title: "Environment Variable & Secrets"
 description: "Learn how to configure Environment Variables and Secrets on Qovery"
 ---
@@ -126,6 +126,12 @@ Important information on this feature:
 - there is no check at creation / edition / deletion if the referenced variable doesn't exist
 - "inner replacements" are not supported (e.g VAR_1 = {{VAR_2}} and VAR_2={{VAR_3}} )
 
+You can easily insert existing variables by clicking on the magic wand icon and selecting your desired variables:
+
+<p align="center">
+  <img src="/img/configuration/variables/var_insert_magic_wand.png" alt="Variables" />
+</p>
+
 ## Naming Rules
 
 * Environment variable name should use only alphanumeric characters and the underscore character (_) to ensure they are accessible from all programming languages. Environment variable keys should not include the hyphen character.

website/docs/using-qovery/configuration/environment-variable.md.erb

@@ -123,6 +123,12 @@ Important information on this feature:
 - there is no check at creation / edition / deletion if the referenced variable doesn't exist
 - "inner replacements" are not supported (e.g VAR_1 = {{VAR_2}} and VAR_2={{VAR_3}} )
 
+You can easily insert existing variables by clicking on the magic wand icon and selecting your desired variables:
+
+<p align="center">
+  <img src="/img/configuration/variables/var_insert_magic_wand.png" alt="Variables" />
+</p>
+
 ## Naming Rules
 
 * Environment variable name should use only alphanumeric characters and the underscore character (_) to ensure they are accessible from all programming languages. Environment variable keys should not include the hyphen character.

website/docs/using-qovery/deployment/image-mirroring.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2024-07-11"
+last_modified_on: "2024-10-09"
 title: "Image Mirroring"
 description: "Learn how images are mirrored within your cloud account"
 ---
@@ -29,9 +29,9 @@ Every time an application needs to be deployed on your cluster, the application
 
 ## Application built via the Qovery pipeline
 
-Images within the mirroring registry are organized by "Qovery service", each service has its own repository (or namespace, naming depends on the cloud provider). This means that each service build and mirroring process is completely isolated from the others.
+Images in the mirroring registry are organized by Git repository. Each service, with identical build context parameters (commit ID, repository root path, Dockerfile path, Dockerfile content, and environment variables), is assigned its own repository, named z<short_cluster_id>-git_repo_name (or namespace, depending on the cloud provider). This ensures that each service's build and mirroring process is completely isolated from others.
 
-Before building the application A1, Qovery checks within mirroring registry at the repository of the application A1 if an image has already being built with the same version (commit id and environment variables). 
+Before building the application A1, Qovery checks within mirroring registry at the repository of the application A1 if an image has already being built with the build context parameters (commit id, repository root path, dockerfile path, dockerfile content and environment variables) within the same cluster. 
 
 If the image already exists, the built is skipped and Qovery starts the deployment of that image on the Kubernetes cluster.
 

website/docs/using-qovery/deployment/image-mirroring.md.erb

@@ -20,9 +20,9 @@ Every time an application needs to be deployed on your cluster, the application
 
 ## Application built via the Qovery pipeline
 
-Images within the mirroring registry are organized by "Qovery service", each service has its own repository (or namespace, naming depends on the cloud provider). This means that each service build and mirroring process is completely isolated from the others.
+Images in the mirroring registry are organized by Git repository. Each service, with identical build context parameters (commit ID, repository root path, Dockerfile path, Dockerfile content, and environment variables), is assigned its own repository, named z<short_cluster_id>-git_repo_name (or namespace, depending on the cloud provider). This ensures that each service's build and mirroring process is completely isolated from others.
 
-Before building the application A1, Qovery checks within mirroring registry at the repository of the application A1 if an image has already being built with the same version (commit id and environment variables). 
+Before building the application A1, Qovery checks within mirroring registry at the repository of the application A1 if an image has already being built with the build context parameters (commit id, repository root path, dockerfile path, dockerfile content and environment variables) within the same cluster. 
 
 If the image already exists, the built is skipped and Qovery starts the deployment of that image on the Kubernetes cluster.
 

website/guides/advanced/production.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2023-12-27"
+last_modified_on: "2024-10-08"
 $schema: "/.meta/.schemas/guides.json"
 title: Production
 description: Learn how to run your Production with Qovery