I'm working to get bluebuild working as a forgejo action with podman as the container handler. It seems like this might not be possible with the way the github actions are set up. I've converted the workflow to a forgejo workflow and made it so that it "should" upload images to the forgejo container registry. ### The issue I'm can't seem to get the action to complete. It looks like the workflow spawns a (separate) docker container on the github side behind the scenes which would then do the build. ### What I've tried I've set up a mapping from the podman socket to a docker socket in the runner, but that's not the container that is actually doing the build. I'm not sure how to do this. if I don't have that set up. Has anyone else tried doing something like this? If not, should I just stop trying?

message has been deleted

i have a forgejo server with actions set up so i should try this as well

Yeah I'm probably going end up going the custom build pipeline option. That's a bit down the road for me though, so if you come up with a solution quicker than me, I'd love to see it.

We do try to make the cli args easy to use

You can try to learn from this Gitlab example: https://gitlab.com/eu-os/workspace-images/eu-os-base-demo/-/blob/main/.gitlab-ci.yml?ref_type=heads

in case anyone is still looking for a forgejo workflow, this is what i am using. it simply uses the bluebuild cli image as job environment, installs nodejs (which is needed for the forgejo checkout action) and then just calls the bluebuild command. you do need to add a secret called CONTAINER_REGISTRY_TOKEN which contains a forgejo token with write:packages permission, because the automatically created token does not have permission to push packages to the registry. you also might have to change the label, since it defines the images in the workflow, it simply needs a label matching a runner with docker/podman capabilites. https://cdn.discordapp.com/attachments/1466236423160991826/1485228456693202964/build.yml?ex=69c26bca&is=69c11a4a&hm=56c572f6a4cd0bbe67855ec30f61f89f047d814ba3e07f11b1f588cf229c488a&

It looks like you are using docker and maybe dind for the internal container? If I wanted to use podman for this inner container, how would you go about solving the namespacing/(UID/GID) mapping issue for buildx?

yes, i am using dind and i am mounting the docker socket to the inner container (in the runner config.yml) container: options: "--volume /var/run/docker.sock:/var/run/docker.sock" i am not sure i understand your question though, is the problem that your host/runner is using podman and the job environment tries to run docker commands? If so, you could pass the hosts podman through to the job runner and install podman-docker in the job runner, so it emulates docker commands that actually run on your podman.sock

So my current setup uses podman inside the container and launches the podman daemon so that there is a socket to connect to. I would like to make this work or be able to mount my rootless podman socket inside the container to make that work instead. The way I have the host set up: - rootless podman creates socket which gets mounted to the runner as the $DOCKER_HOST. This works fine because the podman socket works the same as the docker socket. - Inside the build container, I need a socket, so I just run

podman system service -t 0

to get the socket at

/run/podman/podman.sock

The issues: - there seems to be an issue with the mapping of subuids and subgids and buildx gives this error:

potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/shadow)

I just tried mounting the socket into the container like you mentioned (but with the podman socket instead) but I think I'm missing where the socket actually is... - the runner systemd unit has

DOCKER_HOST=unix:///run/user/<uid>/podman/podman.sock

- Then in the workflow I have:

--volume /run/user/<uid>/podman/podman.sock:/run/podman/podman.sock

which doesn't properly mount... I'm not sure if I'm way overcomplicating things, but I was hoping to get this all done without the use of docker and dind.

i don't think you are over complicating things, but I am afraid I am not experienced enough to be able to help you. but a wild guess of mine would be to check permissions? podman runs rootless by default (afaik) and that might not allow it to use or mount the socket?

okay I made it run privileged and I was able to get a test script to run the podman container with the mounted socket. This worked, but as soon as I translated it to the forgejo workflow, it failed to mount. This is really frustrating as I have to push to the repo every time I want to test each iteration:

options: "--privileged --storage-opt overlay.ignore_chown_errors=true -v /run/user/<UID>/podman/podman.sock:/run/podman/podman.sock:rw"

also the env has DOCKER_HOST set to the

/run/podman/podman.sock

This is in the workflow ^ and it doesn't work. The script below does work though:

podman run --rm -it --privileged --storage-opt overlay.ignore_chown_errors=true -v /run/user/<UID>/podman/podman.sock:/run/podman/podman.sock:rw -v "${CI_WORKSPACE}:/workdir:Z" -w /workdir \
    -e DOCKER_HOST=unix:///run/podman/podman.sock ghcr.io/blue-build/cli:latest bash -c "... env vars ... bluebuild build ..."

Okay I found the issue: [/run/user//podman/podman.sock] is not a valid volume, will be ignored... Now I have to do some magic to solve it.