Topic on Talk:GitLab/2020 consultation

The second of three listed "Why"s is easy and self-service continuous integration configuration.

This has indeed been a point of friction for many years. This wasn't related to Gerrit, but rather because we didn't resource/prioritise setting up something that could securely run unreviewed code for installing arbitrary packages and running arbitrary shell commands.

Between 2013 and 2015 we invested in this. We got rid of the hardcoded Jenkins jobs, and instead defer all package and command selection to a file in the source repository/branch, just like Travis CI and GitLab. These files are package.json, composer.json, Gemfile. Just like Travis, the entry point commands are just "npm install + npm test" or "composer install + composer test". Fully self-serviced.

There are some cases where for security or performance reasons, where we bypass the base image and instead provision something custom ahead of time for a specific repository. I assume this will still be possible in GitLab, and would require similar effort either way.

From an end-user perspective, what is the difference?

(I do want to recognise that RelEng currently spend significant time maintaining the Docker base images that drive this. I believe GitLab has similar preset images, that would save RelEng time. However, the consultation lists ease of use for end-users. And, of course, changing the backend of CI to GitLab was already approved months ago and is out of scope here. Also, whether we can/should use GitLab's base images remains to be seen since I believe we generally prefer to match OS and package backports with prod.)

From an end-user perspective, what is the difference?

I might take issue with your characterization of our current CI as "Fully self-serviced". Only 19 people out of all users of Gerrit can fully setup CI without any help.

---

I'm just going to stumble through getting something running as an experienced person at stumbling through the process.

GitLab

• Click "Set up CI/CD" on the repo
• Click the "Apply a template" dropdown
• Click "Commit changes" button
• Jobs run in CI

Current CI

• git clone ssh://gerrit.wikimedia.org:29418/integration/config.git
• $EDITOR zuul/layout.yaml -- grep around for "npm" and find repos using "reponame"-npm-node-6-docker
• git grep 'node-6-docker'
• $EDITOR jjb/job-templates.yaml -- There's a job-template that seems to do what I want...ok...got to use that template -- I'll git grep for projects using that template
• $EDITOR jjb/mediawiki-services.yaml -- there appear to be a lot of projects using the template I want here...maybe this is where I add my project:

  - {project: {name: 'tyler-test', jobs: {name}-npm-node-6-docker}}

• So that should create the job, now I need to add the job to the repo
• $EDITOR zuul/layout.yaml (again)

- {name: tyler-test, test: tyler-test-npm-node-6-docker}

• Send for code review
• self-merge (27 people can do this currently, including you and me)
• Deploy the job (19 people can do this currently, including you and me)
• Deploy a new zuul configuration (19 people can do this currently, including you and me)

This is the perspective when we already have the functionality to do something simple. As you mention adding new docker images (something only the same 19 contint-admins can do) adds complexity to this step. You need to add a new Docker image currently if you want to, say, install a library that your node project is using -- it's not uncommon.

I stumbled my way through to a working CI in gitlab without reading any documentation. I've been maintaining CI via zuul/jjb for 5 years and I still had to do a lot of grepping.

Once you've got your CI setup you can change things through the npm test entrypoint it's true, but this is different than what I mean by self-service CI.

I did not find the CI self-service setup easy on the GitLab test instance. If you look at https://gitlab-test.wmcloud.org/translatewiki.net/repong/-/commits/master it took me four commits to get it working. I could not do it without looking for a working example from another repo in the test instance. Possible caveat is that on the actual instance the images might be unrestricted, so the premade templates would actually work.

I found no way to actually test the pipeline without committing it to the repo first. Now there are bunch of useless and broken commits there in the history. Even if there is a way to test before committing, it is definitely not obvious as I spend a lot of time trying to find it.