Topic on User talk:BDavis (WMF)/Archive 2

Striker now creates GitLab repos and prior Diffusion repos have been migrated. More at https://lists.wikimedia.org/hyperkitty/list/cloud-announce@lists.wikimedia.org/thread/LSUIQGQ4DCHNDDIT54XMQ2FHK4E4DW3W/

Hey. Dropping this here because… well, because I have no clue where would be more appropriate. And the same goes for this ping: @TCipriani (WMF). On both counts: apologies for the possibly misdirected interruption. :)

Anyways… What's the story on Toolforge and the Wikimedia GitLab instance?

The context is that I recently "inherited" a tool on Toolforge where the single original maintainer is no longer active, and it's been untouched since 2015. Lot's of Python 2 -> 3, new pywikibot, cleanup of single-maintainer idiosyncrasies, general modernisation, etc. is the order of the day. And since the original code is in a personal Github repo: migrating to a new repo!

And then I get tipped off to the existence of GitLab / https://gitlab.wikimedia.org. And in my primitive "Monkey see goodie, monkey want goodie!" brain, that sounds like the best of all possible goodies: <s>no Gerrit</s>the features of Github, but integrated in the MW/WMF ecosystem (auth, not least).

But them docs… Going by the docs it looks like the WMF GitLab is both currently fully ready for production, we just need to move everyone over to it; and still in testing and we shouldn't put anything of value in it; and in some kind of early-adopter / use for personal stuff phase.

And nowhere, not in the docs not in the consultation, do I see Toolforge mentioned.

And Toolforge, to my mind, is the perfect case for this. Lots of contributors that would flat out refuse to use Gerrit no matter what incentive you gave them, can't be dictated to on such things in any meaningful way, but who we really really want to use version control somewhere we (we = the movement) have some sort of visibility and consistency. And Toolforge has lots of groupings (tools) with members (maintainers) etc., already managed through a management interface (Striker).

So when reading through GitLab/Policy I immediately think each "tool" on Toolforge should get a project (and default repo) on GitLab, either automatically or by checking a checkbox in toolsadmin. Maintainers of the tool should automatically be maintainers on the GitLab project. Toolforge should have its own namespace on GitLab, with sub-namespaces for each tool? Anyway, that sounds like it wouldn't just be sweet but even "sweeeet!", and clean up a lot of code access and revision control headaches for Toolforge.

So… Is anybody talking to somebody about Toolforge and GitLab?

Is GitLab ready for ad hoc use for Toolforge tool maintainers? And if so, how in the heck would I actually do that? Or should I just go to Github and plan to migrate later?

And nowhere, not in the docs not in the consultation, do I see Toolforge mentioned.

That's an excellent point.

So… Is anybody talking to somebody about Toolforge and GitLab?

Not explicitly. We should put it on the Roadmap somewhere, even if it's at the end.

Is GitLab ready for ad hoc use for Toolforge tool maintainers? And if so, how in the heck would I actually do that? Or should I just go to Github and plan to migrate later?

The GitLab Roadmap should be up-to-date.

I would say you can use GitLab for your own personal projects, but it's going to be missing some niceties for a bit. The current thing it's missing is shared runners for CI (you can setup your own, but that's not our plan for the future). Hopefully that will be solved Soon™.

You can sign in to GitLab with a Wikimedia Developer account and use it as you would Github (with the exception of having CI which I'm aware is a big exception and hopefully very temporary).

I don't think CI is going to be too relevant for most Toolforge projects (I may be wrong). Certainly not for mine: I need a git repo with a nice web frontend for managing merge/pull requests, browsing commits, etc.; and some way to add the other maintainers for the tool (as set in Striker). My biggest concern looking at the docs was fitting those needs within the policy for namespaces etc. and whether "personal" really means personal (I'm seeing a lot of "This is my .bashrc" there), or just "not ready for mediawiki/core yet". Toolforge tools are kinda somewhere inbetween those extremes.

But in any case… A. Nyone and S. Omebody needs to start talking about just how good friends Toolforge and GitLab are going to be, and figure out who does what and when it makes sense. Unlike Gerrit->GitLab, which has some pretty significant drawbacks for at least some people, Diffusion->GitLab for Toolforge looks like all upside from where I'm sitting. A quick win, and one that helps the community more in the short term than the big migration from Gerrit. Especially if Paladox is right that the conversion on the Striker side isn't all that complicated (cf. T224676).

phab:T224676 is probably the correct place to discuss. My personal answer is that yes gitlab and Toolforge should be friends, and this will eventually replace the current support built into Striker (https://toolsadmin.wikimedia.org/) for creating per-tool Diffusion repositories. What I cannot say at all today is when GitLab will be "ready" to take this usage and when anyone will have the time to work on integrating Striker with GitLab.

Striker now creates GitLab repos and prior Diffusion repos have been migrated. More at https://lists.wikimedia.org/hyperkitty/list/cloud-announce@lists.wikimedia.org/thread/LSUIQGQ4DCHNDDIT54XMQ2FHK4E4DW3W/