danger: Git Fatal on Danger Branches

Report

What did you do?

Run danger on a pull request using Github/Jenkins.

What did you expect to happen?

Running Dangerfile without seeing git fatals.

What happened instead?

Every build that runs prints fatal: Couldn't find remote ref refs/heads/danger_base and fatal: Couldn't find remote ref refs/heads/danger_base three times each, corresponding to the calls to git_fetch_branch_to_depth. This seems to be tied to the manually assigned refspec, which makes git look for refs/heads/danger_head & refs/heads/danger_base as remote branches, throwing fatals if those branches do not exist.

I’ve manually set refspecs for the job, +refs/pull/*:refs/remotes/origin/pr/* refs/heads/${ghprbTargetBranch}:refs/heads/danger_base refs/pull/${ghprbPullId}/head:refs/heads/danger_head, in my case using the ghprb plugin in Jenkins to provide refs/heads/danger_head & refs/heads/danger_base, but the manual refspec assigned to the fetch command seems to override this anyway.

Why would a remote danger_base or danger_head branch be expected? If it is not expected, do we need the refspec in the fetch? The refspec isn’t included in the call to git_in_depth_fetch which makes me think we don’t need it.

This isn’t a hard error as Danger gets past it each time, but would rather not see fatals unless there is something actually wrong.

Your Environment

Which CI are you running on? Jenkins
Are you running the latest version of Danger? 5.5.3

What is your Dangerfile?

# please paste here, with 2-space identation, thank you!
xcov.report(
   scheme: ENV["FL_XCOV_SCHEME"],
   workspace: ENV["FL_XCOV_WORKSPACE"],
   skip_slack: ENV["FL_XCOV_SKIP_SLACK"],
   derived_data_path: ENV["FL_XCOV_DERIVED_DATA"],
   only_project_targets: true
)
xcode_summary.ignored_files="Pods/**"
xcode_summary.report(ENV["FL_XCS_REPORT"])

About this issue

Original URL
State: open
Created 7 years ago
Reactions: 10
Comments: 16 (4 by maintainers)

Commits related to this issue

ci: add fetch depth for Danger job The Danger job seems to have issues working with shallow clones, update it to have a fetch-depth. Fix based on https://github.com/danger/danger/issues/913 — committed to Chesire/LifecykleLog by Chesire 4 years ago

Most upvoted comments

For the folks who end up stumbling on this issue because they use Github Actions, changing the depth of the check-out fixed the issue for us. Here’s our full danger action, which may help some folks:

name: Run Danger

on: [pull_request]

jobs:
  build:
    name: Run Danger
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v2
        with:
          fetch-depth: 100

      # Setup ruby
      - name: Set up Ruby 2.6
        uses: actions/setup-ruby@v1
        with:
          ruby-version: 2.6

      # Install the right bundler version
      - name: Install bundler
        run: gem install bundler

      # Cache dependencies
      - name: Cache ruby dependencies
        id: cache-ruby
        uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: union-gems-${{ hashFiles('**/Gemfile.lock') }}
          restore-keys: |
            union-gems-

      # Install dependencies on cache miss
      - name: Install ruby dependencies
        if: steps.cache-ruby.outputs.cache-hit != 'true'
        run: |
          bundle config path vendor/bundle
          bundle install --jobs 4 --retry 3 --without=documentation

      # Run danger
      - name: Run danger
        env:
          DANGER_GITHUB_API_TOKEN: ${{ secrets.DANGER_GITHUB_API_TOKEN }}
        run: |
          bundle config path vendor/bundle
          bundle exec danger

+24

fredoliveira on Jun 26, 2020

Having a similar issue that sometimes is there, and sometimes isn’t (has been happening on-and-off for the past year or so):

fatal: Couldn't find remote ref refs/heads/danger_base
fatal: Couldn't find remote ref refs/heads/danger_head
fatal: Couldn't find remote ref refs/heads/danger_base
...

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.6.2/lib/danger/scm_source/git_repo.rb:128:in `find_merge_base'
  /Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.6.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.6.2/lib/danger/danger_core/dangerfile.rb:261:in `setup_for_running'
  /Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.6.2/lib/danger/danger_core/dangerfile.rb:271:in `run'
  /Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.6.2/lib/danger/danger_core/executor.rb:28:in `run'
  /Users/behance/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/danger-5.6.2/lib/danger/commands/runner.rb:68: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.6.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)>'

kgaidis on Jun 14, 2018

@fredoliveira Why does adding fetch-depth: 100 fix the issue? 🤔

hlung on Oct 21, 2022

This is still an issue today. I’m lucky I discovered this by perusing the PR and seeing this comment:

https://github.com/danger/danger/issues/768#issuecomment-398893158

bdrelling on May 13, 2020

Danger gets the difference between the base of your PR and the head by looking at the commit history between them, if they are not available then Danger fails

orta on May 5, 2023

@fredoliveira Why does adding fetch-depth: 100 fix the issue? 🤔

I would also like to know this lol

jpmcglone on May 4, 2023

Just putting an update for others who may view this in the future.

My issue was “fixed” by looking into shallow clone: https://github.com/danger/danger/issues/768#issuecomment-398893158

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.

kgaidis on Jan 10, 2019