Cut down the evaluation overhead of build-packages

[michaelpj]

At the moment build-packages builds ~6 derivations in a single Nix command. That doesn't seem so bad... except that each of them is its own independent cabal project, and so needs to do the haskell.nix cabal planning IFD. So in fact the evaluation time becomes significant: about 5min at the moment, and it'll be more as we add more packages to the smoke test.

(For the building we have nixbuild.net, which is massively parallel, but the evaluation is serial!)

It would be nice to cut this down. At the moment the only way I can think of doing that is to do a matrix build in GHA, with each package in its own job. Then the evaluation work can be done in parallel. But this would be a bit annoying, we'd need to get the list of things to build out of the flake and then call back into it again...

[andreabedini]

nix-eval-jobs seems to be able to do the evaluation in parallel. It would spit out a json file we can read back into GHA. Something like this:

  eval-jobs:
    outputs:
      matrix: ${{ steps.set-matrix.outputs.matrix }}
    steps:
    - run: |
        nix-eval-jobs --flake path:$PWD#packages.x86_64-linux.allPackages --override-input CHaP path:_repo > jobs.json
    - id: set-matrix
      run: |
        echo "::set-output name=matrix::$(jq @text < dist-newstyle/cache/plan.json)" # maybe with some json wrangling
  build-packages:
    needs: eval-jobs
    strategy:
      matrix: ${{fromJson(needs.eval-jobs.outputs.matrix)}}

[michaelpj]

Hmm, interesting. Hopefully it'll use remote builders for the IFD still, but that could be a big improvement.

I'm unsure if we want to generate a matrix: probably we do if it's for the smoke test or new packages, but we wouldn't if we decided to try and build everything since matrixes are limited to 256 jobs (hah). And also the real parallelism will be happening on nixbuild.net, we'll just be occupying |matrix| runners sitting there waiting for builds to finish!

Also it doesn't yet support --override-input. Maybe we can just do --update-input beforehand instead.