try out existing nix container made for gitea actions #405
No reviewers
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
3 participants
Notifications
Due date
No due date set.
Depends on
#356 reproduce CI runner
fediversity/fediversity
Reference
fediversity/fediversity!405
Loading…
Reference in a new issue
No description provided.
Delete branch "kiara/fediversity:ci-in-nix-docker"
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?
this proposal is to try out the first idea from #393 (comment), and may supersede #393.
this isn't to say we shouldn't want a more up-to-date container, altho it might help to validate the approach works.
part of #362.
EDIT: potentially superseded by #463
The CI didn't run; is that normal?
@Niols i retried but no dice. something does seem up. maybe the runner node does need to have the container manually downloaded first?
try out existing nix container made for gitea actionsto WIP: try out existing nix container made for gitea actionsWhat you use in
runs-onmust correspond to a label on the runner, so this will just hang. If you have a label that runs docker, you can use that label and override the image with:https://forgejo.org/docs/v1.20/user/actions/#jobsjob_idcontainer
cf658afa09fba8719923@ -11,3 +11,3 @@jobs:check-pre-commit:runs-on: nativeruns-on: nixUnless you've pushed the configuration to the runner, I think this should be
docker?9621aa56b13747bade28i.e. missing feature:
kvmthis seems to come down to either:
--device=/dev/kvm(e.g.containers.<name>.allowedDevices = [ { modifier = "rwm"; node = "/dev/kvm"; } ];/virtualisation.oci-containers.containers.<name>.devices = ["/dev/kvm:/dev/kvm"];)system-featuresattributekvmtonix.confin the image (implies rebuilding it and making sure the runner knows it):3747bade283e8c0c7738i tried a failed attempt (on a branch), yielding:
this triggers on compile failures over missing executables, in the nix context apparently over say
dockerTools.buildImage'sconfig.Cmd, which in the base image uses bash. while more info should be inoci-login podman's run-time directory (/run/podmanor in this case/run/user/1004/podman/), onforgejo-cithis unfortunately only still containspodman.sock.edit: this error does not occur when i override
config.cmd, so i believe the issue is i try to run a one-of command (or even empty) as a daemon, while really i just want a way to ensure the image is built ahead of CI looking for the container.3e8c0c7738d87b1ebd63WIP: try out existing nix container made for gitea actionsto try out existing nix container made for gitea actions563a5863e99a273cada1e011ef611064aa8049a7try out existing nix container made for gitea actionsto WIP: try out existing nix container made for gitea actionsa while after deploying this, half the step runs would fail on their checkout steps.
a failing step would just output this.
rather than this, for a successful checkout step.
not quite knowing the fix so far, i've deployed the
mainbranch's setup to the runner VM again.kiara referenced this pull request2025-07-08 18:57:27 +02:00
redeploying this reproduced the checkout problem.
while the parent directory of
/var/lib/gitea-runner/nix0/.cache/act/d071e2ae85e4660a/tmp/5b40f50f-9fff-45b8-a662-2c2d61c03d97/.gitconfigdid not yet exist,/var/lib/gitea-runner/nix0/.cache/actdoes.the line it gets stuck on, in line with the print, seems
await io.cp(gitConfigPath, newGitConfigPath).not understanding why, especially as earlier attempts appeared to work, maybe my best bet to resolve this would be trying to bisect the code involved.
WIP: try out existing nix container made for gitea actionsto try out existing nix container made for gitea actionstry out existing nix container made for gitea actionsto WIP: try out existing nix container made for gitea actionsswitching back from podman to docker seemed to fix this.
that said, i'm not sure the parallelization is as we expect tho: i see multiple steps of the same task run in parallel, tho i'm not yet sure if this works for multiple tasks in parallel yet.
edit: in fact it does, so this seems ready.
WIP: try out existing nix container made for gitea actionsto try out existing nix container made for gitea actionsfa902637fa95873fd960CI checkout failures at #456 still seem concerning, i may need to figure out what went wrong there - after re-deploying
mainto make it go thru.update: i hadn't managed this yet, due to an SSH permission denied error, so this still affects CI now.
edit: i can ssh in by
procolix@(i think this was something on my end), so deployedmainagain for now.Yes those are extremely weird
95873fd9605acbf0300dtried a run with log level
traceand the following superfluous litany of debug secrets:ACTIONS_RUNNER_DEBUG:trueRUNNER_DEBUG:1(moved to non-sensitive variables to prevent the Forgejo runner from substituting every1occurrence in the logs with***)ACTIONS_STEP_DEBUG:truecheckoutaction:GIT_CURL_VERBOSE:TrueGIT_TRACE:TrueGIT_SSH_COMMAND:ssh -vvv.. as per that run, the
checkoutactions had yet to trigger, altho the peertube test somehow seemed to fail without logging output whatsoever.on a rerun, the `checkout` issue triggered on at least the mastodon test, with the more verbose logs giving a better hint on the issue.
the few hints i can find about such a
deadline exceededseem to point in the general direction of https://github.com/moby/buildkit.trying to reproduce the checkout issue using 68b6e146f7160f9f99f2ea6bc3615c135d15a3f6, if that fails i can try and reploy 3d8d6269122f2106411c9c9d6a93e4135825116e to try and reproduce with that.
3d8d626912df4c184a51df4c184a5187486019cai did in fact run into this on that commit again, so now deployed the whole branch again to try that.
actually, that still triggers the checkout issue, so i've yet to really find a solution.
kiara referenced this pull request2025-07-26 18:29:28 +02:00
original ticket seems solved
Pull request closed