Run unit tests in the Kubernetes cluster

Georgi N. Georgiev | GitLabrequested to merge
ggeorgiev/migrate-jobs-to-k8s into main

What does this MR do?

Moves the Unit tests to run inside the Kubernetes cluster.

  • We used to run unit tests and unit tests with race
  • Both of these were split, so we ended up running 4 jobs
  • It turns out that the slow part is compilation, so splitting these tests has almost no benefit at this point
  • It also turns out that that adding -race to the test run has almost no difference in terms of execution speed. The difference is ~2 minutes

What's changed is that:

  • We run a single unit tests job with race detection on. This has a similar execution time of ~12-13 minutes as the jobs from before.
  • This is mostly since the execution of unit tests requires ~4 CPUs and 4Gi of RAM. 4 similar jobs will require more than one of our current k8s nodes with no benefits.
  • There's no prebuild job as it didn't bring benefits right now
  • The job has no cache right now [K8S Dogfooding] Setup GCS caching in the cluster (#38686) • Unassigned
  • We can experiment with prebuilding when we enable cache.
  • The splitic project was moved to runner tools with the changes in gitlab-org/ci-cd/runner-tools/splitic!1 (merged)

Infra MR: https://gitlab.com/gitlab-org/ci-cd/runner-tools/runner-kubernetes-infra/-/merge_requests/8

Why was this MR needed?

What's the best way to test this MR?

CI should pass.

What are the relevant issue numbers?

Related to #38460 (closed)

Edited by Georgi N. Georgiev | GitLab

Merge request reports