Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix dependency constraint on ruby-git #1436

Merged
merged 5 commits into from
May 13, 2023
Merged

Conversation

ainame
Copy link
Contributor

@ainame ainame commented Apr 24, 2023

In this PR #1419, the gemspec for runtime dependency on git was bumped to ~> 1.13.0.

When updating Danger to 9.3.0 today, I noticed the dependency-resolving issue. In my project, bundler has already fixed git at version 1.18.0, so installing danger v9.3.0 means we need to downgrade git. Bundler didn't allows me to do that by default. (I needed to delete Gemfile.lock and re-run bundle install)

This is what we got when updating danger via Renovate.

Fetching gem metadata from https://rubygems.org/........
Resolving dependencies............

Bundler could not find compatible versions for gem "git":
  In snapshot (Gemfile.lock):
    git (>= 1.17.2)

  In Gemfile:
    danger (= 9.3.0) was resolved to 9.3.0, which depends on
      git (~> 1.13.0)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.

Bundler could not find compatible versions for gem "highline":
  In snapshot (Gemfile.lock):
    highline (>= 2.0.3)

  In Gemfile:
    fastlane (= 2.212.2) was resolved to 2.212.2, which depends on
      highline (~> 2.0)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.

Bundler could not find compatible versions for gem "multipart-post":
  In snapshot (Gemfile.lock):
    multipart-post (>= 2.0.0)

  In Gemfile:
    fastlane (= 2.212.2) was resolved to 2.212.2, which depends on
      faraday (~> 1.0) was resolved to 1.10.3, which depends on
        faraday-multipart (~> 1.0) was resolved to 1.0.4, which depends on
          multipart-post (~> 2)

    fastlane (= 2.212.2) was resolved to 2.212.2, which depends on
      multipart-post (~> 2.0.0)

    xcov (= 1.8.1) was resolved to 1.8.1, which depends on
      multipart-post

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.

The previous constraint of being flexible on the minor versions is easier for anyone who has been using Danger.

According to the PR author, there was no reason to limit the version constraint to the patch version.
#1419 (comment)

cc: @manicmaniac

@ainame ainame marked this pull request as ready for review April 24, 2023 11:14
@orta
Copy link
Member

orta commented Apr 24, 2023

Cool, yeah, looks reasonable to me

@orta
Copy link
Member

orta commented Apr 25, 2023

The test fail looks like it would have been caused by this update

@ainame
Copy link
Contributor Author

ainame commented Apr 26, 2023

Let me check the error 👀

Update: It looks like danger with git gem v1.15.0 released last March was supposed to started causing the failed test case but #1419 was already merged last Jan. Danger hasn't been tested with the newer git gem since then. (That would make it difficult to catch up with dependencies in the long run. Another reason why we shouldn't fix the version at the patch level.)

https://github.com/ruby-git/ruby-git/releases/tag/v1.15.0

I will try to fix the failure in this PR.

Update2:

The new feature added to git caused a failure. I mean the test case was expected to get an exception for opening non-root repo dir, but it's not the case with git v1.15.0. It's good, though.

@@ -43,7 +43,7 @@
@dm = testing_dangerfile
expect do
@dm.env.scm.diff_for_folder(dir + "/subdir")
end.to raise_error(ArgumentError, /path does not exist/)
end.to raise_error(ArgumentError, /is not the top level git directory/)
Copy link
Contributor Author

@ainame ainame Apr 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously ArgumentError was caused by Git.open called at git_repo.rb L20 when the path isn't a top-level git directory. But from git gem v1.15.0, Git.open won't cause the error any more.

My change maintains the current intention to keep the backward compatibility but gives a better error message to educate users.

#1178

@ainame ainame marked this pull request as draft April 26, 2023 10:47
@ainame ainame marked this pull request as ready for review April 27, 2023 09:17
end
end
repo = Git.open git_top_level
git_top_level = find_git_top_level_if_needed!(folder, lookup_top_level)
Copy link
Contributor Author

@ainame ainame Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I extracted logic to raise an error to keep the compatibility, but the behaviour should be the same as before, apart from the error message.

end
end

it "looks up the top level git folder when requested" do
with_git_repo do |dir|
@dm = testing_dangerfile
@dm.env.scm.diff_for_folder(dir + "/subdir", lookup_top_level: true)
Copy link
Contributor Author

@ainame ainame Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous spec didn't assert anything. I made the expectation explicit.

@ainame
Copy link
Contributor Author

ainame commented Apr 27, 2023

PR is ready to review now. I confirmed RSpec passed all specs with git v1.13.2 and v1.18.0 locally 🙇

@manicmaniac manicmaniac merged commit 85a2a6f into danger:master May 13, 2023
@ainame ainame deleted the ruby-git branch May 17, 2023 12:40
@Semty
Copy link

Semty commented Jun 2, 2023

@manicmaniac hey! could you, please, like release a new version or something? 🙂

@manicmaniac
Copy link
Member

Sorry I don't have the right to publish new release. @orta can do it.

@orta
Copy link
Member

orta commented Jun 6, 2023

Shipped, thanks @manicmaniac !

@manicmaniac
Copy link
Member

Thanks to @ainame from me 🥇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants