Hi Laura, On Sun, Nov 25, 2018 at 09:27:19PM +0100, Laura Arjona Reina wrote: > Hello all > We've been told that the webwml CI builds in Salsa use too much > resources, affecting Salsa's ability to serve other users.
That's not good, obviously. How are we overdoing it? E.g., are we using too many runners, or are we using too much space for artifacts? > Currently the use of shared runners is disabled (see Settings > CI in > Salsa webwml project), and I have renamed the .gitlab-ci.yml file to > README_CI.gitlab-ci.yml and added an explanation inside the file (see > the paragraph added below): [...] > We can also discuss in which cases it's reasonable to enable the CI > setup for the team repo, and how (apart of renaming the file back and > forth?). Some things that spring to mind: - We could install a project-specific runner on a machine that is owned by (a member of) the webmaster team. That way we don't overload the shared runners. This would not help much if the main problem is the overuse of artifacts, though. - We could disable artifacts altogether, and use some custom deployment instead (e.g., on www-staging.debian.org). This would require that translations are able to be built when English is not built, however; I'm not sure if that's the case currently. It also ignores the shared runners issue (if that exists). Obviously the two methods could be combined if necessary. - Please note that with gitlab CI, it's also possible to specify on which branches the runner should do nothing. That way, we can tell it to ignore the master branch, but build it everywhere else. It would then still be used for merge requests, without a need for renaming the file over and over again. I think this would be more useful as an intermediate solution than the current "disabled everywhere" thing. Regards, -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
