On 25/03/2022 15:58, David Caro wrote:
+100 for trying to get this going
Indeed, thank you!
On 03/25 14:44, Arturo Borrero Gonzalez wrote:
Hi there,
I've been playing this morning with gitlab.w.o and CI, and here is my proposal on how to work with it:
- have all gitlab-ci related stuff consolidated into a single repository
[0], this includes: ** generic gitlab-ci.yaml config files as required [1] ** Dockerfiles for the images used in the above gitlab-ci.yaml files [2]
This repository is now under common cloud, where volunteers (toolforge roots) don't have merge rights, should we have one per-project? Or the idea is to have several of this gitlab-ci.yaml files, like:
- python39_tox
- golang1_17
that sound good to me (though would be nice to make sure the volunteers of the given project are ok losing merge rights there). Random question, do they have MR rights to propose changes in that cicd repo? (/me is still a bit confused on what are the current rights).
I currently have 'owner' rights on /repos/cloud/*, and as far as I'm aware we can grant a few different access levels to an individual repository or a subgroup which applies to everything below it. Not as customizable as Gerrit allows, but should be good enough for our needs.
Gerrit has CI configuration in a centralized repo (integration/config) and requires production shell access in order to deploy updates, having it in a repo controlled by us is already an improvement.
Everyone can create a MR to any repository they can see by creating a fork I believe.
- in each repo that requires CI (likely all), instead of having to re-write
the gitlab-ci.yaml file every time, "include" it from the repo above. [3]
- due to upstream docker registry ratelimits, we need to do some heavy
caching in our docker registry (docker-registry.tools.wmflabs.org), which even involves scp the base docker image from ones laptop (something like [4]) because you can't even pull the base images at docker.io from tools-docker-imagebuilder-01.
Hopefully this would be come a bit easier once we have harbor.
Caching images on Toolforge registries sounds fine to me. Just note that by default everything available on docker-registry.tools.wmflabs.org is also available for Toolforge Kubernetes users.
To see a live demo/example of this, here is a successful tox job for a python 3.9 repository: https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-framework-api/-/jobs...
I prefer if we have our own CI/CD stuff in a separate repo/docker registry for now. I don't think there is a unified effort for this unlike in gerrit.
I think this kind of CI stuff is one of the main missing pieces that was previously preventing us from adopting gitlab for good.
PD: there are a bunch of things to automate here, like base image maintenance and such. Will wait to see if this proposed workflow is something we're interested in.
regards.
[0] https://gitlab.wikimedia.org/repos/cloud/cicd/gitlab-ci [1] https://gitlab.wikimedia.org/repos/cloud/cicd/gitlab-ci/-/blob/main/py3.9-bu... [2] https://gitlab.wikimedia.org/repos/cloud/cicd/gitlab-ci/-/blob/main/py3.9-bu... [3] https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-framework-api/-/blob... [4] https://stackoverflow.com/questions/23935141/how-to-copy-docker-images-from-...
-- Arturo Borrero Gonzalez Site Reliability Engineer Wikimedia Cloud Services Wikimedia Foundation _______________________________________________ Cloud-admin mailing list -- cloud-admin@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud-admin.lists.wikimedia.org/
Cloud-admin mailing list -- cloud-admin@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud-admin.lists.wikimedia.org/