[15:33:23] 10GitLab (Auth & Access): Create subgroup for 'wikisp' - https://phabricator.wikimedia.org/T296110 (10brennen) I have created https://gitlab.wikimedia.org/people/volunteer-group-wikimedia-small-projects - please let me know at least one Wikimedia developer account that has been logged into GitLab and should have... [17:55:06] and the theory that caused me to ignore a minute or so of the meeting was https://en.wikipedia.org/wiki/Birds_Aren%27t_Real ! [17:55:17] birds have been replaced by drones .... [17:55:38] anyway for lot of repository the transition to gitlab is probably straightforward [17:55:57] the CI part is a bit worrying cause today it is more or less enforced / centrally managed [17:56:16] but that has its limits for sure [17:57:13] for mediawiki extensions it is probably not that complicated, lot of the test workflow has been ported to a standalone python command https://doc.wikimedia.org/quibble/ which knows which commands to run (though it is hardcoded with gerrit and our ci but we should be able to adjust) [17:57:51] for mediawiki + skins/extensions pushed to production, we have a few complicated workflow notably ensuring they always pass tests together [17:58:36] and a parent repository that has all the mediawiki repo registered as submodule and automatically updated by gerrit (but I guess that is hackable in gitlab by listening for events and manually bumping submodules) [17:59:09] and there is Zuul itself which test changes together to prevent breakage ( the concept is more or less explaned at https://zuul-ci.org/docs/zuul/discussion/gating.html ) [17:59:35] and if that workflow is dished out, we need to rethink how we develop mediawiki and extensions and specially how we do the integration testing of the result [17:59:41] or migrate to a mono repo [17:59:50] those are open questions for mediawiki ... future uncertain [18:36:30] we kinda discussed a mono repo on https://phabricator.wikimedia.org/T268283