.gitlab-ci.yml

 workflow:
   rules:
-    - if: '$CI_COMMIT_BRANCH == "staging" || $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
+    - if: >-
+        $CI_COMMIT_BRANCH == "staging"
+        || ($CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TITLE =~ /Merge branch 'staging' into 'main'/)
       when: always
     - when: never
 
@@ -123,6 +125,7 @@ create-release-tag:
   allow_failure: true
 
 deploy-new-staging-version:
+  extends: .gke-initialization
   stage: deploy
   needs:
     - 'build-image'

README.md

@@ -8,6 +8,9 @@ These branches are protected, meaning that commits targetting them will fail.
 Changes to the codebase are realized through the use of other temporary branches and Merge Requests to **staging**. Merge Requests to **main** should
 only be opened from **staging** as a source branch.
 
+# Workflow
+
+## Automated jobs
 As soon as a new change through a MR is commited to **staging**, the [pipeline](.gitlab-ci.yml) is triggered. It deploys the application to the **staging-todoapp-devops** namespace in a Kubernetes cluster, run on GKE. After that, the application is accessible in its test/pre-production version under the domain:
 
 > staging.todoapp-devops.software
@@ -19,5 +22,5 @@ The web application is then accessible in its production version under:
 
 ## Manual jobs
 
-The pipeline job `switch-to-https` should be manually triggered, after the app has been deployed. Due to Google's requirements, this process can only be triggered manually after the Google-managed Load Balancer is set up correctly and is operational.
+The pipeline job `switch-to-https` corresponds to an upgrade from HTTP to HTTPS regarding the "client <-> Google's external Load Balancer" connection. Due to Google's requirements, this process should be only manually initialized after the Google-managed Load Balancer is set up correctly and is operational. Therefore, this job is not automatically executed in the pipeline and can be started manually.