Hello, just chiming in there, it would be also great to be able to define this per service container, in case one has several of them per build job. For instance, for each test job, we have 1 mongodb service container requiring 0.5 cpu, and 2 others containers not as cpu hungry (a gcp pubsub emulator service container consuming 0.1 at best, and a redis container consuming even less). We end up autoscaling our Kubernetes nodes more than necessary, because while these are appropriate values for the first service container, it is definitely a waste for the other two.
I noticed the naming of the container was deterministic (svc-0 for the first service container, and so on), so maybe while this would take much more time and human resources to be able to control this directly through an enhancement of the services keyword in gitlab-ci.yml, maybe controlling this through aptly named environment variables could do the trick: KUBERNETES_SERVICE_CPU_REQUEST_0 or KUBERNETES_SERVICE_0_CPU_REQUEST and so on.
If KUBERNETES_SERVICE_CPU_REQUEST_N (where N == int) is defined then it will override the global (if defined) KUBERNETES_SERVICE_CPU_REQUEST for that service container or the runner defaults.
If KUBERNETES_SERVICE_CPU_REQUEST_N is not defined, it will use the current global defaults KUBERNETES_SERVICE_CPU_REQUEST or the runner defaults.
Hello, just chiming in.
Since !2108 (merged) already allows for global service/helper resources requests/limits overrides (let's hope it gets merged soon :) ), I started working from it to allow explicit service overrides in !2117 (closed)