Skip to content
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

ci: add DeterminateSystems/magic-nix-cache-action #6269

Closed

Conversation

thiagokokada
Copy link
Contributor

@thiagokokada thiagokokada commented Jan 4, 2025

Description

There is zero reason why the current CI for home-manager is that slow. We can cache the CI results and basically get a very fast CI (e.g.: only run tests for the changed code) as long as we store the /nix/store somewhere and restore before running the tests.

This PR adds DeterminateSystems/magic-nix-cache-action to do so.

Checklist

  • Change is backwards compatible.

  • Code formatted with ./format.

  • Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

  • Test cases updated/added. See example.

  • Commit messages are formatted like

    {component}: {description}
    
    {long description}
    

    See CONTRIBUTING for more information and recent commit messages for examples.

  • If this PR adds a new module

    • Added myself as module maintainer. See example.

Maintainer CC

@rycee
Copy link
Member

rycee commented Jan 5, 2025

We actually used to have caching but I removed it at some point (#5093) because it was actually slowing things down.

Maybe it's worth trying to re-enable it. But I suspect it still is not a big win.

Would be great to make the tests have a more reasonable runtime so well worth investigating more deeply. E.g., how to reduce the number of evaluations of Nixpkgs.

@thiagokokada
Copy link
Contributor Author

Maybe it's worth trying to re-enable it. But I suspect it still is not a big win.

I amended the commit to re-trigger the tests, let's see. I imagine that this new run should be significantly faster than the previous one (that took ~43 min), but if there is no change it wouldn't be worth it.

@thiagokokada
Copy link
Contributor Author

Took basically the same time, yes, it seems it is not worth it at all.

@thiagokokada thiagokokada mentioned this pull request Jan 7, 2025
6 tasks
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.

2 participants