Adding flake check and weekly flake.lock maintence job in git workflow

[Mshehu5]

This PR addresses some of the issues in #457 specifically:

Adding a Nix flake check to the GitHub workflow

Adding a flake.lock maintenance job to automatically update flake.lock

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 20214601820

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 83.307%

---

Totals
Change from base Build 20196571621:	0.0%
Covered Lines:	9657
Relevant Lines:	11592

---

💛 - Coveralls

[benalleng]

45 minutes! yikes 😵 I think we need to aggressively limit what is being checked in the PR flake check as laid out in the comment in the original issue

nix flake check -L .#{nix-fmt-check,shfmt,shellcheck}

I think the full flake check should be limited to the weekly actionz

Perhaps just some veery basic smoke-testing is sufficient as the formatter checks would really be redundant alongside the work I am doing in #1221

[Mshehu5]

45 minutes! yikes 😵 I think we need to aggressively limit what is being checked in the PR flake check as laid out in the comment in the original issue

nix flake check -L .#{nix-fmt-check,shfmt,shellcheck}

I think the full flake check should be limited to the weekly actionz

Perhaps just some veery basic smoke-testing is sufficient as the formatter checks would really be redundant alongside the work I am doing in #1221

Yeah, I wanted to do that but after checking #1221 I realized it would be redundant. Also in the issue using nix flake check -L was suggested, which is why I went with that approach.

A weekly maintenance job might be the best option for now, since running it takes 45 minutes which is alot

[nothingmuch]

45 minutes! yikes 😵 I think we need to aggressively limit what is being checked in the PR flake check as laid out in the comment in the original issue

Note that caching should improve this a lot of the build time is the dependencies

nix flake check -L .#{nix-fmt-check,shfmt,shellcheck}

Note this is incorrect, it needs to be nix build -L .#checks.x86_64-linux.shellcheck (or whatever platform the runner is on)

I think the full flake check should be limited to the weekly actionz

For now yes, but in the long run we should strive to make it less redundant and more useful, otherwise it'll bitrot. Some notes on how to achieve this below.

Perhaps just some veery basic smoke-testing is sufficient as the formatter checks would really be redundant alongside the work I am doing in #1221

formatter checks will be quick, the long build time is for the project dependencies under multiple toolchains which should be mostly cached across builds, and release builds as part of the compilation of each package separately

for simple/quick things like shellcheck we can build those separately:

nix build .#checks.x86_64-linux.shellcheck -L

we can also define checks that just have other checks as build inputs:

diff --git a/flake.nix b/flake.nix
index 85e16184..509da043 100644
--- a/flake.nix
+++ b/flake.nix
@@ -164,6 +164,16 @@
         };
         formatter = pkgs.nixfmt-tree;
         checks = packages // {
+          quick = simpleCheck {
+            name = "quick";
+            src = pkgs.runCommand "dummy src" { } "mkdir $out";
+            buildInputs = with self.outputs.checks.${system}; [
+              shfmt
+              shellcheck
+              nix-fmt-check
+            ];
+          };
+
           payjoin-workspace-nextest = craneLib.cargoNextest (
             commonArgs
             // {

so that we can do something like

nix build .#checks.x86_64-linux.quick -L

both in CI and when running locally to have more useful fail fast scenarios. we should also split the msrv and nightly jobs to not run in the same github action, running one after the other on the same machine is wasteful, and there's no way for the build of one toolchain to help by caching something useful for the build of another. all the checks that have inherit cargoArtifacts do depend on the nightly build dependencies though (payjoin-workspace-clippy, payjoin-workspace-doc and pyajoin-workspace-nextest explicitly, but also all of the packages via the individualCrateArgs attr set).

finaly just to temper expectations in the long run, nix build .#checks.x86_64-linux.payjoin-workspace-nextest will almost always be slower than just running cargo test in github actions directly (or in the local working directory), since the latter can reuse some compiler outputs from the previous revision with build artifact caching, whereas in nix this will always be built in the sandbox and only the explicit dependencies artifacts arranged by crane are available

[nothingmuch]

i would suggest rebasing on top of #1226, which implements the suggestions of my previous comment.

otherwise, there is a redundancy because when a new pr is opened that will run the flake checks, so updating will run them twice as implemented

[nothingmuch]

is this because the flake check on the PR it opens is planned to be partial?

if so maybe it's better to do it in the reverse order:

First:

nix flake check -L --recreate-lock-file --no-write-lock-file

to make a new lockfile

then add --offline to the update-flake-lock action's nix arguments, if it passes this to nix flake update --commit-lockfile then i think it will commit without re-fetching the upstream flake inputs so the same flake inputs as were used when running the checks with the recreated lock file should be used... a cleaner approach would be to PR to the update-flake-lock action to allow it to run the check after the nix flake update command but before opening the PR

[nothingmuch]

see other comment, we should only do this once per update, if this remains then the other one is redundant

[Mshehu5]

Edit: I get the comment now.
@nothingmuch

[nothingmuch]

btw, for nice progress, you can use:

nix run nixpkgs#nix-output-monitor -- build .#checks.x86_64-linux.{quick,slow}

(nom build if you use it in a nix shell)

[Mshehu5]

btw, for nice progress, you can use:

nix run nixpkgs#nix-output-monitor -- build .#checks.x86_64-linux.{quick,slow}

(nom build if you use it in a nix shell)

Thank you very much! Your comments have been really helpful. I’ll make the required changes.

[nothingmuch]

rebasing on top of #1228 should result in speedsups

[Mshehu5]

rebasing on top of #1228 should result in speedsups

After rebasing and running nix flake check it looks like it now requires more disk space. On my local machine, I had to delete some files to get it to run
Currently on CI, we’re hitting the following error:
workspace-deps-nightly> rustc-LLVM ERROR: IO failure on output stream: No space left on device

Also I seem to not be able to pass: ❌ checks.x86_64-linux.payjoin-workspace-nextest-stable integration test in nix flake check on my PC anymore

[nothingmuch]

i guess the debug symbols are too much, but in addition it seems crane's cargoNextest derivations are saving the resulting target.tar.zstd from the test run itself, I'm not sure why but investigating

nix store gc (and ofc also cargo clean, i had ~200GB one for rust-payjoin workspace recently) can help with old builds clogging up disk space, but yeah this needs to be improved especially because it caching less useful

[nothingmuch]

i pushed additional commits:

1. new crane profile inherits from test (which inherits from dev) but overrides to set debug = false. this reduces targets.tar.zstd by about 50%, and probably more for the uncompressed targets dir (temporarily extracted within the build sandbox)
2. disabled installing cargo artifacts for the nextest job. we might want to re-enable aspects of this to obtain test and coverage logs from the nextest runs but we definitely don't need the entire cargo artifacts directory to be saved