gitlab-org--gitlab-foss/doc/development/testing_guide/review_apps.md
2018-11-16 12:05:55 +02:00

4.8 KiB

Review Apps

Review Apps are automatically deployed by each pipeline, both in CE and EE.

How does it work?

  1. On every pipeline during the test stage, the review job is automatically started.
  2. The review job triggers a pipeline in the CNG-mirror project.
    • We use the CNG-mirror project so that the CNG, (Cloud Native GitLab), project's registry is not overloaded with a lot of transient Docker images.
  3. The CNG-mirror pipeline creates the Docker images of each component (e.g. gitlab-rails-ee, gitlab-shell, gitaly etc.) based on the commit from the GitLab pipeline and store them in its registry.
  4. Once all images are built, the Review App is deployed using the official GitLab Helm chart to the review-apps-ee Kubernetes cluster on GCP
  5. Once the review job succeeds, you should be able to use your Review App thanks to the direct link to it from the MR widget. The default username is root and its password can be found in the 1Password secure note named gitlab-{ce,ee} Review App's root password (note that there's currently a bug where the default password seems to be overridden).

Additional notes:

  • The Kubernetes cluster is connected to the gitlab-{ce,ee} projects using GitLab's Kubernetes integration. This basically allows to have a link to the Review App directly from the merge request widget.
  • The manual stop_review in the test stage can be used to stop a Review App manually, and is also started by GitLab once a branch is deleted.
  • Review Apps are cleaned up regularly using a pipeline schedule that runs the scripts/review_apps/automated_cleanup.rb script.
  • If the Review App deployment fails, you can simply retry it (there's no need to run the stop_review job first).
  • If you're unable to log in using the root username and password, you may encounter this bug. Stop the Review App via the stop_review manual job and then retry the review job to redeploy the Review App.

Frequently Asked Questions

Isn't it too much to trigger CNG image builds on every test run? This creates thousands of unused Docker images.

We have to start somewhere and improve later. Also, we're using the CNG-mirror project to store these Docker images so that we can just wipe out the registry at some point, and use a new fresh, empty one.

How big are the Kubernetes clusters (review-apps-ce and review-apps-ee)?

The clusters are currently set up with a single pool of preemptible nodes, with a minimum of 1 node and a maximum of 100 nodes.

What are the machine running on the cluster?

We're currently using n1-standard-4 (4 vCPUs, 15 GB memory) machines.

How do we secure this from abuse? Apps are open to the world so we need to find a way to limit it to only us.

This isn't enabled for forks.


Return to Testing documentation