2025-07-01 06:27:51 armhf and s390x gitlab shared-runners are failing to pull registry.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci:latest https://gitlab.alpinelinux.org/lotheac/aports/-/jobs/1915804 2025-07-01 10:42:43 seems to have recovered now. 2025-07-01 10:43:51 Yeah, I have just fixed it, thanks 2025-07-01 10:47:19 good timing :) 2025-07-01 10:47:31 thanks for fixing 2025-07-01 13:45:26 hello, could someone check on the edge loongarch64 builder? it may be stuck? 2025-07-01 14:13:53 in on it 2025-07-01 15:07:39 thanks! 2025-07-01 18:48:46 meow how does security.a.o get its branches? 3.22 is not yet fetched by it 2025-07-01 18:50:10 https://gitlab.alpinelinux.org/alpine/infra/docker/secfixes-tracker/-/blob/master/config/prod.settings.py 2025-07-01 19:01:27 ah 2025-07-01 19:01:28 https://gitlab.alpinelinux.org/alpine/infra/docker/secfixes-tracker/-/merge_requests/13 2025-07-01 19:21:38 achill: thanks! I deployed it now 2025-07-01 19:35:33 thank you! 2025-07-02 08:08:12 any reason it does not use releases.json? 2025-07-02 15:38:53 does somebody know why the log of the build failure on build-edge-aarch64 is 404? https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/py3-pytest-qt/py3-pytest-qt-4.5.0-r0.log 2025-07-02 19:58:39 lotheac: Testing your MR. It creates a runner, but the pod fails to run because (I guess the operator) set runAsNonRoot true 2025-07-02 19:58:41 Error: container has runAsNonRoot and image will run as root 2025-07-03 00:57:31 ikke: you can add pod.spec.containers.securityContext.runAsUser & runAsGroup to specify the uid/gid to run as 2025-07-03 00:58:01 (or remove the runAsNonRoot if you want to run as root) 2025-07-03 02:00:45 i suppose by default the operator expects an image that sets default uid to non-zero 2025-07-03 02:00:57 let me add a patch to that 2025-07-03 02:08:00 ikke: added patch to the runner.spec.podSpec to set runAsNonRoot=false. (not sure if the builds can handle running as non-root in the container -- if so we could do it the other way) 2025-07-03 03:57:16 also added a commit to reduce the privilege level of the controller-manager to be namespace-scoped 2025-07-03 13:53:52 could someone maybe check on the edge builders' logs? they're accessible, but logs for new builds don't seem to be updated at the moment? 2025-07-03 13:58:39 e.g. there is a package rebuilding today, but the log timestamp is from 01 Jul 2025 2025-07-03 15:06:27 distfiles disk was full, cleaning up 2025-07-03 15:34:08 thanks :) 2025-07-03 15:39:11 achill: ^ 2025-07-03 15:39:19 ohhh nice thanks! 2025-07-03 15:40:25 in other unrelated news, chromium source archives are huge 2025-07-03 15:45:20 surprise.... 2025-07-03 15:46:32 chromium everything is huge. source, build times, final packages, memory usage, build time memory usage, debug builds, 2025-07-03 21:35:54 uhhh now it looks like the websocket server of https://build.alpinelinux.org/ is down 2025-07-04 05:19:44 achill: fixed 2025-07-04 05:31:52 lotheac: thanks, note that it's currently the runner itself that apparently tries to run as root, not the build / helper image yet. 2025-07-04 05:33:28 docker run -it --rm --entrypoint /bin/sh registry.gitlab.com/gitlab-org/gitlab-runner:alpine-bleeding -c 'id -u' 2025-07-04 05:33:30 -> 0 2025-07-04 05:34:09 So strange that it sets runAsNonRoot to true while the image runs as root 2025-07-04 06:02:55 ikke I'm consistently getting HTTP 500 from GitLab when creating MR. is it just me? 2025-07-04 06:13:17 rnalrd: do you have up to date master branch in your fork? 2025-07-04 06:21:07 rebase from master branch 2025-07-04 06:32:31 ikke: oh huh, that is strange indeed 2025-07-04 06:34:06 lotheac: the fix is still the same 2025-07-04 06:42:31 yep pj 2025-07-04 06:45:16 ikke: for sure it is, but if their default image uses root as well then how is it working for anybody else either :thinking: 2025-07-04 06:51:15 Yes, same question here 2025-07-04 06:54:05 https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/238 2025-07-04 06:54:49 i guess the answer is "it's not" :) 2025-07-04 06:56:52 anyway good point about this not being the actual build image. maybe we could just run it as some other uid 2025-07-04 06:58:13 as in... patch runAsUser+runAsGroup instead of runAsNonRoot 2025-07-04 07:00:30 Note that the default helper image does assume root and hence our helper image as well 2025-07-04 07:13:52 sure. that’s probably fine (but i haven’t been able to verify what kind of pods the runner will actually create) 2025-07-04 07:15:44 I'll be testing that next 2025-07-04 10:26:39 lotheac: https://gitlab.alpinelinux.org/sertonix/aports/-/jobs/1919841 2025-07-04 14:34:48 ikke: can’t look very closely today, but when i looked at the operator i think it defaulted to assuming the builder pods would be in the same namespace as the runner pods 2025-07-04 14:36:06 (”gitlab-runner-system” by default iirc). if that is different, we need to modify rbac so it can do stuff in gitlab-ci ns as well 2025-07-04 14:36:44 s/we need/we probably need/ 2025-07-05 03:33:39 right, looks like i specified namespace: gitlab-ci in the runner objs 2025-07-05 03:42:31 i think the quickest fix is running the builders in gitlab-runner-system 2025-07-05 03:43:33 from a quick glance, i think maybe the operator tries to create a role in the target namespace for this purpose -- i think that's why it wanted the wide-open ClusterRole you noticed 2025-07-05 03:44:26 don't know how it would behave with a precreated role in the target ns -- or with a role in the target ns that allows it to create more roles there -- so i figure it's easier to get it running at all by just shoving it into gitlab-runner-system for now 2025-07-05 03:45:11 (ie. the same ns as the Runner objects) 2025-07-05 03:46:16 made that change in my MR 2025-07-05 20:19:01 seems we got some spammers on gitlab 2025-07-05 20:19:10 https://gitlab.alpinelinux.org/-/snippets/265#note_522606 2025-07-05 20:19:36 ptrc: constantly, I'm cleaning most of it up