determinatesystems / nix-installer-action Goto Github PK

Howdy,

Thanks for your work on nix-installer and this action! I'm rooting for the success of both projects 🙂

I noticed the readme recommends supplying the github-token input, otherwise "you will likely get rate limited."

Have you considered defaulting github-token to the github.token value from the github context? This would improve the ergonomics of using the action:

    - name: Install Nix
      uses: DeterminateSystems/nix-installer-action@main

though it would change the semantics of the current implementation. I'm not sure how strongly the maintainers feel about keeping the current behavior, which makes it possible to avoid authenticated requests.

Though, one option would be to explicitly opt out of authenticated requests, maybe with an input like:

    - name: Install Nix
      uses: DeterminateSystems/nix-installer-action@main
      with:
        github-token: ""

or

    - name: Install Nix
      uses: DeterminateSystems/nix-installer-action@main
      with:
        use-unauthenticated-requests: true

What do you think? I'm happy to open a PR if this aligns with the direction of the project.

Cheers!

Is there a comparison between the different installer actions?

I'd like to know what I gain or loose by using this action over eg. the one by cachix.

sudo is used to set up KVM (even when KVM isn't present, like with ACT, like on forgejo/gitea actions).

Installing it makes the action work, but folks on the Discord told me it shouldn't be required so, here's your issue to track it!

From discord, heres the output when running nix-installer-action via act (on the fully-featured image):

[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   💬  ::debug::download complete
| Detected `$ACT` environment, assuming this is a https://github.com/nektos/act created container, set `NOT_ACT=true` to override this. This will change the setting of the `init` to be compatible with `act`
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   💬  ::debug::Execution environment: {%0A    "NIX_INSTALLER_NO_CONFIRM": "true",%0A    "NIX_INSTALLER_DIAGNOSTIC_ATTRIBUTION": "GH-c47505c2-696f-4673-90c7-c17aedf358eb",%0A    "NIX_INSTALLER_MODIFY_PROFILE": "true",%0A    "NIX_INSTALLER_DIAGNOSTIC_ENDPOINT": "https://install.determinate.systems/nix/diagnostic",%0A    "NIX_INSTALLER_INIT": "none",%0A    "NIX_INSTALLER_START_DAEMON": "true",%0A    "NIX_INSTALLER_EXTRA_CONF": "trusted-users = root root\n"%0A}
| [command]/tmp/0e573188-ff00-4f89-8af9-d52b236b2898 install linux
|  INFO Step: Create directory `/nix`
|  INFO Step: Provision Nix
|  INFO Step: Create build users (UID 30000-30032) and group (GID 30000)
|  INFO Step: Configure Nix
|  INFO Step: Create directory `/etc/tmpfiles.d`
|  INFO Step: Leave the Nix daemon unconfigured
|  INFO Step: Remove directory `/nix/temp-install-dir`
|  WARN SelfTest([ShellFailed { shell: Sh, command: "\"sh\" \"-lc\" \"nix build --no-link --expr \\'derivation { name = \\\"self-test-sh-1701955359511\\\"; system = \\\"x86_64-linux\\\"; builder = \\\"/bin/sh\\\"; args = [\\\"-c\\\" \\\"echo hello > \\\\$out\\\"]; }\\'\"", output: Output { status: ExitStatus(unix_wait_status(512)), stdout: "", stderr: "sh: 10: .: cannot open /etc/skel/.cargo/env: No such file\n" } }])
| Nix was installed successfully!
| To get started using Nix, open a new shell or run `. /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh`
| 
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   ❓  ::endgroup::
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   ❓  ::group::Configuring the Docker shim as the Nix Daemon's process supervisor
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   💬  ::debug::Loading image: determinate-nix-shim:latest...
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   💬  ::debug::Loaded image: determinate-nix-shim:latest
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   💬  ::debug::Starting the Nix daemon through Docker...
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   💬  ::debug::07b80d704386e4f1b51c620ae47f21f2b165f49450c37c053b82dae2d663290f
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   💬  ::debug::docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/nix/var/nix/profiles/default/bin/nix-daemon": stat /nix/var/nix/profiles/default/bin/nix-daemon: no such file or directory: unknown.
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   ❗  ::error::Error: The process '/usr/bin/docker' failed with exit code 127
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   ❌  Failure - Main DeterminateSystems/nix-installer-action@main
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   ⚙  ::set-env:: DETERMINATE_NIX_KVM=0
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   ⚙  ::add-path:: /nix/var/nix/profiles/default/bin
[nix_p4-fusion/Build p4-fusion x86_64-linux  ]   ⚙  ::add-path:: /home/runner/.nix-profile/bin
[nix_p4-fusion/Build p4-fusion x86_64-linux  ] exitcode '1': failure

Local machine is x86_64-linux NixOS. Issue happened on both v8 and v9 pin, and both rootless and rootful docker

The action is still on node16, but by default configured runners on NixOS only come with node20, causing the action to fail.

It should probably be moved to node20, if there are no drawbacks?

What main does at the time I'm opening this is: notice systemd isn't there, try to run docker info and immediately fail because I think either of "docker isn't in PATH" or "docker info" returned a non-zero exit code end up throwing instead of just returning from detectAndForceDockerShim.

On Discord, @grahamc suggested trying v8, which happened to be "after Act workarounds were added" but "before GHE (GitHub Enterprise) stuff was added" and that version does work under act, it's only affected by #62.

Recently been getting run failures with an Error: spawn ETXTBSY error.

Tracking down the source appears to show

This specific failure reminds me of the race condition mentioned in the README of https://github.com/buildbarn/bb-remote-execution - requiring separate processes to handle downloading of an executable and executing that executable.

• To work around golang/go#22315 that effectively prevents multi-threaded processes from writing executables to disk and spawning them. Through this decomposition, bb_worker writes executables to disk, while bb_runner spawns them.

Excerpt from workflow log:

2023-11-02T13:53:48.8844243Z ##[group]Run DeterminateSystems/nix-installer-action@v6
2023-11-02T13:53:48.8844899Z with:
2023-11-02T13:53:48.8845200Z   flakehub: false
2023-11-02T13:53:48.8845821Z   github-token: ***
2023-11-02T13:53:48.8846200Z   modify-profile: true
2023-11-02T13:53:48.8846748Z   reinstall: false
2023-11-02T13:53:48.8847092Z   start-daemon: true
2023-11-02T13:53:48.8847777Z   diagnostic-endpoint: https://install.determinate.systems/nix/diagnostic
2023-11-02T13:53:48.8848606Z   trust-runner-user: true
2023-11-02T13:53:48.8848997Z ##[endgroup]
2023-11-02T13:53:49.0060064Z Fetching binary from https://install.determinate.systems/nix/nix-installer-x86_64-linux?ci=github&correlation=GH-599763b2-1658-467b-abe6-984a90a66e96
2023-11-02T13:53:49.5869054Z Downloaded `nix-installer` to `/tmp/nix-installer-7iB0Nw/nix-installer-x86_64-linux`
2023-11-02T13:53:49.5897493Z Execution environment: {
2023-11-02T13:53:49.5903883Z     "NIX_INSTALLER_NO_CONFIRM": "true",
2023-11-02T13:53:49.5904829Z     "NIX_INSTALLER_DIAGNOSTIC_ATTRIBUTION": "GH-599763b2-1658-467b-abe6-984a90a66e96",
2023-11-02T13:53:49.5905559Z     "NIX_INSTALLER_MODIFY_PROFILE": "true",
2023-11-02T13:53:49.5906364Z     "NIX_INSTALLER_DIAGNOSTIC_ENDPOINT": "https://install.determinate.systems/nix/diagnostic",
2023-11-02T13:53:49.5907140Z     "NIX_INSTALLER_START_DAEMON": "true",
2023-11-02T13:53:49.5909417Z     "NIX_INSTALLER_EXTRA_CONF": "access-tokens = github.com=***\ntrusted-users = root runner\n"
2023-11-02T13:53:49.5910164Z }
2023-11-02T13:53:49.6049345Z ##[error]Error: spawn ETXTBSY
2023-11-02T13:53:49.6219046Z Post job cleanup.

As part of the work on the S3 cache GC, we discovered that most of our Fastly traffic is coming from North America. Could this be primarily GitHub traffic?

It would be interesting if this action could set the "user-agent-suffix" Nix setting with the following info:

• the name of the action
• which github org it's being used on

This would allow us to build a better understanding of the usage pattern of the cache.

I'm going to post this to the other Nix install actions as well.

Hey there!

This action (and project to make Nix easier to use/learn in general) is awesome!

How stable is this action at the moment? If it's pretty stable, it would be great to cut a release. I want to start using this on some work repository actions, but for stability it would be great to tie the action to a tag rather than main.

Is there any plan for this in the near future?

I noticed that setting experimental-features in extra-conf has no effect, however, setting extra-experimental-features does. Is this expected behaviour? Could this be because by default it is set to include flakes?

name: "CI using nix"

on:
    push:
      branches:
        - develop
        - main

    pull_request:
      branches:
        - develop
        - main

jobs:
    check:
        runs-on: ubuntu-22.04
        steps:
        - uses: actions/checkout@v3
        - uses: DeterminateSystems/nix-installer-action@main
          with:
            extra-conf: |
              extra-experimental-features = nix-command flakes impure-derivations ca-derivations
        - uses: DeterminateSystems/magic-nix-cache-action@main
        - run: nix flake check

I attempted the following:

1. Set up a self-hosted runner on a NixOS host: services/github-runner.nix
2. Changed by workflow to use that runner: https://github.com/lovesegfault/nix-config/pull/3052/files#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133ddR85-R86
3. Kicked off CI: https://github.com/lovesegfault/nix-config/actions/runs/6496771196

But this action failed: https://github.com/lovesegfault/nix-config/actions/runs/6496771196/job/17644474420

I could just guard the action with an if, and expose the host's Nix to the runner, but I wanted to keep things identical to the GitHub-hosted runners, if at all possible.

Error

Error: 
   0: Executing `nix-installer` as `root` via `sudo`
   1: ENOENT: No such file or directory

Metadata

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:

I'm seeing sporadic failures with this action: https://github.com/lovesegfault/nix-config/actions/runs/6520438910/job/17708001569?pr=3060

It appears to be due to stochastic failure to fetch the installer binary, and could be mitigated with a retry cycle.

nix show-config | grep max-jobs is set to 1 on github actions. Isn't this a cause for concern? Because that would limit the number of concurrent downloads to being 1, slowing down the CI job as a consequence.

https://github.com/srid/nix-health/actions/runs/5743692748/job/15568517152#step:4:79

We may be able to use https://github.com/actions/toolkit/tree/main/packages/tool-cache to use some github smart caching and simplify some code.

Currently the issue is that we can't easily know when to cachebust, since the action typically gets the latest installer. Unfortunately the tool cache doesn't seem to have expiry settings, so it's hard to properly judge when the user should get a new nix-installer binary.

I am trying to use the action on a gitea-runner. The docker image is catthehacker/ubuntu:act-latest.

My job description is simple:

name: Nix build
on: [push]
run-name: Test and build flake
jobs:
  nix-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Nix
        uses: https://github.com/DeterminateSystems/nix-installer-action@v4
        with:
          init: none

You can see the result here: https://code.maralorn.de/maralorn/runner-test/actions/runs/17/jobs/0

For your convenience the error message is:

info: downloading installer (https://install.determinate.systems/nix/tag/v0.10.0/nix-installer-x86_64-linux)
Error: 
   0: Planner error
   1: Error executing action
   2: Action `configure_init_service` errored
   3: Could not detect systemd; you may be able to get up and running without systemd with `nix-installer install linux --init none`.
      See https://github.com/DeterminateSystems/nix-installer#without-systemd-linux-only for documentation on usage and drawbacks.
location:
   src/cli/subcommand/install.rs:193
backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

This is surprising because before that it says:

Set NIX_INSTALLER_INIT=none

I might be holding it wrong. Please enlighten me!

Tried this on: macos-12 and macos-13-xlarge with identical results

I'm using default installer configuration

    - uses: DeterminateSystems/nix-installer-action@main

I following step I set post-build-hook, which invokes nix copy in /etc/nix/nix.conf and restart nix daemon with:

sudo launchctl stop org.nixos.nix-daemon
sudo launchctl start org.nixos.nix-daemon

I then build a package with nix-build and see the following:

post-build-hook: /Users/runner/.config/nix/upload-to-cache.sh: line 28: nix: command not found
error: program '/Users/runner/.config/nix/upload-to-cache.sh' failed with exit code 127

This causes cachix-action to fail when using Nix 2.15: cachix/cachix-action#146

I think echo "$HOME/.nix-profile/bin" >> "$GITHUB_PATH" is warranted somewhere, though I am uncertain whether that should happen here or in the installer.

I am getting this error while using the nix installer action. I am really mystified by what is happening, because I am using this action in two different repositories. In one repository the action works fine, and I don't have any issues. In another repository I am getting the issue title as an error.

Here is the github action workflow yaml. I am sure this will be confusing, but I am on GitHub Enterprise Server, and my work has strict rules around which actions we use. I am using GitHub Actions Sync to bring public actions into GHES.

- name: Install Nix
   uses: redacted-actions/nix-installer-action@main
   with:
     init: none
     planner: linux
     
- uses: redacted-actions/magic-nix-cache-action@main

- name: Get all changed and modified yaml files
  id: changed_files
  uses: redacted-actions/changed-files@v38
  with:
    files: |
      **/*.yml
      **/*.yaml
    separator: " "

- name: Run yamllint
  run: |
    nix develop --command yamllint -c .yamllint.yaml ${{ steps.changed_files.outputs.all_changed_files }}

The workflow fails on the Run yamllint step, and throws the error error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted

In the repository where things work, I am using a pretty similar invocation, but without the usage of nix develop. I added a test nix develop invocation, and that also fails with error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted.

Any idea what could be going on?