[12:25:43] 10GitLab, 10Accessibility: Gitlab announce banner / broadcast message are unreadable due to dark background - https://phabricator.wikimedia.org/T330496 (10hashar) [12:34:12] 10GitLab, 10Accessibility: Gitlab announce banner / broadcast message are unreadable due to dark background - https://phabricator.wikimedia.org/T330496 (10hashar) [17:24:41] 10GitLab, 10Accessibility: Gitlab announce banner / broadcast message are unreadable due to dark background - https://phabricator.wikimedia.org/T330496 (10bd808) I think this is caused by a regression that has been documented upstream: https://gitlab.com/gitlab-org/gitlab/-/issues/386736. Fixing looks to be bo... [18:17:19] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover, 10Patch-For-Review: Switchover gitlab (gitlab1004 -> gitlab2002) - https://phabricator.wikimedia.org/T329931 (10eoghan) [20:29:28] 10GitLab (Misc), 10Accessibility, 10Upstream: Gitlab announce banner / broadcast message are unreadable due to dark background - https://phabricator.wikimedia.org/T330496 (10brennen) For what it's worth, GitLab admins can adjust the messages here: https://gitlab.wikimedia.org/admin/broadcast_messages I thi... [21:25:04] I thought, maybe incorrectly, that we weren't going to allow people to use GitLab issues? and instead mandate the use of Phabricator? [21:26:27] that was discussed at some point [21:27:15] something in the back of my head says that issues were disabled by default for all repositiories, but that there might not be a way to prevent them from being turned back on [21:27:40] https://phabricator.wikimedia.org/T264231 [21:28:02] strike that, reverse it [21:28:46] * legoktm comments [21:30:19] 10GitLab (Administration, Settings & Policy), 10Release-Engineering-Team (Radar), 10Upstream, 10User-brennen: Investigate whether issues, operations, wikis, etc. can be disabled globally on GitLab - https://phabricator.wikimedia.org/T264231 (10Legoktm) This ticket mostly discusses the technical implementat... [21:30:28] thanks for finding [21:31:48] please tell me we dont already have open issues [21:33:43] a) we have an exception for [i forget which team, probably research folks]. [21:34:01] b) as a practical matter, i haven't scheduled the script that runs against all repos anywhere. [21:34:38] ok, a) is what I found, leading to my question. https://gitlab.wikimedia.org/repos/research/html-dumps/ [21:35:09] c) my appetite for opening this can of worms is non-existent, but sooner or later we're probably going to have a conversation about whether we can realistically keep using phabricator, and whether gitlab issues are our only real alternative to whatever SaaS solution a large managerial contingent would probably prefer. [21:37:48] yep :( [21:38:05] i suppose an addendum to that last one is just that if we're being realistic, people are already tracking issues in about 87 different places besides phabricator. i couldn't begin to guess what all beyond asana, github issues, sundry spreadsheets, and random checklists on google docs, but you know it's a longer list than that. [21:38:38] mhm [21:39:53] phabricator was introduced to _stop_ that we were using all these different task trackers. it was sold to us to replace Bugzilla and RT [21:40:04] https://www.mediawiki.org/wiki/Project_management_tools/Review back in 2013-2014 was the process that led us to Phabricator in the first place, it feels many of the problems outlined there have come back [21:40:09] heh, jinx [21:40:10] 10GitLab (Administration, Settings & Policy), 10Release-Engineering-Team (Radar), 10Upstream, 10User-brennen: Investigate whether issues, operations, wikis, etc. can be disabled globally on GitLab - https://phabricator.wikimedia.org/T264231 (10brennen) > This ticket mostly discusses the technical implement... [21:40:37] now removing it with the reason that we are "using so many different systems anyways" and then non-free Asana.. is just... [21:41:22] i want to be clear that nobody is removing anything, and if i were going to personally work on migrating away from phabricator it would not be because people are already using x, y, or z thing. [21:41:23] * legoktm quickly stuffs worms back in the can [21:41:44] but we should probably be honest with ourselves that either phabricator will require an investment of resources in phorge [21:41:50] gitlab can barely support existing code review workflows, it certainly can not replace existing task management workflows [21:41:51] or we're going to have to do something else eventually. [21:42:04] unrelatedly, good discussion happening at https://wikis.world/@LucasWerkmeister/109921695224848444 [21:42:14] and if it comes to a question of something else, a great many people have preferences that we might not like. [21:42:30] feels like we are going to end up with 2 code review systems AND 2 task trackers [21:43:39] brennen: so from my read of https://wikitech.wikimedia.org/wiki/GitLab/Phabricator_integration it seems that GitLab *can* send webhooks to Toolforge tools, and that if I set up a webhook receiver for wikibugs, it could get the full firehose? [21:43:43] all to fix a problem with CI [21:44:49] legoktm: yeah, that's what we're doing for that tool. [21:44:52] 10GitLab (Misc), 10Accessibility, 10Upstream: Gitlab announce banner / broadcast message are unreadable due to dark background - https://phabricator.wikimedia.org/T330496 (10hashar) [21:45:02] if somebody's about to tell me that's a policy violation i guess we'll have to house it differently. [21:45:16] once an exception has been made it seems very very unlikely it's not going to be standard [21:47:12] brennen: historically there has been a firewall between prod and WMCS, but some services do cut in the middle, like Jenkins->CI runners (in WMCS). GitLab seems like one of the exceptions that make sense because it's effectively replacing Jenkins [21:48:08] yeah. this felt safe to us in that it's not something that writes back to gitlab. [21:48:19] I remember trying to do Gerrit webhooks with ^d but it didn't work out because of the firewall and none of us wanted to figure out if we could get an exception, but given that GitLab already has the whole it makes sense [21:48:21] (from toolforge, that is.) [21:48:51] it maybe _is_ something that gives me a little extra pause if people want to put stuff in private repos on gitlab. [21:49:06] although that's not an aspect i've really explored the implications of. [21:49:52] ok! this is great, I'll figure out how to write the webhook receiver and munge GitLab events into IRC updates. And see whether I can get away with writing it in Rust instead of Python.... [21:50:28] which is why we should definitely not just enable private repos casually, we have warned about this [21:51:26] legoktm: that would be awesome. [21:51:34] in Gerrit there are "private" repos (infamously the Transparency Report), but wikibugs via stream-events can see everything, but I think we have some fail safe to prevent broadcasting them [21:51:40] it's long been on our list, we just have kind of been kicking the can a bit down the road on it. [21:52:52] 10GitLab (Misc), 10Accessibility, 10Upstream: Gitlab announce banner / broadcast message are unreadable due to dark background - https://phabricator.wikimedia.org/T330496 (10hashar) >>! In T330496#8644707, @bd808 wrote: > I think this is caused by a regression that has been documented upstream: https://gitla... [21:53:48] legoktm: one thing to note, we pointed https://gitlab.wikimedia.org/repos/releng/gitlab-phabricator/ at a "system hook", there are some subtle differences between what's available to project/group-level hooks and the system ones, if i remember right, but lemme know if i can help with that. [21:54:14] 10GitLab (Integrations), 10Wikibugs, 10Patch-For-Review, 10Release-Engineering-Team (Priority Backlog 📥): Connect WikiBugs IRC bot to Wikimedia GitLab - https://phabricator.wikimedia.org/T288381 (10Legoktm) a:03Legoktm Discussed with @brennen today in `#wikimedia-gitlab`. Based off the existing GitLab/Ph... [21:54:33] ack [21:59:16] 10GitLab (CI & Job Runners), 10Release-Engineering-Team (GitLab V: Event Horizon 🌄): Isito interferes with HTTP traffic from buildkitd build containers - https://phabricator.wikimedia.org/T330433 (10brennen) [21:59:18] 10GitLab (Misc), 10Release-Engineering-Team, 10Upstream: Gitlab message after push point to a 404 merge request URL when not logged in - https://phabricator.wikimedia.org/T324262 (10brennen)