[03:33:47] 10GitLab (Integrations), 10Wikibugs, 10Release-Engineering-Team (Priority Backlog 📥): Connect WikiBugs IRC bot to Wikimedia GitLab - https://phabricator.wikimedia.org/T288381#9712181 (10bd808) Getting [[https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#comment-events|comment]], [[https... [12:55:08] 10GitLab (CI & Job Runners), 06collaboration-services, 06Release-Engineering-Team: 14Define access to external resources for GitLab CI Runners - 14https://phabricator.wikimedia.org/T320730#9713150 (10Jelto) 05Open→03Resolved 14I think we are mostly settled about which runners have which kind of acce... [15:32:49] 10GitLab (Administration, Settings & Policy), 06collaboration-services, 06Release-Engineering-Team, 13Patch-For-Review: gitlab: enforce 2fa for admins - https://phabricator.wikimedia.org/T361277#9714043 (10LSobanski) a:03eoghan [15:32:55] 10GitLab (Administration, Settings & Policy), 06collaboration-services, 06Release-Engineering-Team, 13Patch-For-Review: gitlab: enforce 2fa for admins - https://phabricator.wikimedia.org/T361277#9714044 (10LSobanski) p:05Triage→03High [15:33:46] 10GitLab, 06collaboration-services, 06Release-Engineering-Team: GitLab archival by Software Heritage - https://phabricator.wikimedia.org/T362258#9714046 (10LSobanski) No concerns from #collaboration-services [15:51:08] dancy that's a pity, any chance we can use a squid or similar to do the caching? (could it be possible to use our own instance in cloud?) [15:51:40] I had to remove golangci-lint from our tests on ci because it was hanging too often [15:53:05] There's a section in the Gitlab docs about caching Go deps: https://docs.gitlab.com/ee/ci/caching/#cache-go-dependencies I'd like to know how that works out for you. [15:54:41] that looks really promising :), let me try it out [16:08:47] oh, got an authentication error from github? [16:08:49] fatal: could not read Username for 'https://github.com': No such device or address [16:08:53] actually dns sorry [16:09:28] not sure, it's confusing xd [16:09:30] https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-api/-/jobs/241273 [16:14:07] dcaro: that sounds like https://stackoverflow.com/a/40274775/8171, but the the question quickly becomes why would that `git fetch` trigger an auth prompt. [16:15:21] I think that github by default returns 401 for non-existing repos, to avoid repo listing [16:15:42] and I think there's a typo on the shellecheck repo in the pre-commit config [16:16:08] (looking on why it did not complain before) [16:18:35] when everything works, it works xd, ~1m https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-api/-/jobs/241282, 59s next run https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-api/-/jobs/241282 [16:18:49] not sure if it's using the cache though, as yesterday I also had runs in that order of magnitude [16:19:08] related: We probably could use a general solution like the "composer-github-oauthtoken" in jenkins that lets CI things in GitLab auth to github to increase rate limit ceilings. I'm not sure how possible it is in GitLab to setup a shared credential that is not easily exposed by an arbitrary job. [16:20:06] https://phabricator.wikimedia.org/rCICFe0982e0c4573e6dd32346d5e6499a881277f98d9 [16:22:01] that'd be nice yes, agree that sounds hard to not expose it if it needs being set for random MRs [16:27:47] Running it without the cache takes the same time now :/ [16:27:54] so maybe it's not doing much [16:28:01] (or I'm failing to use it) [16:33:22] yep, I added more commands (a couple echos) to the task, and they don't show up, I'm doing something wrong with the environment [16:39:11] it seems it got the cache this time :), it took 42 seconds (and said that it was getting the cache from some digitalocean url) [16:39:57] https://usercontent.irccloud-cdn.com/file/MxtoD0MR/image.png [16:49:16] I think I got the right combo now :), dancy that worked like a charm thanks! [17:02:05] yay! That's good news. [17:39:10] I just slapped together https://github-ratelimit.toolforge.org/ to give us a place to check the shared egress rate limit. See also https://docker-ratelimit.toolforge.org/ [17:43:24] @bd808 I thought at first, the way I read that, you get slapped with a rate limit [18:07:29] 10GitLab, 06collaboration-services, 10Release-Engineering-Team (Radar): GitLab archival by Software Heritage - https://phabricator.wikimedia.org/T362258#9714971 (10thcipriani) Reading the [[https://docs.softwareheritage.org/user/faq/#add-forge-now|faq]] answered all the questions I had. No concerns here either. [18:10:27] 10GitLab, 06collaboration-services, 10Release-Engineering-Team (Radar): GitLab archival by Software Heritage - https://phabricator.wikimedia.org/T362258#9714975 (10JJMC89) @LSobanski and @thcipriani Would you like me to respond to them or would you like to? [21:44:45] 10GitLab (Integrations), 10Phabricator, 10Wikimedia-Phabricator-Extensions, 13Patch-For-Review, 10Release-Engineering-Team (Yak Shaving 🐃🪒): Phabricator gitlab panel is hard to read on narrow screens - https://phabricator.wikimedia.org/T362047#9715644 (10CodeReviewBot) brennen merged https://gitlab.wikim... [21:47:24] 10GitLab (Integrations), 10Phabricator, 10Wikimedia-Phabricator-Extensions, 13Patch-For-Review, 10Release-Engineering-Team (Yak Shaving 🐃🪒): Phabricator gitlab panel is hard to read on narrow screens - https://phabricator.wikimedia.org/T362047#9715645 (10brennen) 05Open→03In progress We'll deploy @Ak... [21:49:44] has anyone else run into a situation where gitlab will _sometimes_ refuse to rebase a branch which has no obvious conflicts, and where rebasing manually works immediately? [21:50:28] error message of "Something went wrong. Please try again." [21:52:09] https://gitlab.com/gitlab-org/gitlab/-/issues/385359 mostly describes the behavior, but this seems to happen even for branches within the same repo (no fork involved), and more confusingly trying again does seem to work eventually in some cases. [23:31:03] brennen, dancy: after verifying that rejected users can sign up again without an extra hoops to jump through I have been rejecting all of the old accounts stuck in "pending approval" state. [23:31:51] This should send them emails saying they were rejected. I'm hoping that actually prompts the "real" people to try again and see the improved banners on how to finish the process. [23:41:58] 10GitLab (Account Approval): Correct and then approve https://gitlab.wikimedia.org/sethabathaba - https://phabricator.wikimedia.org/T353857#9715880 (10bd808) I was doing some other cleanup of pending GitLab accounts and I think I may have rejected the https://gitlab.wikimedia.org/sethabathaba account. Attempting... [23:44:33] 10GitLab (Account Approval), 06Release-Engineering-Team: Requesting GitLab account activation for safan41 - https://phabricator.wikimedia.org/T361018#9715882 (10bd808) I was doing some other cleanup of pending GitLab accounts and I think I rejected the https://gitlab.wikimedia.org/safan41 account. Logging in t... [23:51:33] bd808: good call, i think. [23:52:16] i suspect that will catch a handful of good-faith users, but probably not many. [23:56:17] I have disk logging setup for the gitlab-account-approval bot now too, so I should be able to find out what makes it fail so often. I have a hunch it will turn out to be LDAP, but maybe there will be some surprisingly busted thing that I can actually fix.