I’m pretty sure you can cache them. I’ll see if I can dig up some info.

You want to use the cache action. Here’s an example using it to cache ruby gems (but it’s generic and can cache anything.

The key thing is to use a hashkey that makes sense so the cache is invalidated when the things you are caching change. In this case below, I’m using a hash of the Gemfile.lock (which is the lock file for Ruby gems). When it changes, the cache is invalidated.

name: Tests
on: pull_request
jobs:

rake:

name: rake tests

runs-on: ubuntu-latest
# runs all of the steps inside the specified container rather than on the VM host.  
# Because of this the network configuration changes from host based network to a container network.
container:
  image:  ruby:2.6.6

steps:
- uses: actions/checkout@v2
  with:
    path: app/

# Need 2 caches for the gems.  The cache key is based on a hash of the gemspec file
# When the gemspec file changes, the cache is invalidated
- uses: actions/cache@v2
  with:
    path: app/vendor/cache
    key: ${{ runner.os }}-gem-${{ hashFiles('**/Gemfile.lock') }}
    restore-keys: |
      ${{ runner.os }}-gem-

- uses: actions/cache@v2
  with:
    path: /usr/local/bundle
    key: ${{ runner.os }}-bundle-${{ hashFiles('**/Gemfile.lock') }}
    restore-keys: |
      ${{ runner.os }}-bundle-

- name: bundle
  working-directory: ./app
  run: |
    bundle install --jobs 4 --retry 3

@dnorth98 Thanks, will take a look at that. I’m not sure that would help for apt packages that may place files in varying locations with various dependencies but for tools or app package dependencies that I control the destination more that may be of use.

A Docker image would be another possibility as long as Linux only is fine for your project. You can containerize an entire build environment including dependencies and it’s just a single, rather fast pull. It probably doesn’t beat a cache though.