Support vendoring for Ruby about dependabot-core

[agrobbin]

I'd like to also advocate for this support. We are currently large paid users of Dependabot, and are looking to improve our build/CI/deployment times significantly by vendoring our .gem packages into the Git repo.

I'm happy to do what I can to support this initiative @greysteil!

[dentarg]

I think this issue should be kept open.

[snowblink]

Why not make it a feature of a paid tier?

[greysteil]

I don't work on Dependabot any more (I'm focussed on GitHub's code scanning product these days), but @feelepxyz, @jurre and @hmarr should be able to help.

I do know that adding support for vendoring is quite a big project on the Dependabot side, and that they've been flat out on the work to integrate Dependabot into GitHub with only a small team!

[feelepxyz]

@greysteil Because of this, we are trying to ignore a vendored gem using the new config file option, but the updater job on Github tries to fetch the gem regardless, which makes the entire update job fail.

It seems the ignore should happen prior to the attempt at fetching the gems.

@LQkkeN yeah this is a known limitation with how we run updates. When you ignore a dependency we only ignore it when checking for new versions but as soon as we try to update some other package we try to resolve all dependencies in your manifest/lockfile which cause the update to fail if there are vendored gems that can't be fetched.

Would love to figure out a workaround to this where we keep the guarantees of not-breaking your manifest but also handle cases where we can't fetch the dependency. This and actually supporting vendoring are both big projects so they are a while out. We're focusing on integrating Dependabot natively with GitHub for the next few months and after that, we're probably going to focus on making Dependabot less noisy with the amount of PRs it generates. Vendoring will hopefully follow after that.

[dentarg]

I think this issue is solved! https://github.blog/changelog/2020-09-23-dependabot-supports-vendoring-for-ruby-bundler/ (and it is the same as #2152)

[jurre]

Yep, this is now supported 👍

[greysteil]

Hmmm, at the moment Dependabot doesn't support vendoring. It would be nice to add it, but I think it's going to be hard to do so performantly - downloading all those dependencies using bundle package would take a lot of time on our end. We currently avoid actually doing any installs for Ruby, which keeps things fast (take a look at dependabot/dependabot-core for all the gory details), and whilst Dependabot is free that's essential.

One hacky solution would be to append something to your CI run that does the vendoring and commits the change, but that's pretty grim...

[greysteil]

Thinking about this one a bit more, I'm going to revise what I said about about why this is hard. The below isn't a particularly "good" reason, but it's what's making this more than a few hours work.

Dependabot has to evaluate code it gets from the internet (your Gemfile, for example), so the creation of each PR works as follows:

1. Dependabot's main backend kicks off an update run by sending a job to the isolated environment
2. The isolated environment evaluates the Gemfile, checks for possible updates, and generates the required code for any PRs
3. The isolated environment passes that generated code back to the backend
4. The backend checks if any PRs already exist, whether the user has asked to ignore them for this version, etc.. If everything is OK, it creates the PR with the generated code

For Dependabot to support vendoring, we'd need to change 3. and 4. slightly, since there's no way the isolated environment could pass around the (large) files involved in updating vendored packages. Instead, the isolated environment should pass back a list of vendored dependencies that need to be updated in step 3., and the main backend should fetch and update them in step 4., assuming this can be done without evaluating any arbitrary code (which rules out running bundle pack).

My hunch is that the first step here is to change the UpdateChecker for Ruby or some other languages to return details of any subdependencies that are being updated in the updated_dependencies method (probably changing the return signature of that method to be a hash, rather than an array).

TL;DR - this is possible, the work required is almost all in this repo, but there's quite a bit of it!

[greysteil]

Thanks @agrobbin. We're a small team so can't work on too many things at once, but @hmarr is planning to look at vendoring for Go in the near future, which will translate quickly to vendoring for all other languages.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.

[LQkkeN]

@greysteil Because of this, we are trying to ignore a vendored gem using the new config file option, but the updater job on Github tries to fetch the gem regardless, which makes the entire update job fail.

It seems the ignore should happen prior to the attempt at fetching the gems.