[00:00:41] 10GitLab (Project Migration), 10Gerrit, 10Release-Engineering-Team (GitLab V: Event Horizon 🌄), 10User-brennen: Script closing/archiving of migrated repositories on Gerrit - https://phabricator.wikimedia.org/T330345 (10Dzahn) I wonder if we could make migrated Gerrit repos read-only and show that fact in t... [00:15:17] 10GitLab (Auth & Access), 10Infrastructure-Foundations, 10CAS-SSO, 10Release-Engineering-Team (GitLab V: Event Horizon 🌄), 10User-brennen: GitLab sessions expire frequently - https://phabricator.wikimedia.org/T330359 (10brennen) [00:15:34] ^ task re: needing to re-auth with gitlab a bunch. [00:15:52] i don't *think* anybody else had actually filed yet. [00:55:17] 10GitLab (Auth & Access), 10Infrastructure-Foundations, 10CAS-SSO, 10Release-Engineering-Team (GitLab V: Event Horizon 🌄), 10User-brennen: GitLab sessions expire frequently - https://phabricator.wikimedia.org/T330359 (10bd808) [01:31:39] ^ bd808: thanks for that. i always forget the irc highlighting exists. :) [06:49:43] 10GitLab (Integrations), 10Phabricator, 10Release-Engineering-Team (Priority Backlog 📥), 10User-brennen: Comment on Phabricator tasks for new, merged, and abandoned changes on GitLab - https://phabricator.wikimedia.org/T324150 (10hashar) >>! In T324150#8639102, @brennen wrote: >> I am reopening the task si... [08:50:16] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover: Switchover gitlab-replica (gitlab2002 -> gitlab1003) - https://phabricator.wikimedia.org/T329930 (10Jelto) >>! In T329930#8637828, @Dzahn wrote: > > I think T296944#8496308 is related here. Thanks for the link! We made sure we use the... [08:55:45] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover: Switchover gitlab (gitlab1004 -> gitlab2002) - https://phabricator.wikimedia.org/T329931 (10Jelto) [09:34:00] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover: Switchover gitlab (gitlab1004 -> gitlab2002) - https://phabricator.wikimedia.org/T329931 (10Jelto) [09:51:28] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover, 10Patch-For-Review: Switchover gitlab (gitlab1004 -> gitlab2002) - https://phabricator.wikimedia.org/T329931 (10Jelto) [09:51:56] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover, 10Patch-For-Review: Switchover gitlab (gitlab1004 -> gitlab2002) - https://phabricator.wikimedia.org/T329931 (10Jelto) [09:59:18] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover, 10Patch-For-Review: Switchover gitlab (gitlab1004 -> gitlab2002) - https://phabricator.wikimedia.org/T329931 (10Jelto) [15:55:40] 10GitLab (Infrastructure), 10serviceops-collab: Investigate gitlab maintenance/read-only mode - https://phabricator.wikimedia.org/T330277 (10eoghan) a:03eoghan We have a few options here to show varying levels of user experience. The deployment page is nice, but it alone doesn't block API calls or ssh writ... [16:27:45] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover, 10Patch-For-Review: Switchover gitlab-replica (gitlab2002 -> gitlab1003) - https://phabricator.wikimedia.org/T329930 (10eoghan) 05Open→03Resolved This was completed successfully yesterday and everything remains stable 24 hours lat... [17:11:48] something I have encountered earlier, I have cloned someone else repo https://gitlab.wikimedia.org/kharlan/earlywarningbot/ , made a commit and send it back as a new branch. I did receive a message pointing to a merge request form but that yields a 404 [17:12:03] and when browsing my branch on the web UI no merge reuqest is proposed [17:12:16] the fix was to delete the branch, fork the repo, send the branch on the fork and then do the merge request [17:12:36] I am guessing I was able to push a new change on the other person repo due to being an admin or having some special privileges maybe [17:12:47] that was Antoine confusion of the day [17:16:36] the workflow around this is a bit crap. [17:33:37] The split workflow of some users working on feature branches in the authoritative repo and some working on feature branches in forks is going to make all of our docs more confusing. I know it will annoy some, but I think we should promote the 'fork & merge request' model to everyone as the preferred way to work with a repo. [17:35:59] also having every open MR be a branch on the main repository is going to be incredibly messy [17:37:02] if there are for example N forks of mediawiki/core, will gitlab consume N times the disk space of a single checkout? or does it internally store the forks together? [17:38:48] I would really hope that it does sparse change mapping magic on the backend. GitHub 100% does. [17:39:52] https://docs.gitlab.com/ee/development/git_object_deduplication.html [17:42:16] Apparently reporting on the state of deduplication is an open issue upstream -- https://gitlab.com/gitlab-org/gitlab/-/issues/290226 [17:53:18] i want to say that thcipriani and i dug into this and it seemed like forks in gitaly were deduped at the time. [17:53:36] * brennen actually reads the linked doc [17:57:34] i've personally always found the fork as default workflow thing clunky in the extreme, but maybe it does make things less cluttered on a repo with a very large set of contributors. [17:57:42] i'm not sure i have a strong opinion, tbh. [17:59:33] forks are hardlinks on disk IIRC [17:59:45] meaning: takes inodes, but not disk space [18:29:04] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover, 10Patch-For-Review: Switchover gitlab (gitlab1004 -> gitlab2002) - https://phabricator.wikimedia.org/T329931 (10Jelto) I scheduled a [new broadcast message](https://gitlab.wikimedia.org/admin/broadcast_messages/7/edit) on GitLab for t... [18:41:49] 10GitLab (CI & Job Runners), 10serviceops-collab, 10Release-Engineering-Team (Radar): Cleanup and attach volumes for gitlab-runners WMCS project - https://phabricator.wikimedia.org/T328283 (10Jelto) a:03Jelto I deleted all unused volumes in the `gitlab-runners` project. This freed some storage/volume quota... [20:21:53] 10GitLab, 10Release-Engineering-Team (GitLab V: Event Horizon 🌄): Isito interferes with HTTP traffic from buildkitd build containers - https://phabricator.wikimedia.org/T330433 (10dancy) [20:30:42] 10GitLab, 10Release-Engineering-Team (GitLab V: Event Horizon 🌄): Isito interferes with HTTP traffic from buildkitd build containers - https://phabricator.wikimedia.org/T330433 (10dancy) [20:39:59] I think what struck me is that on https://gitlab.wikimedia.org/repos/releng/jenkins-deploy/ I have been sending my patches as a branch then doing a merge request, ie without forking. Then I guess it is because I have the developers right there [20:40:35] while on some other user repo ( in this case that was https://gitlab.wikimedia.org/kharlan/earlywarningbot/ ) , I don't have the developer rights and thus I guess I can't propose a merge request [20:40:40] but I can still send a new branch [20:41:05] anyway a fork solved it [20:41:38] on another topic, I have a hard time chaining patches so I gotta relearn to do small branches instead [20:42:08] and of course when I get unrelated stuff that depends on each other, that does not work, unless I send a merge request which is a bunch of assorted commits [20:42:25] or I get one of the other merge request to win the merge race and then gotta fix the conflict in the other merge request [20:43:01] I had the use case when doing two different/unrelated features which happened to hit the same area of code [20:44:00] I also have hard time finding to which commit a review comment is attached to, but I put that one on my confusion with regard to the web UI. I guess I will adjust with time [20:44:23] probably nothing unsolvable, but I am really having a bad time using it as a code review system :\ [21:03:08] It definitely takes some getting used to coming over from Gerrit. [21:26:51] Nearly all of the arguments that were made about Gerrit being a new thing for folks to learn here now apply to GitLab being a new things for folks here to learn. The workflows will be more like those that GitHub really brought to most of the development world, but they will be uniquely bent to fit a large collection of FOSS projects working on GitLab CE. [21:29:16] Gerrit's power user features like patch chains that are easily rebased, reordered, and separated are going to be missed by many of us for a very long time I imagine. [21:30:05] Collaborative patch editing is another huge Gerrit feature that I haven't seen a true replacement for in GitLab CE. [21:37:03] i would contest "easily", re: anything to do with patch chains, but i'll give you possible. [21:41:02] 10GitLab, 10Patch-For-Review, 10Release-Engineering-Team (GitLab V: Event Horizon 🌄): Isito interferes with HTTP traffic from buildkitd build containers - https://phabricator.wikimedia.org/T330433 (10dancy) Workaround deployed and operational. [21:47:09] 10GitLab (Infrastructure), 10serviceops-collab, 10Datacenter-Switchover, 10Patch-For-Review: Switchover gitlab-replica (gitlab2002 -> gitlab1003) - https://phabricator.wikimedia.org/T329930 (10Dzahn) Ah, cool, this is a nice explanation and outcome. Thanks! [21:57:27] 10GitLab, 10Patch-For-Review, 10Release-Engineering-Team (GitLab V: Event Horizon 🌄): Isito interferes with HTTP traffic from buildkitd build containers - https://phabricator.wikimedia.org/T330433 (10dduvall) Awesome! [22:52:28] brennen: likely a matter of familiarity :) When in deep development mode I quite commonly maintain chains of 5-10 patches while waiting for code review to land them. [23:02:18] yeah, most likely.