In reply to @aciceri:nixos.dev

Maybe balsoft's solution is better since the only use case that comes to my mind is when the host's architecture is different, but I don't feel like I can express an opinion.

Any quick workaround to do what I'm trying to do instead? Maybe a sequence of nix check where I manually specifying what want to check?

I'm trying to write a flake with the configurations of all my machines (using devos as template), included an aarch64 notebook. The problem is that when I run in the Github workflow nix flake check it tells me that "a 'aarch64-linux' with features {} is required to build blah blah..." and it stops.

Before adding the arm machine the workflow correctly worked.

The alternative would be to run several times nix build .#checks.x86_64-linux.<myCheck> with all the needed <myCheck>s. I see two problems:

• The number of my checks could grow in time and I don't want to manually add these lines in the workflow yaml, is there a way to get a flake's outputs? Then with a little bit of shell fu I could obtain the correct nix build command to run.
• According to the doc flake check not only builds the checks but also does checks that the flake's outputs are app definitions, nixos modules, overlays, etc... So it would'n be equivalent to just run a sequence of nix build

The alternative would be to run several times nix build .#checks.x86_64-linux.<myCheck> with all the needed <myCheck>s. I see two problems:

• The number of my checks could grow in time and I don't want to manually add these lines in the workflow yaml, is there a way to get a flake's outputs? Then with a little bit of shell fu I could obtain the correct nix build command to run.
• According to the doc flake check not only builds the checks but also does checks that the flake's outputs are app definitions, nixos modules, overlays, etc... So it wouldn't be equivalent to just run a sequence of nix build

In reply to @aciceri:nixos.dev

The alternative would be to run several times nix build .#checks.x86_64-linux.<myCheck> with all the needed <myCheck>s. I see two problems:

• The number of my checks could grow in time and I don't want to manually add these lines in the workflow yaml, is there a way to get a flake's outputs? Then with a little bit of shell fu I could obtain the correct nix build command to run.
• According to the doc flake check not only builds the checks but also does checks that the flake's outputs are app definitions, nixos modules, overlays, etc... So it wouldn't be equivalent to just run a sequence of nix build

In reply to @aciceri:nixos.dev

The alternative would be to run several times nix build .#checks.x86_64-linux.<myCheck> with all the needed <myCheck>s. I see two problems:

• The number of my checks could grow in time and I don't want to manually add these lines in the workflow yaml, is there a way to get a flake's outputs? Then with a little bit of shell fu I could obtain the correct nix build command to run.
• According to the doc flake check not only builds the checks but also does checks that the flake's outputs are app definitions, nixos modules, overlays, etc... So it wouldn't be equivalent to just run a sequence of nix build

1. AFAIR you can generate workflow YAML's at runtime. If so, nothing is stopping you from using Nix to generate them with builtins.toJSON. If you want an example on how to do it for buildkite, see https://github.com/serokell/common-infra/blob/master/flake.nix#L69

In reply to @ilkecan:matrix.org
To get the flake outputs, there is nix flake show but it is for humans. Recently a PR that adds --json flag is merged but it seems this didn't hit the channels yet.

In reply to @balsoft:balsoft.ru

1. AFAIR you can generate workflow YAML's at runtime. If so, nothing is stopping you from using Nix to generate them with builtins.toJSON. If you want an example on how to do it for buildkite, see https://github.com/serokell/common-infra/blob/master/flake.nix#L69

Two completely unrelated questions:

1. is it possible for a flake to "read the status" of the running system where it's executed (with nix build or nix check for example)? I was thinking it would be convenient (for my use case written before) to understand during the flake evaluation the host's architecture (I mean the machine where I run nix)
2. Does it exist a github bot that try to update my flake's inputs (the flake is hosted on Github)? Consider that for the pacakges I also use nvfetcher this simplifies. However I would also like to update modules and all, not only packages.

In reply to @aciceri:nixos.dev

Two completely unrelated questions:

1. is it possible for a flake to "read the status" of the running system where it's executed (with nix build or nix check for example)? I was thinking it would be convenient (for my use case written before) to understand during the flake evaluation the host's architecture (I mean the machine where I run nix)
2. Does it exist a github bot that try to update my flake's inputs (the flake is hosted on Github)? Consider that for the pacakges I also use nvfetcher this simplifies. However I would also like to update modules and all, not only packages.

In reply to @aciceri:nixos.dev

Two completely unrelated questions:

1. is it possible for a flake to "read the status" of the running system where it's executed (with nix build or nix check for example)? I was thinking it would be convenient (for my use case written before) to understand during the flake evaluation the host's architecture (I mean the machine where I run nix)
2. Does it exist a github bot that try to update my flake's inputs (the flake is hosted on Github)? Consider that for the pacakges I also use nvfetcher this simplifies. However I would also like to update modules and all, not only packages.

1. No, it's not, by design (it wouldn't be hermetic otherwise)
2. Yes! https://github.com/serokell/update-daemon (it's still somewhat WIP though)

In reply to @balsoft:balsoft.ru

1. No, it's not, by design (it wouldn't be hermetic otherwise)
2. Yes! https://github.com/serokell/update-daemon (it's still somewhat WIP though)

1. I understand, it makes sense
2. Really interesting, it could be exactly what I was looking for, I'm definitely going to try it. Looking at module definition I can't understand how to set the agentSetup option. I also don't understand if I have to create another GitHub user or what. Are there any examples?

In reply to @aciceri:nixos.dev

1. I understand, it makes sense
2. Really interesting, it could be exactly what I was looking for, I'm definitely going to try it. Looking at module definition I can't understand how to set the agentSetup option. I also don't understand if I have to create another GitHub user or what. Are there any examples?

In reply to @colemickens:matrix.org
when using nix cli 2, you can often structure things such that your commands are actually arch amiguous. nix run .#install-secrets does the right thing because it auto-coerces that to (a number of things including) .apps.{archs}.install-secrets. The {arch} it tries during the coercion is based on the host executing nix.

In reply to @aciceri:nixos.dev
Sorry but what is nix cli 2? And is nix run .# install-secrets standard or you meant a particular flake? I'm really interested but I really can't understand what are you talking about

In reply to @balsoft:balsoft.ru
(2) Sadly examples aren't public, but I can provide you with a snippet if you want

In reply to @aciceri:nixos.dev
If it's not a problem and you've a working example at hand I would like to see it.

{ config, pkgs, lib, inputs, ... }: {
  vault-secrets.secrets.update-daemon = {
    secretsAreBase64 = true;
  };

  services.update-daemon = {
    enable = true;
    secretFile = "${config.vault-secrets.secrets.update-daemon}/environment";
    agentSetup = ''
      export PATH="$PATH":${lib.makeBinPath [ pkgs.openssh ]}
      if [[ -z "''${SSH_AGENT_PID:-}" ]] ; then
        echo "Starting an ephemeral ssh-agent" >&2;
        eval "$(ssh-agent -s)"
      fi
      cat ${config.vault-secrets.secrets.update-daemon}/private_ssh_key | env SSH_ASKPASS="$(command -v false)" ssh-add -
    '';
    repos = {
      github = {
        serokell = {
          gemini-infra = {};
          pegasus-infra = {};
        };
      };
    };
    settings = {
      author.email = "operations@serokell.io";
      extra_body = "CC @serokell/operations";
    };
  };
}

In reply to @balsoft:balsoft.ru
nix cli 2 is the experimental nix-command feature, I suppose

In reply to @balsoft:balsoft.ru

{ config, pkgs, lib, inputs, ... }: {
  vault-secrets.secrets.update-daemon = {
    secretsAreBase64 = true;
  };

  services.update-daemon = {
    enable = true;
    secretFile = "${config.vault-secrets.secrets.update-daemon}/environment";
    agentSetup = ''
      export PATH="$PATH":${lib.makeBinPath [ pkgs.openssh ]}
      if [[ -z "''${SSH_AGENT_PID:-}" ]] ; then
        echo "Starting an ephemeral ssh-agent" >&2;
        eval "$(ssh-agent -s)"
      fi
      cat ${config.vault-secrets.secrets.update-daemon}/private_ssh_key | env SSH_ASKPASS="$(command -v false)" ssh-add -
    '';
    repos = {
      github = {
        serokell = {
          gemini-infra = {};
          pegasus-infra = {};
        };
      };
    };
    settings = {
      author.email = "operations@serokell.io";
      extra_body = "CC @serokell/operations";
    };
  };
}