I'm running danger on Travis CI from a pull request.
Danger shouldn't crash.
There is no comment on a PR and in the travis log I see the following error:
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.
From https://github.com/php-coder/mystamps
* [new tag] 0.1 -> 0.1
* [new tag] 0.1.1 -> 0.1.1
* [new tag] 0.1.2 -> 0.1.2
* [new tag] 0.1.3 -> 0.1.3
* [new tag] 0.2 -> 0.2
* [new tag] 0.3 -> 0.3
/home/travis/.rvm/gems/ruby-2.2.5/gems/danger-4.3.2/lib/danger/scm_source/git_repo.rb:77:in `find_merge_base': Cannot find a merge base between danger_base and danger_head. (RuntimeError)
from /home/travis/.rvm/gems/ruby-2.2.5/gems/danger-4.3.2/lib/danger/scm_source/git_repo.rb:16:in `diff_for_folder'
from /home/travis/.rvm/gems/ruby-2.2.5/gems/danger-4.3.2/lib/danger/danger_core/dangerfile.rb:259:in `setup_for_running'
from /home/travis/.rvm/gems/ruby-2.2.5/gems/danger-4.3.2/lib/danger/danger_core/dangerfile.rb:269:in `run'
from /home/travis/.rvm/gems/ruby-2.2.5/gems/danger-4.3.2/lib/danger/danger_core/executor.rb:27:in `run'
from /home/travis/.rvm/gems/ruby-2.2.5/gems/danger-4.3.2/lib/danger/commands/runner.rb:66:in `run'
from /home/travis/.rvm/gems/ruby-2.2.5/gems/claide-1.0.1/lib/claide/command.rb:334:in `run'
from /home/travis/.rvm/gems/ruby-2.2.5/gems/danger-4.3.2/bin/danger:5:in `<top (required)>'
from /home/travis/.rvm/gems/ruby-2.2.5/bin/danger:22:in `load'
from /home/travis/.rvm/gems/ruby-2.2.5/bin/danger:22:in `<main>'
from /home/travis/.rvm/gems/ruby-2.2.5/bin/ruby_executable_hooks:15:in `eval'
from /home/travis/.rvm/gems/ruby-2.2.5/bin/ruby_executable_hooks:15:in `<main>'
This issue is reproduced on one of my PRs and danger doesn't work at all :(
Does 4.3.1?
4.3.2 Should I try 4.3.1?
There were changes around this in 4.3.2 - CHANGELOG
Might be worth seeing if they affected you.
No, it's definitely not related to a new version because another PR is also running on a new version and doesn't fail with such error.
Sounds like this is a dupe of https://github.com/danger/danger/issues/768 then
Sounds like this is a dupe of #768 then
Duplicate of itself? :)
No, it's definitely not related to a new version because another PR is also running on a new version and doesn't fail with such error.
I was wrong, it fails on both of PRs. I'm trying to rollback to 4.3.1
I confirm that rolling back to 4.3.1 is solving this error.
I wonder if different versions of git have different behaviour here, can you leave some breadcrumbs in #660 so that you or others can debug 馃憤
I'm not sure that this issue is the same as #660 because error messages and stack traces are different.
Changes due to #660 were the only thing that shipped in 4.3.1
Could it be related to custom git clone depth in TravisCI?
git:
depth: 1
Yep, that would make sure that the commits Danger is looking for would need to be re-downloaded
We had this error because there were two branches with the same name: feature/iOS-11 and feature/ios-11 (a mistake). Deleting one of the branches fixed the error.
The tricky thing is that PR's unrelated to these branches were failing, so out of nowhere, all PR's were failing.
Could there be some branch naming collision "bug" in Danger?
Related: https://stackoverflow.com/a/38494084/826435
bundler: failed to load command: danger (/Users/behance/.rbenv/versions/2.3.1/bin/danger)
RuntimeError: Cannot find a merge base between danger_base and danger_head.
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.3.2/lib/danger/scm_source/git_repo.rb:104:in `find_merge_base'
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.3.2/lib/danger/scm_source/git_repo.rb:16:in `diff_for_folder'
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.3.2/lib/danger/danger_core/dangerfile.rb:259:in `setup_for_running'
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.3.2/lib/danger/danger_core/dangerfile.rb:269:in `run'
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.3.2/lib/danger/danger_core/executor.rb:27:in `run'
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.3.2/lib/danger/commands/runner.rb:66:in `run'
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/claide-1.0.2/lib/claide/command.rb:334:in `run'
/Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.3.2/bin/danger:5:in `<top (required)>'
/Users/behance/.rbenv/versions/2.3.1/bin/danger:22:in `load'
/Users/behance/.rbenv/versions/2.3.1/bin/danger:22:in `<top (required)>'
Build step 'Execute shell' marked build as failure
[BFA] Scanning build for known causes...
[BFA] No failure causes found
[BFA] Done. 0s
I have this issue too with jenkins and Bitbucket.
This is our config:

And what it does:

I'm seeing this as well with Jenkins and Github. We are doing shallow clones with a depth of 1 and the error appears to be sporadic.
Most of the time the job works fine, but ~20% it runs into the error. Usually running the job again seems to fix it which makes it even more confusing for us to track down.
Seems almost like it bails every time fetch has to do either a forced update or gets a new ref.
Just dropping a breadcrumb: we were doing shallow clones on CI for PR builds and once the # of commits on that PR surpassed that depth, it started failing with this error
It feels like danger does some black magic to get the base and the HEAD, which is not really compatible to what shallow clone is about. What helped to me is adding master additionally to refspec: +refs/pull/${ghprbPullId}/merge:refs/remotes/origin/pr/${ghprbPullId}/merge +refs/heads/master:refs/remotes/origin/master and then defining base and the head on my own while calling danger like: danger --head=\$(git rev-parse HEAD) --base=\$(git rev-parse origin/master) ....
I think I forgot to comment on an update.
I'm pretty sure that what @rob-keepsafe said worked. We had shallow clone of depth 1, and once it was changed to shallow clone of depth 100 it has worked since. The 100 is just a random number to maximize the chance of this issue _not_ happening.
Most helpful comment
Just dropping a breadcrumb: we were doing shallow clones on CI for PR builds and once the # of commits on that PR surpassed that depth, it started failing with this error