Update vendored gems when updating with bundler

[jdelStrother]

What would you like Renovate to be able to do?

When submitting a PR to update a bundler dependency, it would be nice if Renovate updated the vendored gems in cache_path in addition to just tweaking the version numbers in Gemfile & Gemfile.lock

I set up https://github.com/jdelStrother/renovate-gem-caching as a test case, which caches its gems here - https://github.com/jdelStrother/renovate-gem-caching/tree/main/vendor/cache

Here's Renovate's PR, which bumps the Gemfile version, but doesn't touch vendor/cache.

And for comparison here's Dependabot's PR, which bumps the Gemfile version, and includes the updated gems. (You can opt in to this with vendor:true in dependabot's settings)

Tell us what requirements you need solving, and be sure to mention too if this is part of any "bigger" problem you're trying to solve

I'm running tests with github actions and an installation step like:

      - uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true
          ruby-version: 2.7

which fails with Some gems seem to be missing from your vendor/cache directory during bundle install if the cache directory isn't kept up-to-date with new gem versions.

[github-actions]

Thank you for providing a reproduction! 🎉 🚀

The Renovate team will take a look at the reproduction repository.

[rarkins]

We will want to do this automatically without needing it to be opted into. i.e. if vendored files are detected then we commit any updates to them.

The question is: how to detect if they're pre-existing? e.g. presence of vendor/cache directory or some other single source of truth?

Should be similar to how we do it in Composer/PHP

[booleanbetrayal]

We would also like this functionality and cache to the standard vendor/cache path, in case it helps. We've been bitten by CDN outages in the past so prefer to commit these in our repo.

[barillax]

@rarkins I agree that simply checking for the existance of any .gem files in the /vendor/cache directory should be sufficient to understand if the project is vendoring gems. That said, I could imagine it would make sense to have an override flag for explicitly toggling the behavior, if that's a common pattern.

[booleanbetrayal]

Just checking to see if anyone is actively looking / prioritizing this issue.

[rarkins]

I'm not aware of anyone working on it, but considering we have a few other managers doing similar/same things, it should not be particularly complex for a community contribution.

[siebertm]

FYI, I was able to solve this using postUpdateTasks configuration:

In the repository config, I have

{
  "packageRules": [
    {
      "matchManagers": ["bundler"],
      "postUpgradeTasks": {
        "commands": ["bundle package --all --all-platforms"],
        "fileFilters": ["vendor/cache/**/*"],
        "executionMode": "branch"
      }
    }]
}

In order to allow executing the postUpgradeTask, it has to be enabled in self-hosted config:

{
  "allowedPostUpgradeCommands": ["^bundle package"]
}

Now, we have updated vendor/cache in our MRs. Profit!