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

Fixing the cache situation #2427

Closed

Conversation

Anton-Latukha
Copy link
Collaborator

@Anton-Latukha Anton-Latukha commented Dec 1, 2021

Because the number of small things are addressed here - it is easier to make documentation in commits & address them in review mode.

@Anton-Latukha Anton-Latukha force-pushed the fixing-the-cache-situation branch 9 times, most recently from a45fcd4 to 38cd642 Compare December 1, 2021 17:48
@Anton-Latukha Anton-Latukha mentioned this pull request Dec 1, 2021
27 tasks
@Anton-Latukha Anton-Latukha force-pushed the fixing-the-cache-situation branch 4 times, most recently from fc963d2 to a241891 Compare December 1, 2021 20:53
@Anton-Latukha Anton-Latukha force-pushed the fixing-the-cache-situation branch 5 times, most recently from 8087928 to 12c19ee Compare December 1, 2021 23:45
@Anton-Latukha
Copy link
Collaborator Author

Anton-Latukha commented Dec 2, 2021

Current source caching works great:

      - name: Hackage sources cache
        uses: actions/cache@v2
        env:
          cache-name: hackage-sources
        with:
          path: ${{ env.CABAL_PKGS_DIR }}
          #  2021-12-01: NOTE: Cabal Hackage source tree storage does not depend on OS or GHC.
          key:          ${{ env.cache-name }}-${{ env.HACKAGE_TIMESTAMP }}
          restore-keys: ${{ env.cache-name }}-

All GHCs use one 193Mb cache instance & none of them needed to download additional versions.

But depending on the library versions supporting particular base - some package downloads can happen for particular GHCs here & there down the line in the future.

The most ideal way to cache is to differentiate on GHC versions:

      - name: Hackage sources cache
        uses: actions/cache@v2
        env:
          cache-name: hackage-sources
        with:
          path: ${{ env.CABAL_PKGS_DIR }}
          #  2021-12-01: NOTE: Cabal Hackage source tree storage does not depend on OS or GHC really, but can depend on `base`.
          key:          ${{ env.cache-name }}-${{ matrix.ghc }}-${{ env.HACKAGE_TIMESTAMP }}
          restore-keys: |
            ${{ env.cache-name }}-${{ matrix.ghc }}-
            ${{ env.cache-name }}-

But that means storing (6 GHCs) - 6 times more sources. So using 10% of the cache for it.

Source caching is really to be done inside master branch for caching & that gets shared into PRs.
But PRs really would not change or even use dependency sources, since they would have & (should) use dependencies compiled.

And if the person updates the Hackage pin - it anyway needs full redownload & rebuild, of caches also.

So source caching is really only happens in master & only for master having a faster compilation of deps. In that way it is revealed that occasional partial redownload from Hackage is a redundant theme to drive attention to & discuss & that source caching at all can be removed without notacible implications.

I would keep it as it is & would put a statement to "think hard - that is a master for master purposes".

@Anton-Latukha Anton-Latukha force-pushed the fixing-the-cache-situation branch 9 times, most recently from 4e9d72c to 4f0ae41 Compare December 2, 2021 12:48
@Anton-Latukha
Copy link
Collaborator Author

Closing in favour of #2446 continuation.

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