After running in act, host's nix-daemon is unusable

[Hoverbear]

It appears that after #59 the action runs something like the following inside of the runner:

docker
          --log-level=debug
          run
          --detach
          --privileged
          --userns=host
          --pid=host
          --mount
          type=bind,src=/tmp,dst=/tmp
          --mount
          type=bind,src=/nix,dst=/nix
          --mount
          type=bind,src=/etc,dst=/etc,readonly
          --restart
          always
          --init
          --name
          determinate-nix-shim-${this.correlation}
          determinate-nix-shim:latest

I am not sure it was intended, but in the case of docker-in-docker systems (like act) this appears to mount the /nix of the docker host.

In act, is the the user's host machine.

This creates the rather unfortunate situation where the host's Nix is unavailable after running the action:

[grahamc]

In a docker in docker situation, this should not be an issue. If act is passing the host’s docker socket in to the installer environment then that would cause it. Docker in docker provides the isolation needed for this to behave correctly, and is the environment it was built for.

…

On Tue, Jan 9, 2024, at 1:02 PM, Ana Hobden wrote: It appears that after #59 <#59> the action runs something like the following inside of the runner: docker --log-level=debug run --detach --privileged --userns=host --pid=host --mount type=bind,src=/tmp,dst=/tmp --mount type=bind,src=/nix,dst=/nix --mount type=bind,src=/etc,dst=/etc,readonly --restart always --init --name determinate-nix-shim-${this.correlation} determinate-nix-shim:latest I am not sure it was intended, but in the case of docker-in-docker systems (like `act`) this appears to mount the `/nix` of the docker host. In `act`, this the the user's host machine. This creates the rather unfortunate situation where the host's Nix is unavailable after running the action: image.png (view on web) <https://github.com/DeterminateSystems/nix-installer-action/assets/130903/a1f744a2-1f65-445b-bab6-2f941e8c1dad> — Reply to this email directly, view it on GitHub <#65>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAASXLFFLJMZV577XHUW2KDYNWA3LAVCNFSM6AAAAABBTQMNVGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3TEOBZGEYTCOI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Hoverbear]

Ahh perhaps that is what is happening!

[Hoverbear]

It does appear to be using a socket mount: https://github.com/nektos/act/blob/adbe229fcb34d8747297f824a8b465b01be3437a/pkg/runner/run_context.go#L1035

I guess we need to see if we can detect if it's true docker-in-docker or this socket-mount solution.