Skip to content

Cache ghc883 and ghc8101 again (without tests) #821

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Aug 14, 2020
Merged

Conversation

hamishmack
Copy link
Collaborator

When ghc 8.8.4 and ghc 8.10.2 were added we stopped building the older
versions on ci. This changes adds them back but does not run all
the tests on them.

When ghc 8.8.4 and ghc 8.10.2 were added we stopped building the older
versions on ci.  This changes adds them back but does not run all
the tests on them.
@hamishmack hamishmack requested a review from michaelpj August 14, 2020 03:57
ci.nix Outdated
inherit (import ./default.nix { inherit checkMaterialization; }) nixpkgsArgs;
inherit runTests;
}) ({
ghc865 = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth writing down the policy here... what is it?

@michaelpj
Copy link
Collaborator

Actually, thinking about the policy, should we put something in the documentation (and maybe even in the readme) listing the GHC versions that get this extra level of support?

I think it's just two support levels:

  1. We have an expression, and relevant bits are materialized, and we build the compiler itself and nix-tools (I think we do all of this for any version we have an expression for?)
  2. The above, and it's tested.

Writing it down, I guess that's only one level as far as users are concerned.

@hamishmack hamishmack merged commit b368a5d into master Aug 14, 2020
@iohk-bors iohk-bors bot deleted the hkm/cache-old-ghc branch August 14, 2020 12:34
@masaeedu
Copy link
Contributor

masaeedu commented Aug 15, 2020

@michaelpj I think that would be a good idea. Additionally, I'm not sure if it's too much trouble, but getting the CI to maintain some system of tags/branches which allows a user to get the latest version of haskell.nix for which cached builds are available with a particular compiler and nixpkgs would be very useful. At the moment the choice is between sitting on one fixed commit forever once you've finally got everything to work, or upgrading straight to master periodically (which can often cause breakages with a selected combination of nixpkgs, compiler and index-state).

@michaelpj
Copy link
Collaborator

I think realistically the only guarantee we offer is that master is built with whatever's in ci.nix.

@masaeedu
Copy link
Contributor

@michaelpj The problem I'm running into is that it doesn't seem like we have the guarantee that everything in ci.nix is built by the time it's in master. I want some ref that I can put in my niv projects, such that when I run niv update I still get cache hits. master does not appear to be such a ref, because things seem to go into master before the corresponding stuff is built and stored in the cache.

@michaelpj
Copy link
Collaborator

Are you using the iohk hydra cache as well as the cachix one? (https://input-output-hk.github.io/haskell.nix/tutorials/getting-started/#setting-up-the-cachix-binary-cache)

booniepepper pushed a commit to booniepepper/haskell.nix that referenced this pull request Feb 4, 2022
When ghc 8.8.4 and ghc 8.10.2 were added we stopped building the older
versions on ci.  This changes adds them back but does not run all
the tests on them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants