cache breaks with private packages

[modosc]

whenever Gemfile.lock changes, the first action run always fails, but the second succeeds. we've seen this with prs from dependabot as well as prs opened by humans.

if Gemfile.lock does not change then there's no issue.

we have two different workflows with this issue - both are identical except for the last step (bundle exec brakeman -q vs bundle exec rubocop)

on:
  push:
    branches: [master]
  pull_request:
    branches: [master]

name: Linter

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          # runs 'bundle install' and caches installed gems automatically
          bundler-cache: true
        env:
          BUNDLE_RUBYGEMS__PKG__GITHUB__COM: ${{ secrets.BUNDLE_RUBYGEMS__PKG__GITHUB__COM }}

      - name: Run brakeman
        run: |
          bundle exec brakeman -q

the first run will always fail:

but re-running manually always works:

failing logs: logs_588.zip
passing logs: logs_779.zip

i can't link to the runs because they're from a private repo, do you need anything else here?

[eregon]

This is quite weird.
Did you/Could you try the commands locally to see if you can reproduce? (by setting the env var, not using bundle config)

[modosc]

Did you/Could you try the commands locally to see if you can reproduce? (by setting the env var, not using bundle config)

sure, will verify now. i also realized i left out some info, i'm updating the description appropriately (i opened this originally as a github support ticket because it involved secrets, actions, and dependabot).

[modosc]

Did you/Could you try the commands locally to see if you can reproduce? (by setting the env var, not using bundle config)

also yes, verified this works fine with the env variable:

$  bundle config list
Settings are listed in order of priority. The top value will be used.
gem.changelog
Set for the current user (/Users/modosc/.bundle/config): false

gem.ci
Set for the current user (/Users/modosc/.bundle/config): false

gem.coc
Set for the current user (/Users/modosc/.bundle/config): false

gem.mit
Set for the current user (/Users/modosc/.bundle/config): false

gem.rubocop
Set for the current user (/Users/modosc/.bundle/config): false

gem.test
Set for the current user (/Users/modosc/.bundle/config): false

gemfile
Set via BUNDLE_GEMFILE: "/Users/modosc/git/repo/Gemfile"

rubygems.pkg.github.com
Set via BUNDLE_RUBYGEMS__PKG__GITHUB__COM: "NNNNNNNNNNNNNNNNN"
$ bundle install
...
Bundle complete! 113 Gemfile dependencies, 272 gems now installed.

[simonc]

Hi there. Setting up Dependabot with our CI in Github Actions we encountered the same issue. The build does not pass when Dependabot opens a PR but if I rerun the workflow it passes.

One key difference I see is in the way the env variable BUNDLE_RUBYGEMS__PKG__GITHUB__COM is set. In the case of the failing workflow it's empty.

[eregon]

The fact BUNDLE_RUBYGEMS__PKG__GITHUB__COM is empty sounds very likely to be the cause of this bug.
But that bug must be an issue of secrets or github actions runner.
It can't be of this action which doesn't control any of that, so I'll close this.

I think filing this to GitHub support nmd/or to https://github.com/actions/runner/issues would be the most best way to progress on this issue.

[eregon]

I forgot to mention, in the OP's logs we see the same issues, failing logs has BUNDLE_RUBYGEMS__PKG__GITHUB__COM empty, while the correct run has BUNDLE_RUBYGEMS__PKG__GITHUB__COM: ***, hence it looks exactly the same issue.

[modosc]

I think filing this to GitHub support nmd/or to https://github.com/actions/runner/issues would be the most best way to progress on this issue.

sigh we filed a ticket with github support, they said the problem must be with the 3rd party actions and sent us here. i'm going back to them about this, thanks for your help.

[eregon]

sigh we filed a ticket with github support, they said the problem must be with the 3rd party actions and sent us here. i'm going back to them about this, thanks for your help.

Sorry about that, but they must be wrong, it is undiscutably an issue that secrets are not consistently set when running a job as shown by the logs and the resulting behavior.

[eregon]

Given #230 I'm starting to wonder if env: on a - uses: actually works reliably, or if env: needs to be set at the job level.

[modosc]

Given #230 I'm starting to wonder if env: on a - uses: actually works reliably, or if env: needs to be set at the job level.

unfortunately i tried that but it didn't work.

also github confirmed this issue is expected because REASONS. apparently when dependabot runs there's no way to run the other actions as dependabot as well.