Re: Renamed .gitlab-ci.yml to disable CI builds (at least for now)
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
Reply to: