Docker build failing to use vendor cache

[stephenhyde]

Hi! So this is probably me issue but tried a few things to speed up my docker build in github actions as bundle is taking a majority of the time. 6 mins ! I am sure this will be helpful to others as I scoured the internet looking. I figured docker just didn't have the cache so the last thing I landed on was trying to copy it to /vender/bundle but still doesn't seem to use it.

Docker File

FROM ruby:2.6.6
RUN apt-get update -qq && apt-get install -y nodejs postgresql-client
WORKDIR /1v1Me-API

COPY Gemfile /1v1Me-API
COPY Gemfile.lock /1v1Me-API
COPY vendor/bundle /vendor/bundle/
RUN bundle install

COPY . /1v1Me-API

RUN bundle exec rake assets:precompile

# Add a script to be executed every time the container starts.
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]

GitHub Action (Snippet)

    - uses: actions/checkout@v3
    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: '2.6.6' # Not needed with a .ruby-version file
        bundler-cache: true # runs 'bundle install' and caches installed gems automatically

    - name: Build, tag, and push image to Amazon ECR
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        ECR_REPOSITORY: api-dev
        IMAGE_TAG: ${{ steps.split.outputs.fragment }}
      run: |
        echo "$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
        echo "${{ github.head_ref || github.ref_name }}"
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

I figure this prob not an issue with this library but any help be greatly appreciated!

[stephenhyde]

Looking at your build in github i do notice

/opt/hostedtoolcache/Ruby/2.6.6/x64/bin/bundle config --local path /home/runner/work/1v1Me-API/1v1Me-API/vendor/bundle

before bundle install so maybe I am just copying nothing over?

[eregon]

I think there is simply no way to use a GitHub action inside a Docker image.
You could try to copy the gems like you attempt here but this will most likely not work since the Ruby, paths, packages, OS, OS version, etc outside and inside the image will differ. It might work for pure-Ruby gems, but for C extensions it's unlikely to work.

Maybe you could use some Docker-level step caching instead if the first part of your Dockerfile doesn't change often? Or even build your image based on another image which already did the bundle install and is only rebuilt when there is a change to Gemfile.lock?

[stephenhyde]

I had the same concerns last night, there no guarantee the libc ruby gems that I copy from the action operating system could match my base image os. I do agree this may be the wrong way to go about it.

I am going to try buildx driver to do layer caching to see if that helps. Another option is copying out the vendor from the container and putting that into cache then mounting it back on a subsequent run. Later not idea but I was under the impression layer caching wouldn't work with bundle install but going to give it another shot.

[stephenhyde]

Okay figured out a solution. Definitely looking in the wrong place. For some reason I didn't think docker caching would understand the gemlock file changing.

   - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v2

    - name: Build and push
      uses: docker/build-push-action@v3
      with:
        context: .
        push: true
        tags: |
          ${{ steps.login-ecr.outputs.registry }}/api-dev:${{ steps.split.outputs.fragment }}
        cache-from: type=gha
        cache-to: type=gha,mode=max

This did the trick. Got the total build time down to a minute.

[stephenhyde]

Hopefully I can help out the next poor soul doing CI lol