@thcipriani Regarding the open questions

• Web-Team seems like the right tag for this
• Move vs Archive? definitely move
• Are there blockers for this migration?

I have a few questions about this migration in regards to the CI pipeline:

• Will the Jenkins Job wikimedia-portals-build have to be updates as part of this migration?
• How should the related repo, wikimedia-portals/deploy be handled? It's an output target of the Jenkins job, should it be migrated as well?
• If the`wikimedia-portals/deploy` repo is migrated to Gitlab, I assume the wikimedia-config repo will have to be updated too, since portals-deploy is a submodule there.

In T344743#9195733, @Jdrewniak wrote:

• Will the Jenkins Job wikimedia-portals-build have to be updates as part of this migration?

Jenkins is not used on GitLab. GitLab CI is used instead, so yes, the configuration needs not only to be updated, but to be basically rewritten (and moved to the wikimedia/portals repository).

• How should the related repo, wikimedia-portals/deploy be handled? It's an output target of the Jenkins job, should it be migrated as well?
• If the`wikimedia-portals/deploy` repo is migrated to Gitlab, I assume the wikimedia-config repo will have to be updated too, since portals-deploy is a submodule there.

Couldn’t job artifacts or deployment jobs be used instead? While .gitlab-ci.yaml contains shell commands, so it should be possible to replicate the current behavior, I find it strange to store build artifacts in a Git repository – the Git history doesn’t convey any information so long as the build is reproducible, so why fill disks with it?

Per the web team's quarterly grooming, these tasks are being removed from the team's backlog.

Will this ever happen, now that you’ve removed the only team tag from the task, and that Gerrit is no longer deprecated? While I still think that the existence of wikimedia-portals/deploy is strange, maybe a better solution could be found with the Gerrit/Jenkins setup, so maybe moving to GitLab isn’t worth the effort.