NixOS tests break when CI runs them in parallel #362
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
ambition
application-offering
ambition
configure-applications
ambition
front-end
ambition/install-applications
ambition
security
ambition
switch-host
ambition
update-applications
ambition
user-management
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#224 automated dev-ops workflows
fediversity/fediversity
#704 tests' memory metadata
fediversity/fediversity
Reference
fediversity/fediversity#362
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
as per @Niols, our NixOS tests often break because they're all running CI at the same time. a common symptom seems
Input/output error. options to address this seem to include:capacity1 so that it only ever takes one job. While slow, this would be better than CI failing altogether.many Proxmox VMs that each only accept one job, thothis might be excruciatingly slow.c.f. CI resource issues (#13)
CI comparison
nix-eval-jobsgradient(supports OIDC, not yet LDAP)apiKeyFilesbuildbotbuildbot-nix(MIT)buildbot-nixor (probably) gitea plugintest✅ thrunix-eval-jobsjenkinsservices.jenkins/services.jenkinsSlavehydraservices.hydranix-eval-jobsgitea/forgejorunnertho i did not get it to cancel on push-forcespindlewoodpecker/ crowflake-pipelinerdaggeragolaeka-cigarnixtyphonbuildkitemay be acceptable using gerrit (#302)?tokens depend on their proprietary platformbuildkite-forgejo-webhookhercules-cinix-cikiara referenced this issue2025-07-08 18:57:27 +02:00
kiara referenced this issue2025-07-27 08:55:56 +02:00
kiara referenced this issue2025-07-30 12:51:40 +02:00
kiara referenced this issue2025-08-04 22:02:23 +02:00
kiara referenced this issue2025-12-02 00:46:35 +01:00
kiara referenced this issue2025-12-14 19:11:35 +01:00
could maybe be fixed by using containers over VMs?
isolation approaches to try (given node access) short of switching CI:
ci-multi-runner- so far had builds not go thru over OOMs, retry after #721ci-microvm-runners- haven't had the hardware to test, 16 GB RAM seems not enough for our big tests while our CI node has 32 GB RAM.manually spinned up runner user services at
kingseem to no longer reproduce this issue - which perhaps the mentionedci-multi-runnerset-up could help reproduceci-multi-runnerdeployed again thru #919, let's seereflecting on this now, i wonder if this may have just been mostly about OOMs
with #13 this seems to just work, implying this indeed had been about resource constraints rather than a software issue. an anti-climatic resolution, but glad to see this finally resolved.
seems not fixed, e.g. https://git.fediversity.eu/fediversity/fediversity/actions/runs/48123/jobs/0/attempt/1 still fails on 'Bad file descriptor'
honestly this seems mostly kinda fine now?