GitLab/pipeline conversion

Policy Workflows Project setup assumptions Registering an account on GitLab Hosting a project on GitLab Pipeline conversion Mirroring projects Configuring CI Publishing documentation Code review Making a merge request Squashing Managing security patches Deploying services to production Gerrit to GitLab Localization updates wikitech:GitLab GitLab implementation

Steps for migrating a PipelineLib repo

1. Use pipeline-to-gitlab to convert .pipeline/config.yaml into .gitlab-ci.yml:

   $ curl -sSf https://gitlab.wikimedia.org/repos/releng/pipeline-to-gitlab/-/raw/master/pipeline-to-gitlab | python3 - .pipeline/config.yaml > .gitlab-ci.yml
   

2. Perform any desired cleanup on the generated file, such as renaming jobs and stages, removing redundant jobs, etc.
3. Commit and push new .gitlab-ci.yml to GitLab.

If you have any trouble, get help from Release Engineering.

Differences between Gerrit pipelines and Gitlab CI pipelines

pipeline stage	Gerrit	GitLab
test	A job that runs every time a patchset is created/updated.	A job that is run for every push to the non-default branch (typically used by merge requests).
gate-and-submit	A job that runs before a change is merged. The job runs while other merges to the repo are blocked. This ensure that when the job completes, the result of the merge will be exactly what was tested.	GitLab does not have a corresponding concept (at least one that is accessible in our edition of GitLab). The closest thing to this is configuring your repo so that the default branch is protected, the merge method is set to Fast-forward merge (or Merge commit with semi-linear history ), and "Pipelines must succeed".
postmerge	A job that runs after a change is merged.	A job that runs when a change is merged into the default branch of the repo (if it is protected)
publish	Same as postmerge. Runs after.	Same as postmerge. Runs after.

Changes to publishing container images

If your project intends to publish an image to be used in production, it must be built using Kokkuri and Blubber and the project added to the gitlab-trusted-runner project.

Registry paths for images are different when published from GitLab. In the simplest terms, if your GitLab repo is at https://gitlab.wikimedia.org/x/y/myrepo, you can publish container images at docker-registry.wikimedia.org/x/y/myrepo and below.

You will need to update image paths in the places where you use them (most likely in the operations/deployment-charts repo). Use CodeSearch to search for the old image name.

You may want to change when an image is published (e.g., so that it's not every time there's a merge into the default branch). For example, a good approach is to change the rules in .gitlab-ci.yml so that image build/publish only happens when a protected tag is created.