feat: add and install nix as tool

[matttrach]

This adds and installs Nix into a new Nix image.
It also adds a new build type archive_script which downloads an archive matching the checksum, extracts the install script and runs the installer. Nix has some specific install needs, so I added them into the archive_script template, making sure to switch on tool name. The normal case for archive_script will download the script from the url, extract the installer and run it. For Nix we need to add sudo and a new user, I added the user suse since that is standard on sles.

Closes #34

[mallardduck]

Overall looks okay, it's a solid idea for an area we should cover too. I will need to take a deeper look tomorrow to provide more complete review. My first feedback is around:

Nix has some specific install needs, so I added them into the archive_script template

I would prefer we ensure that the script and archive_script are rather generic and could be used to "add any shell script" to a base image. This keeps things consistent with the existing structure I setup for the project to have. Then we could additionally add some Nix specific logic in for handling that too.

[matttrach]

Like maybe a Nix template? Maybe we should have an "install-template" attribute in the deps.yaml to specify a template to insert into the dockerfile?

[mallardduck]

Like maybe a Nix template?

I was thinking that but then I started thinking about tool "before hooks" of some sort. I'm playing with something tonight and should have a PR this could be based on tomorrow.

[mallardduck]

Here is a new hooks feature to accommodate this PRs needs: #36. I think that this will be more flexible for all tools needs than some nix specific solutions here. Additionally it will consolidate all the "extra tool specific logic" into these new hook files.

---

After that PR the tool config will look different, use:

  - name: nix
    source: "https://releases.nixos.org/nix"
    mode: static
    version: 2.34.5
    checksums:
      linux/amd64: "0a0462692a10ff1eb8a608f713f38d1f25a208ad55963a9c00b239da398de5a1"
      linux/arm64: "771e4b6f719243b9481f19eaedfbbbacc2f4a0282d6e043df4f33bb449ea3c57"
    release:
      download_template: "{source}/nix-{version}/nix-{version}-{arch|replace:amd64=x86_64|replace:arm64=aarch64}-{os}.tar.xz"
      extract: "nix-{version}-{arch|replace:amd64=x86_64|replace:arm64=aarch64}-{os}/install"
      install_to_path: false  # Extract to /var/ci-tools/mytool/ for hooks

Then you will want to make:

hooks/nix-pre.tmpl with:

# Create unprivileged user for Nix installation
RUN useradd -m suse && \
    if [ ! -f /etc/sudoers ]; then touch /etc/sudoers; fi && \
    echo "suse ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

# Add suse user to runner group and create /etc/nix directory and configuration
RUN usermod -a -G runner suse && \
    sudo mkdir -p /etc/nix && \
    printf "build-users-group =\nsandbox = false\nfilter-syscalls = false\n" > /etc/nix/nix.conf && \
    sudo chown -R suse:runner /etc/nix && \
    sudo mkdir -p /nix && \
    sudo chown -R suse:runner /nix && \
    echo 'source /home/suse/.nix-profile/etc/profile.d/nix.sh' > /etc/profile.d/nix.sh && \
    echo 'source /home/suse/.nix-profile/etc/profile.d/nix.sh' > /etc/bash.bashrc.local

And hooks/nix-post.tmpl of:

# Fix ownership and run Nix installer from the extracted archive
RUN set -e; \
    sudo chown -R suse:runner /var/ci-tools/nix

# Switch to unprivileged user for installation
USER suse
WORKDIR /home/suse
ENV USER=suse

RUN set -e; \
    case "${ARCH}" in \
        amd64) extract="nix-2.34.5-x86_64-linux/install" ;; \
        arm64) extract="nix-2.34.5-aarch64-linux/install" ;; \
        *) echo "unsupported architecture: ${ARCH}" >&2; exit 1 ;; \
    esac; \
    cd /var/ci-tools/nix && \
    ./${extract} --no-daemon

# Restore root user for remaining Dockerfile operations
USER root
ENV USER=root

[macedogm]

@matttrach can you please rebase your pr and update it to the new config of hooks made by @mallardduck in #36?

[matttrach]

The version variable allows further templates know the version selected in the deps.yaml. Without this the deps.yaml won't be the single source of truth for the version information.

[mallardduck]

The version variable allows further templates know the version selected in the deps.yaml. Without this the deps.yaml won't be the single source of truth for the version information.

🤔 Ok - I see where you might want to add the version env. However I think that I see this as highlighting a different gap in the hook mechanism. Think this should be pretty easy to extend so that the hook templates have context of and access to variables related to their package.

---

OK - 2 things I see a super simple fix that is pretty obvious in hindsight. Gist being that even InstallToPath=false should extract the same way we do for InstallToPath=true just to a different place not in PATH. So we can probably go with that to immediately unblock this.

To save us some cycles I also prepared a branch to validate this produces expected results: main...fix-test

I don't use nix but the dockerfile fully builds for me now so I think that's a good sign.

The other part is "Hook Variables" which could allow Hook files to be more complex if needed. However the first fix will make it moot - so this becomes a future "nice to have".

[macedogm]

@matttrach #39 is merged and will require a new rebase and re-run to update your code, please.

[macedogm]

@mallardduck I think that we should be good to merge this one, wdyt?

[macedogm]

@matttrach can you please check Dan's comment so when can merge this pr?

[mallardduck]

LGTM - the hooks are in the right place for the lock to account for them. This should ensure that any "hook file only" changes still show up in the change log and are account for in the lock in general.