Hello, regarding the wikibase/termbox service -- we'd be fine with a move to gitlab but have a question for ourselves to find answer for and a (minor) change that would need to happen
question: there's some testing/CI set up in the wikibase/termbox repository which currently uses WMF's Jenkins to run tests etc. We'd like to have it replicated on Gitlab before we do the switch to be certain we do not put up broken code etc. I do not know as of now what is possible CI-wise on Gitlab but should find out.
additionally: wikibase/termbox code is included in Wikibase git repository on gerrit as a git submodule. When moved to github the submodule location reference should be changed. This does not seem like a big deal but I shall make a blocker task for it nonetheless, I figure?

cheers

Change 910439 had a related patch set uploaded (by Ilias Sarantopoulos; author: Ilias Sarantopoulos):

[mediawiki/extensions/ORES@master] feat: use Lift Wing instead of ORES

https://gerrit.wikimedia.org/r/910439

The old image suggestions api (mediawiki/services/image-suggestion-api) is unlikely to receive further development. The Jan 2023 update listed in the table above was a deployment-related housekeeping update by Ahmon that, while appreciated, does not indicate code maintenance or new development. It hasn't otherwise been touched in over a year, and probably won't be.

The only reason I'm aware of to even keep this service around is that it is used in Growth's default developer setup. Per Slack conversation with @Tgr , this could be switched to the anticipated new image suggestions api contemplated under T306349: Public-facing API for querying image suggestion recommendations and submitting user feedback, once such a thing is actually created.

Given all that, is it necessary to move this one to GitLab, or can it just hang out in Gerrit while it waits to die?

Change 912386 had a related patch set uploaded (by Ahmon Dancy; author: Ahmon Dancy):

[mediawiki/services/kask@master] Add .gitlab-ci.yml

https://gerrit.wikimedia.org/r/912386

Change 912386 merged by jenkins-bot:

[mediawiki/services/kask@master] Add .gitlab-ci.yml

https://gerrit.wikimedia.org/r/912386

Will the GitHub mirrors be switched over to replicate from GitLab? This is necessary for libraries like Shellbox that use a GitHub webhook to update Packagist.

In T332953#8809416, @tstarling wrote:

Will the GitHub mirrors be switched over to replicate from GitLab? This is necessary for libraries like Shellbox that use a GitHub webhook to update Packagist.

Mirroring is built-in to GitLab but at the repo level (go to https://gitlab.wikimedia.org/repos/<repo>/-/settings/repository to set up / manage). Automating the set-up of this is I think T321597.

However, for packagist auto-publishing I'd rather that instead of relying on this hack we migrate use to the in-repo controllable GitLab service integration (see https://gitlab.wikimedia.org/repos/<repo>/-/settings/integrations/packagist/edit).

Change 908563 abandoned by Ilias Sarantopoulos:

[mediawiki/extensions/ORES@master] feat: use Lift Wing instead of ORES for fetching scores

Reason:

has too much duplicate code - this work is now covered in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ORES/+/910439/

https://gerrit.wikimedia.org/r/908563

We do our development on github. Does it make more sense to restart with a new repository on gitlab to mirror that, or better to migrate?

In T332953#8819607, @Michaelcochez wrote:

We do our development on github. Does it make more sense to restart with a new repository on gitlab to mirror that, or better to migrate?

You must do a mirroring, else you would loose the development history from the original repository on GitHub. Something like:

git clone --mirror https://github.com/wikimedia/<your_repo>
cd <your_repo>
git add gitlab https://gitlab.wikimedia.org/repos/<path_to_repo.git>
git remote set-url --push gitlab git@gitlab.wikimedia.org:repos/<path_to_repo.git>
git push --mirror gitlab

Note: that creates a bare repository, there is no workspace files.

With that Gitlab fork you can create a new branch and work on the Pipeline integration there. Once ready for the switch, you would:

• resync the repositories (`git fetch --mirror origin; git push --mirror gitlab)
• in a local check out merge the branch having the Gitlab adjustements and merge that in the HEAD branch to catch up with changes made to the "upstream" GitHub repository.

Change 915541 had a related patch set uploaded (by Ilias Sarantopoulos; author: Ilias Sarantopoulos):

[mediawiki/extensions/ORES@master] feat: hardcode threshold calls to switch to Lift Wing

https://gerrit.wikimedia.org/r/915541

I've confirmed information related to analytics/datahub above.
Whilst we could move it as-is, the repository is currently very large as it is a fork of an upstream project.

There are several problems with the way that we currently maintain our build of datahub, so I have put in a blocker which is T303381: Review and improve the build process for DataHub containers.
Ideally, I'd like to be able to address some of these problems and reduce the size of the repository at the same time, rather than bring over the whole repository as it is.

Wow, sorry for the noise by referencing wrong ticket :)

In a project's .gitlab-ci.yml, it is now possible to publish documentation and test coverage results to doc.wikimedia.org using docpub.

You can find usage examples in the README and the scap repo.

If you're interested in using docpub in your new GitLab projects and would like a hand with it, please feel free to give me a shout!

When you're ready to publish your docs/coverage with docpub, your project members will need to be added to the docpub project in order for you to be able to trigger the downstream pipeline there.

As part of using docpub in your project, please reach out to me so I can add you. Other RelEng members can also help with this in case I'm not available.

Removing Search Platform, our work here is done.

In Gerrit / PipelineLib workflow, the PipelineBot makes a comment in Gerrit with the newly published image tag names, example. Are there plans to implement similar functionality for GitLab merge requests?