Run Dependency Group updates

[Nishnha]

This PR is stacked on top of #7074

I have tried to make each commit represent a single file change for this PR.

Things to note:

The main contribution of this PR is that it introduces a new class, the DependencyGroupEngine, which registers DependencyGroups based on values passed in from an Update Job.

The engine is not called directly, but dependency groups are made available to the Updater through 2 methods:

• DependencySnapshot#groups
• DependencySnapshot#ungrouped_dependencies

Here is what the job summary for 2 dependency groups looks like:

+------------------------------------------------------------------------------------------------------------------------------------+
|                                                Changes to Dependabot Pull Requests                                                 |
+---------+--------------------------------------------------------------------------------------------------------------------------+
| created | @emotion/react ( from 11.10.5 to 11.10.6 ), @emotion/styled ( from 11.10.5 to 11.10.6 )                                  |
| created | gatsby ( from 5.6.0 to 5.8.1 ), gatsby-cli ( from 5.6.0 to 5.8.0 ), gatsby-plugin-emotion ( from 8.6.0 to 8.8.0 ), ga... |
+---------+--------------------------------------------------------------------------------------------------------------------------+

This implementation will only run dependencies that belong to a dependency group. It does not try to generate any PRs for ungrouped dependencies.

[brrygrdn]

This looks great! I really like the split out responsibilities between DependencyGroup and the DependencyGroupEngine.

I have a few minor notes, but my longer thought on making the DependencyGroupEngine an instance rather than a 'singleton-like' class is probably worth doing separately. Ruby class variables have a lot of gotchas so while they work it's generally not the preferred idiom and I think we get a side benefit that when we start to do more rule validation we can throw any parsing errors at a nice and clear point in the code later.

[Nishnha]

This PR is in kind of a weird state because I had it stacked on top of https://github.com/dependabot/dependabot-core/pull/7074/commits which I then squashed into main.

The merge commit brings this branch back up to date with main, but there are a couple of commits, namely ff792bc and e8a2b4b, that were also present in the stacked PR that I squashed.

So those 2 commits are kind of unnecessary? If you diff them with main they look (mostly) empty.

Anyhow, I'm going to continue rolling forward with commits on this branch. If we want to have a cleaner history I'd be happy to re-open this branch as a new PR but I don't want to rebase and lose @brrygrdn's comments here.

[Nishnha]

Based on some of the comments from @brrygrdn, after this PR lands I'm going to follow up with a refactor of the DependencyGroupEngine with the goals being:

• make DependencyGroupEngine a class that is instantiated by a DependencySnapshot
• time how long dependency group rules checking takes and attempts a more performant check
• handle errors that result during dependency group rules checks

[Nishnha]

I see this test failure in the updater spec but I can't recreate it locally ☹️

Failures:

  1) Dependabot::Updater#run with the grouped experiment enabled updates multiple dependencies in a single PR correctly
     Failure/Error:
       expect(service).to receive(:create_pull_request) do |dependency_change, base_commit_sha|
         expect(dependency_change.updated_dependencies.first).to have_attributes(name: "dummy-pkg-b")
         expect(dependency_change.updated_dependency_files_hash).to eql(
           [
             {
               "name" => "Gemfile",
               "content" => fixture("bundler/updated/Gemfile"),
               "directory" => "/",
               "type" => "file",
               "mode" => "100644",

       (#<Dependabot::Service:0x00007ff524fb8d28 @client=#<InstanceDouble(Dependabot::ApiClient) (anonymous)>, @pull_requests=[], @errors=[]>).create_pull_request(*(any args))
           expected: 1 time with any arguments
           received: 2 times with any arguments
     # ./spec/dependabot/updater_spec.rb:2206:in `block (3 levels) in <top (required)>'
     # ./vendor/ruby/3.1.0/gems/webmock-3.18.1/lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'

I was thinking of changing the test to be expect(service).to receive(:create_pull_request).at_least(:once) do ... but I'm not sure why :create_pull_request is getting called more than once in the first place?

[brrygrdn]

👍🏻

[brrygrdn]

👍🏻

[brrygrdn]

I was thinking of changing the test to be expect(service).to receive(:create_pull_request).at_least(:once) do ... but I'm not sure why :create_pull_request is getting called more than once in the first place?

Yeah, that's odd - it seems like it should only be called once. It might be worth just adding a puts statement to throw out the dependency_group name/identity at the start of the Service#create_pull_request method just in case there is a mystery guest in the test setup?

I'm thinking that due to the DependencyGroupEngine being a singleton, it might mean that rules declared in other tests are leaking when ran in CI as part of a full suite? We could also put a before to reset the group rule engine to check?

[Nishnha]

I'm thinking that due to the DependencyGroupEngine being a singleton, it might mean that rules declared in other tests are leaking when ran in CI as part of a full suite?

Looks like it was a leaky dependency group! I fixed this in 9ac2f7e by no longer registering a DependencyGroup for the job spec.
The test checks whether the :register_dependency_groups method was called on job creation, but we don't actually need to have a dependency group registered for this test to pass.

[brrygrdn]

Nice, let's 🚀