Fix Duplicate Dependencies Showing in PR summary table

[honeyankit]

Context

This PR resolves the issue of duplicated entries in the group update PR's summary table by ensuring that only unique dependencies are considered in the message builder. These are then displayed in the PR summary table.

Fixes: #7695

[honeyankit]

I started searching about why we are getting duplicate dependencies and got my answer here so made changes in the message builder.

 #<Dependabot::Dependency:0x0000ffffa6e74c48
  @metadata={:directory=>"/"},
  @name="tapioca",
  @package_manager="bundler",
  @previous_requirements=[{:requirement=>">= 0", :groups=>[:development], :source=>nil, :file=>"Gemfile"}],
  @previous_version="0.12.0",
  @removed=false,
  @requirements=[{:requirement=>">= 0", :groups=>[:development], :source=>nil, :file=>"Gemfile"}],
  @version="0.13.1">,

 #<Dependabot::Dependency:0x0000ffffa6e85458
  @metadata={},
  @name="tapioca",
  @package_manager="bundler",
  @previous_requirements=[{:requirement=>">= 0", :groups=>[:development], :source=>nil, :file=>"Gemfile"}],
  @previous_version="0.12.0",
  @removed=false,
  @requirements=[{:requirement=>">= 0", :groups=>[:development], :source=>nil, :file=>"Gemfile"}],
  @version="0.13.1">,

[jurre]

Can we add a test to prevent regression?

[honeyankit]

Can we add a test to prevent regression?

I have tested against the test repo. I am adding the test.

[Nishnha]

There's also a mention of the table showing a dependency updating from a commit to a version, even though they didn't actually update: #7695 (comment)

Is a fix for that going to be part of this PR?

[honeyankit]

There's also a mention of the table showing a dependency updating from a commit to a version, even though they didn't actually update: #7695 (comment)

Is a fix for that going to be part of this PR?

No. This will fix the duplicate entry. I can look into that as well. But first will let this ship

[Nishnha]

Since we're only uniq'ing by name, wouldn't the dependencies that gets removed from the PR body be random? I wonder if the "to" and "from" version can change for a duplicate dependency if you run the same job twice

The note at

dependabot-core/updater/lib/dependabot/updater/dependency_group_change_batch.rb

Lines 65 to 71 in d53fce0

	# We should retain a list of all dependencies that we change, in future we may need to account for the folder
	# in which these changes are made to permit-cross folder updates of the same dependency.
	#
	# This list may contain duplicates if we make iterative updates to a Dependency within a single group, but
	# rather than re-write the Dependency objects to account for the changes from the lowest previous version
	# to the final version, we should defer it to the Dependabot::PullRequestCreator::MessageBuilder as a
	# presentation concern.

recommends keeping the dependency with the lowest previous version but idk if that's why it was suggested

[honeyankit]

@Nishnha : For less then 5 dependencies for group PR, similar approach is used here where by the dependency name the unique dependencies are filtered. So I have just refer that for more then 5 dependencies.

[Nishnha]

@Nishnha : For less then 5 dependencies for group PR, similar approach is used here where by the dependency name the unique dependencies are filtered. So I have just refer that for more then 5 dependencies.

Right but the dependency version isn't displayed for <5 dependencies

[jurre]

We could check for unique by name, from and to to be thorough?

[honeyankit]

@jurre and @Nishnha : I have updated the code to remove duplicates based on name, to and from versions.

1. Both Dep A will be shown

Dep A - previous version 1.2.4 latest version 1.2.5 
Dep A - previous version 1.2.4 latest version 1.2.6 

2. Both Dep A will be shown

Dep A - previous version 1.2.1 latest version 1.2.5 
Dep A - previous version 1.2.4 latest version 1.2.5

[honeyankit]

All the smoke test errors are due to rate limit exceeded.

[Nishnha]

Nice

[edmorley]

@honeyankit @Nishnha @landongrindheim Could this have caused the regression seen in #9457?