Can't update git gem

[natematykiewicz]

My company has an internal gem. It's common practice to create a PR for the gem, then also create a PR for a Rails app that uses the gem. While the gem is still being PRed, the Gemfile line includes , git: 'url_to_gem', branch: 'branch-name' on the gem line. This allows our CI to install the gem from git, and see that everything end-to-end is working. Once the gem PR gets merged and version bumped, you get rid of the git/branch parts and just use the latest version from the gem server (GitHub Packages).

Today we ran into this interesting error in the Rails app. We recently switched from manual actions caches to the bundler-cache: true option. Now we're running into this (which does not occur on our local machines):

Failing log lines

  Found cache for key: setup-ruby-bundler-cache-v3-ubuntu-16.04-ruby-2.5.1-Gemfile.lock-4df73a010035f3baf6748b02b8f750288aceaf4ffd78f98ca0877135bf64a6f4
  /opt/hostedtoolcache/Ruby/2.5.1/x64/bin/bundle install --jobs 4
  You are trying to install in deployment mode after changing
  your Gemfile. Run `bundle install` elsewhere and add the
  updated Gemfile.lock to version control.
  
  If this is a development machine, remove the
  /home/runner/work/reponame/reponame/Gemfile freeze
  by running `bundle config --delete deployment`.
  
  The list of sources changed
  
  You have added to the Gemfile:
  * source:
  https://machineuser@github.com/org/gemname.git (at
  branchname)
  
  You have deleted from the Gemfile:
  * source:
  https://machineuser@github.com/org/gemname.git (at
  branchname@56c6708)
  Took   2.14 seconds

Workflow YML

strategy:
  fail-fast: false
  matrix:
    os: [ ubuntu-16.04 ]
    ruby: [ .ruby-version ]

runs-on: ${{ matrix.os }}

env:
  BUNDLE_RUBYGEMS__PKG__GITHUB__COM: ${{ secrets.GH_GEMS_AUTH }}
  RAILS_ENV: test
  EAGER_LOAD: 1

steps:
  - uses: actions/checkout@v2

  - run: sudo apt-get -y install libpq-dev

  - uses: ruby/setup-ruby@v1
    with:
      ruby-version: ${{ matrix.ruby }}
      bundler-cache: true

[eregon]

Do you have a checked-in Gemfile.lock?
I think that can't work if you change the gem being developed, as the Gemfile.lock will record which revision was used.

So if you change the Gemfile, you should probably delete the Gemfile.lock.

[natematykiewicz]

We do have a Gemfile.lock checked in! It's got this in it:

GIT
  remote: https://machineuser@github.com/org/repo.git
  revision: sha-goes-here
  branch: branch-name
  specs:
    [dependencies here]

The bundle install works locally. I feel like the problem has to do with gem caching somehow.

[eregon]

Are you changing the Gemfile in the workflow, or is it not in sync with the Gemfile.lock?

The only thing here that seems relevant is:
https://github.com/ruby/setup-ruby#caching-bundle-install-automatically

If there is a Gemfile.lock (or $BUNDLE_GEMFILE.lock or gems.locked), bundle config --local deployment true is used.

It doesn't seem a good idea to change the lockfile without the gemfile or vice-versa anyway.

Can you run the exact commands of the workflow locally, including the bundle config ... as mentioned in the issue template?
If you're not modifying the Gemfile in the workflow, this is probably a Bundler issue.

[eregon]

Because the cache key includes a hash of the entire Gemfile.lock, and that includes the sha of the git/ssh dependency, I don't think this can possibly be an issue of caching in ruby/setup-ruby.

[natematykiewicz]

The Gemfile and Gemfile.lock are in sync. Running bundle install locally does not change the Gemfile.lock.

Locally, I ran:

bundle config --local path ./vendor/bundle
bundle config --local deployment true
bundle install --jobs 4

Everything installed. We aren't using any manual bundler commands in the workflow. The YAML of the workflow is all of the steps that happen up to installing ruby. The only things afterwards are running rubocop and rspec, but it doesn't even get to those steps.

The bundler version is 1.17.3.

A part that really catches my eye is this:

Found cache for key: setup-ruby-bundler-cache-v3-ubuntu-16.04-ruby-2.5.1-Gemfile.lock-4df73a010035f3baf6748b02b8f750288aceaf4ffd78f98ca0877135bf64a6f4
  /opt/hostedtoolcache/Ruby/2.5.1/x64/bin/bundle install --jobs 4
  You are trying to install in deployment mode after changing
  your Gemfile. Run `bundle install` elsewhere and add the
  updated Gemfile.lock to version control.

I have no idea why the Gemfile would be changed.

Reading this says the problem could be a stale .bundle folder.

Is it possible that old settings from before we used bundler-cache are still in there?

This is what our workflow looked like before we switched to bundler-cache: true

- name: Setup cache key and directory for gems cache
  uses: actions/cache@v1
  with:
    path: vendor/bundle
    key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby }}-${{ hashFiles('**/Gemfile.lock') }}
    restore-keys: |
      bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby }}-

- name: bundle install
  run: |
    bundle config path vendor/bundle
    bundle config https://rubygems.pkg.github.com $github_gems_auth
    bundle install --jobs 4 --retry 3
  env:
    github_gems_auth: ${{ secrets.GH_GEMS_AUTH }}

[natematykiewicz]

Our .gitignore file contains the following (among other things):

# Ignore bundler config.
/.bundle
# and cache.
/vendor/bundle

We aren't intentionally setting any bundler settings, other than the ENV Var for the gem auth.

[natematykiewicz]

I just double checked bundle config locally after running those commands, and I see that frozen is set to true. It wasn't previously. Presumably the same is true for GitHub Actions. Not sure if that's relevant or not.

[natematykiewicz]

I just added the following steps to the workflow, right before setup-ruby.

- run: env | grep BUNDLE
- run: cat .bundle/config

The env returns 1 line, which is the private gem auth key. The cat command errors with a No such file or directory.

[natematykiewicz]

I added a step of:

- run: git diff

It shows no changes.

I'm not sure what else to check. 🤔

[natematykiewicz]

I just tried this and it also fails. Same reason...

env:
  BUNDLE_RUBYGEMS__PKG__GITHUB__COM: ${{ secrets.GH_GEMS_AUTH }}
  RAILS_ENV: test
  EAGER_LOAD: 1

steps:
  - uses: actions/checkout@v2

  - run: sudo apt-get -y install libpq-dev

  - uses: ruby/setup-ruby@v1
    with:
      ruby-version: ${{ matrix.ruby }}

  - name: Setup cache key and directory for gems cache
    uses: actions/cache@v1
    with:
      path: vendor/bundle
      key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby }}-${{ hashFiles('**/Gemfile.lock') }}
      restore-keys: |
        bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby }}-

  - name: bundle install
    run: |
      bundle config --local path vendor/bundle
      bundle config --local deployment true
      bundle install --jobs 4 --retry 3

I removed the bundle config --local deployment true and it works. Why would that be?

[natematykiewicz]

Okay I figured it out. The deployment thing helped me find the problem.

Each dev on our team has bundler credentials for the rubygems.pkg.github.com in our machines (in bundle config). The system reads this out and uses it for the auth for the git gems as well (a custom helper in the Gemfile). Well... we were adding the auth into the git: part of the Gemfile (https://user@token.github.com), which I just realized is written into the lock file. Each dev has their own credentials, which means each dev (or CI) that bundle installs actually changes the Gemfile.lock's remote line to include their own token. Since we weren't using the deployment flag before, we didn't realize the lock file was changing.

I was able to leverage Bundler.settings.set_global instead, to maintain a consistent Gemfile.lock that doesn't contain a token.

Thanks for trying to help me figure this out. All is working with bundler-cache: true now!

Thanks for your work on setup-ruby.