[00:41:03] 10GitLab (Project Migration), 10Release-Engineering-Team: Create new GitLab project group: 10nm - https://phabricator.wikimedia.org/T321022 (10Remagoxer) [00:42:34] 10GitLab (Project Migration), 10Release-Engineering-Team: Create new GitLab project group: 10nm - https://phabricator.wikimedia.org/T321022 (10Chlod) +1 on this. Confirming as project lead that Remagoxer has been allowed to file this task on behalf of the team. [12:15:22] <_joe_> jelto: do we have standardized pipelines on gitlab for e.g. a python project? [12:15:46] <_joe_> I guess the way to implement that is via a project template [12:19:14] 👀 [12:19:34] _joe_: as far as I know there are no such global templates. I only know some templates from security team under https://gitlab.wikimedia.org/repos/security/gitlab-ci-security-templates. But I can check with brennen and make sure there is at least a task for it. I'd like to have somethink like that too [12:20:57] we kind of started our own as well https://gitlab.wikimedia.org/repos/cloud/cicd/gitlab-ci [12:21:28] but never pushed hard to continue working with it [12:23:34] I used that one like this https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-framework-api/-/blob/main/.gitlab-ci.yml [12:46:07] <_joe_> jelto: I mean gitlab has this thing called project templates: https://docs.gitlab.com/ee/user/group/custom_project_templates.html [12:46:29] <_joe_> I was wondering if it wouldn't be a good idea to invest some time in creating templates for the various languages [12:46:39] <_joe_> frameworks/etc [12:49:06] _joe_: yeah that's definitely useful! But the linked feature is not available in the community edition 🤑 Anyway, I'll make sure we have a task for that [14:20:50] 10GitLab (Misc), 10Release-Engineering-Team (Seen): Gerritlab - https://phabricator.wikimedia.org/T300819 (10demon) 05Open→03Declined This would involve us continuing to add Change-Ids onto commits even on Gitlab? No no, we don't want to recommend that. They're ugly and pointless. [14:25:40] 10GitLab (Integrations), 10Release-Engineering-Team (GitLab II: Wrath of Kahn 👾): GitLab integrations: the Gerrit & Jenkins integration catalog - https://phabricator.wikimedia.org/T319359 (10demon) [14:40:22] _joe_: The release engineering team is currently working on building a standard pipeline. [14:41:32] <_joe_> dancy: I think a template will incorporate that long-term for the CI part, but a project template is more than that. Anyways I'll look into how to add our own templates to gitlab and maybe make a proposal [15:39:47] _joe_, jelto: T319322 [15:39:48] T319322: Create repo in GitLab for shared pipeline code - https://phabricator.wikimedia.org/T319322 [15:43:45] oh great thanks for pointing me to the task! [15:44:31] 10GitLab (Infrastructure), 10serviceops-collab: Migrate gitlab-test instance to bullseye - https://phabricator.wikimedia.org/T318521 (10LSobanski) [15:44:54] 10GitLab (Infrastructure), 10serviceops-collab: Setup alerting for GitLab projects size limits - https://phabricator.wikimedia.org/T316553 (10LSobanski) [15:45:01] 10GitLab (Integrations), 10Release-Engineering-Team (GitLab II: Wrath of Kahn 👾): GitLab integrations: the Gerrit & Jenkins integration catalog - https://phabricator.wikimedia.org/T319359 (10demon) [15:45:05] 10GitLab (Administration, Settings & Policy), 10serviceops-collab: Configure a default cleanup policy for GitLab package registry - https://phabricator.wikimedia.org/T315877 (10LSobanski) [15:45:14] 10GitLab (Infrastructure), 10Data-Persistence-Backup, 10serviceops-collab, 10User-brennen: Setup partial backups for GitLab - https://phabricator.wikimedia.org/T316935 (10LSobanski) [15:45:51] 10GitLab (Project Migration), 10Phabricator, 10serviceops-collab, 10Epic, and 3 others: Migrate active repositories in Phabricator Differential to GitLab - https://phabricator.wikimedia.org/T191182 (10LSobanski) [16:41:37] <_joe_> brennen: am I remembering incorrectly or gitlab has a sort of npm proxy, btw? [16:42:24] <_joe_> my dream is one day we force nodejs builds to only access packages that have been imported onto a local npm instance [16:42:34] https://gitlab.wikimedia.org/help/user/packages/package_registry/index [16:42:47] <_joe_> does that work for npm? cool [16:42:59] it's on the list. i _really_ have not investigated this in any depth. [16:43:03] <_joe_> that's like 99% of our attack surface in terms of supply-chain attacks [16:43:13] I'll post an update to T320730 tomorrow and start working on the two allowed images list [16:43:14] T320730: Define access to external resources for GitLab CI Runners - https://phabricator.wikimedia.org/T320730 [16:43:24] <_joe_> brennen: heh NO PRESSURE [16:43:26] that sounds like a stressful dream, _joe_ :) mine are usually about my teeth falling out [16:44:16] <_joe_> dduvall: it's more stressful to think we're running 1e12 different nodejs packages in production and that every single one of them could be an attack vector [16:44:49] haha, true [16:44:59] but which one? [16:45:23] on a serious note, i'm very interested in working on a supply chain signing system [17:09:09] <^demon> _joe_: The registry in Gitlab is _not_ a proxy for upstream NPM, it's just for packages we publish. So if we wanted to only pull from our hosted packages, we'd need to mirror the entire dependency tree for all packages we utilize. Likely, something à la Verdaccio is a better solution -- https://verdaccio.org (n.b.: I setup & ran an install of this before) [17:14:53] <_joe_> ^demon: if I go past the unfortunate name (literally "ugly green" in italian :P) it seems interesting [17:16:03] <_joe_> if it can be integrated with security scanning tools, it's exactly what I was thinking of [17:17:26] <^demon> Name is unfortunate, yes. And I'd have to look to see but I can't imagine why not :) [17:18:34] <_joe_> it seems the focus is more on availability [17:20:32] <_joe_> but I would guess it would be possible to check every package requested from the client for vulnerabilities and fart back an error if a package with known vulnerabilities is requested [17:21:31] <_joe_> but yes, something along these lines (my dream would be something with the capabilities artifactory has, but that's a commercial product sadly) [17:24:03] <^demon> I came across a project sorta like this.... lemme dig it up [17:32:20] <^demon> Oh yeah: https://pulpproject.org/ [17:33:59] <^demon> Oh, it does python and node and maven just not npm :\ [17:54:11] 10GitLab (CI & Job Runners), 10Release-Engineering-Team, 10serviceops-collab: Define access to external resources for GitLab CI Runners - https://phabricator.wikimedia.org/T320730 (10dduvall) Follow up from the meeting re: === Images that BuildKit uses for internal operations === Our Blubber BuildKit front... [18:14:41] 10GitLab (CI & Job Runners), 10Release-Engineering-Team, 10serviceops-collab: Define access to external resources for GitLab CI Runners - https://phabricator.wikimedia.org/T320730 (10dduvall) Current contents of `docker/dockerfile-copy:v0.1.9@sha256:e8f159d3f00786604b93c675ee2783f8dc194bb565e61ca5788f6a6e9d3... [18:48:54] 10GitLab (Project Migration), 10Release-Engineering-Team (GitLab II: Wrath of Kahn 👾): Create repo in GitLab for shared pipeline code - https://phabricator.wikimedia.org/T319322 (10dduvall) 05In progress→03Resolved The kokkuri project's `.gitlab-ci.yml` illustrates (and tests) the `.kokkuri:build-image` jo... [23:27:43] 10GitLab (Project Migration), 10Release-Engineering-Team (GitLab II: Wrath of Kahn 👾), 10User-dduvall: Migrate Blubber project to GitLab - https://phabricator.wikimedia.org/T301168 (10dduvall) [23:27:58] 10GitLab (Project Migration), 10Release-Engineering-Team (GitLab II: Wrath of Kahn 👾): Build and Run Blubber test variant on GitLab untrusted runners - https://phabricator.wikimedia.org/T307536 (10dduvall) 05Open→03In progress p:05Triage→03Medium a:03dduvall