Binary caches and release branches

[kodeFant]

I would like to highlight the suggestion from @Eisfunke here #1705 (comment) about release branches and fork it into a separate issue :)

I think this will be vital for the future of smooth IHP deployments on Shipnix and other platforms

A repeating issue is non-matching binary caches, and that it's difficult to debug when a binary cache is actually working for the current version, and that the server suddenly takes one hour to deploy, if the server is even powerful enough to pull it off.

If we could ensure that the latest version always is covered by the binary cache, I think deployment on all platforms would be really great.

Then if building IHP takes a long time, the solution would probably often be just to run nix flake update and try again.

Nice to haves:

Could we even could support an individual binary cache for each release branch at least maybe one or two versions down?

And, maybe even better, could even the binary be declared under the hood from the IHP source? I'm guessing it probably isn't as simple as it sounds, but would be great if it was xD

[Eisfunke]

And, maybe even better, could even the binary be declared under the hood from the IHP source? I'm guessing it probably isn't as simple as it sounds, but would be great if it was xD

I'm not sure I understand what you mean, could you elaborate? We can declare a binary cache via the flake, that is then pulled in by the users, so this could be set differently per version:

ihp/flake-module.nix

Line 178 in 62376a9

flake.nixConfig = {

[kodeFant]

That is exactly what I meant 👍

[kodeFant]

Am I reading cachix pins right in that it could actually preserve store paths from the latest of each release branch, and by that also not having to ever change binary cache to support each release?

[mpscholten]

Yes, this would work. But right now it seems not to be what is causing our issues with all the recent missing builds

[CSchank]

+1 - I'm having all sorts of issues getting Cachix to work. Depending on the project it will try to build anywhere from 30-130 packages from source using ghc.

[mpscholten]

@CSchank can you verify that your flake.lock file is the same as in https://github.com/digitallyinduced/ihp-boilerplate/blob/master/flake.lock ?

[mpscholten]

Builds should be fixed now (this time likely for real :D)! The problem was that the cachix action doesn't support nix flakes yet, so the nix flakes output wasn't pushed to cachix at all. I've fixed this by manually pushing it there.

[CSchank]

So, @mpscholten should I try to update an old project to the Nix Flakes-based IHP and see if caching works?

[mpscholten]

Yep, you can give it a try. As the flake.lock in ihp-boilerplate references commit ed567e8 which still has running github actions, I'd wait a couple minutes before trying it, until all the github actions have finished green 👍

[CSchank]

@mpscholten it still seems to want to build IHP for me :( (Note this isn't in GitHub Actions, this is just on my macOS computer)
E.g. it's showing [1/3/9 built] building ihp-v1.0.1 (buildPhase): Probable fix: add INLINABLE pragma on ‘Text.Megaparsec.Internal.$fMonadParsecesParsecT’

flake.nix, default.nix, flack.lock, etc are the same as ihp-boilerplate

Edit: Let's move this discussion to #1745 as it seems to only happen to me when I'm upgrading an old project to use Flakes.