Recommendation: cache `~/.julia/artifacts` in CI services

Tooling
1

As many of you are probably already aware, starting from v1.3, Julia is using Artifacts to ship binary packages to the users. You can read more about this in the blog post Reliable and Reproducible Binary Artifacts for Julia Packages.

Since these packages can take some time to download, you may want to cache them to avoid downloading them over and over again. This would also solve occasional failures due to connection problems between the CI service and GitHub, where most of the tarballs reside.

Here are instructions about how to cache artifacts in some popular CI services, feel free to contribute more instructions and I’ll update the post.

Travis CI

You can cache Julia artifacts on Travis with

cache:
  directories:
  - $HOME/.julia/artifacts

AppVeyor

Following these instructions, my understanding is that for AppVeyor this might work:

cache:
  - '%USERPROFILE%\.julia\artifacts'

GitHub Actions

To cache the artifacts in GitHub actions, add the following lines after the setup-julia setup:

      - name: Cache artifacts
        uses: actions/cache@v1
        env:
          cache-name: cache-artifacts
        with:
          path: ~/.julia/artifacts 
          key: ${{ runner.os }}-test-${{ env.cache-name }}-${{ hashFiles('**/Project.toml') }}
          restore-keys: |
            ${{ runner.os }}-test-${{ env.cache-name }}-
            ${{ runner.os }}-test-
            ${{ runner.os }}-

Final remarks

Note that an extremely large quantity of artifacts can actually increase CI time at least the very first time, but subsequent executions should be faster. Please do report here if you encounter problems due to the use of cache of artifacts on CI services, so that we can understand what may be going wrong.

23 Likes
2

Thanks a lot for this. I think you are missing a ' at the end of the AppVeyor config.

1 Like
3

If you’re seeing random errors downloading artifacts in CI right now, it’s because GitHub is having problems right now: GitHub Status - Incident on 2020-05-07 23:17 UTC. This is however a good occasion to recommend again caching artifacts in CI exactly to avoid issues like this one

1 Like
4

If I understand it correctly, one caveat using this Github Action settings is that if you bump a (patch) version for every PR, which changes Project.toml, you’ll almost never get a cache hit :cry: (at least for the first push)

5

I’m not sure this is correct, in the few packages where I use GitHub Actions for CI the cache has never been invalidated after changing the Project.toml file, at least by judging from the size of the cache that always grows. @SaschaMann maybe knows better how this works.

6

If there’s no exact match for the key, it falls back to the restore-keys: Caching dependencies to speed up workflows - GitHub Docs

If you change Project.toml, it should still match ${{ runner.os }}-test-${{ env.cache-name }}-, assuming there is a cache. This only works if the cache has been accessed within the last week which is not the case for many packages.

2 Likes
7

I wanted to add a possible configuration for gitlab-ci:

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - ./.julia/artifacts
before_script:
  - export JULIA_DEPOT_PATH=./.julia

we need to change the depot path here, because gitlab only allows to cache paths in the project directory.

3 Likes
8

Hi!

There’s now an action created by @rikh and me that handles this for you if you’re using GitHub Actions: https://github.com/marketplace/actions/cache-julia-artifacts-packages-and-registry

An example workflow that uses it to cache artifacts and packages as part of a CI process might look like this:

name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: julia-actions/setup-julia@v1
    - uses: julia-actions/cache@v1
    - uses: julia-actions/julia-buildpkg@v1
    - uses: julia-actions/julia-runtest@v1

You can find more info and config options in the readme.

6 Likes