Steps for migrating a pipelinelib repo

Read the entry for the repo in integration/config/zuul/layout.yaml.
- If it has stages other than test, gate-and-submit, postmerge, or publish, then get help from Release Engineering. Otherwise proceed.
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

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

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-runners project.

Pipelinelib published images with a timestamped tag. Kokkuri uses the SHA1 of the commit that triggered the pipeline.

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 under 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, you could change the rules in .gitlab-ci.yml so that image build/publish only happens when a commit is tagged.

This article is issued from Mediawiki. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.