Technical Investigation: Codequality template job on gitlab.com shared runners is slow
Summary
In a technical investigation of CodeQuality execution time, we produced a runner configuration solution that works well for customers who host their own runners, whether they use self-hosted or SaaS GitLab. Because the runner configuration required is different than that permissible on the gitlab.com shared runners, the solution doesn't work for all customers.
We should consider another change that would help to speed up CodeQuality execution on our own shared runners. The savings via runner configuration are dramatic, so any similar improvement here has the potential to produce meaningful cost savings.
We should investigate what we can do with the dependency proxy on GitLab dot com, including interacting with ~"group::package" and Engineering Productivity to get their feedback on how we can best proceed to speed up CodeQuality and also reduce our hits to the Dockerhub repository, as in #283929 (closed).
Steps to reproduce
Include the CodeQuality template in a project CI pipeline. gitlab-org/gitlab for example.
What is the current bug behavior?
An analysis that should take less than a minute takes over twenty minutes, because it has to fetch several docker images.
What is the expected correct behavior?
A CodeQuality job execute in under 5 minutes. (@drewcimino made up this goal with no real basis)
Relevant logs and/or screenshots
We got this far with private runners. Inspiring stuff!
Proposal
We believe a read-through cache would achieve significant time savings. To that end,
- Find out if the dependency proxy can be used with gitlab.com shared runners as a cache.
- If not, find other potential arrangements that could serve as a read-through cache for CodeQuality and CodeClimate docker images.
We plan on being able to answer these two questions, but not implement anything, when we close this issue.