GitLab/pipeline conversion
Please do not mark this page for translation yet. It is still being drafted, or it contains incomplete translation markup which should be fixed before marking for translation. |
|
Steps for migrating a PipelineLib repo
[edit]- 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.
If you have any trouble, get help from Release Engineering.
Differences between Gerrit pipelines and Gitlab CI pipelines
[edit]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
[edit]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.