Danger fails on CI when running on PR from a fork in GH Actions / Buddy Build #1103

Goos · 2019-03-08T02:29:08Z

We just set up danger in our repository and it fails when running on PRs from forks.

What did you do?

bundle install  
bundle exec danger --fail-on-errors=true

What did you expect to happen?

It would run danger and find the branch & commit in my fork.

What happened instead?

It failed to find the commits and/or the branch:

fatal: Couldn't find remote ref refs/heads/event-ordering
fatal: Couldn't find remote ref refs/heads/event-ordering
fatal: Couldn't find remote ref refs/heads/event-ordering
fatal: Couldn't find remote ref refs/heads/event-ordering
bundler: failed to load command: danger (/usr/local/bin/danger)
RuntimeError: Commit c2b6bb0b doesn't exist. Are you running `danger local/pr` against the correct repository? Also this usually happens when you rebase/reset and force-pushed.
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/scm_source/git_repo.rb:111:in `raise_if_we_cannot_find_the_commit'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/scm_source/git_repo.rb:93:in `ensure_commitish_exists_on_branch!'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/request_sources/github/github.rb:112:in `setup_danger_branches'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/danger_core/environment_manager.rb:57:in `ensure_danger_branches_are_setup'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/danger_core/dangerfile.rb:259:in `setup_for_running'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/danger_core/dangerfile.rb:270:in `run'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/danger_core/executor.rb:29:in `run'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/lib/danger/commands/runner.rb:72:in `run'
/Library/Ruby/Gems/2.3.0/gems/claide-1.0.2/lib/claide/command.rb:334:in `run'
/Library/Ruby/Gems/2.3.0/gems/danger-5.14.0/bin/danger:5:in `<top (required)>'
/usr/local/bin/danger:22:in `load'
/usr/local/bin/danger:22:in `<top (required)>'

Your Environment

Which CI are you running on?
Buddybuild
Are you running the latest version of Danger?
Yup
What is your Dangerfile?

warn("PR is classed as Work in Progress") if github.pr_title.include? "[WIP]"

swiftlint.lint_files fail_on_error: true

The text was updated successfully, but these errors were encountered:

orta · 2019-03-08T02:45:14Z

Did that commit exist in the repo?

Goos · 2019-03-08T02:47:21Z

@orta yeah the commit exists but it seems like it's trying to look at the wrong remote (origin) instead of my fork.

orta · 2019-03-08T02:48:34Z

Ah cool, might be worth looking that the buddy build part of the codebase and compare it to the env vars that bb shows and see If they need changing

Goos · 2019-03-08T02:57:52Z

@orta thanks for the quick response – this part right here looks like it's defaulting to the origins, if I'm reading it correctly. Would it be possible to use the slug to construct a URL instead somehow?

orta · 2019-03-08T03:01:27Z

I'm unsure, I've never used buddy build: maybe there's an API? maybe there's another remote on the repo? Maybe there's another env var?

Goos · 2019-05-07T00:11:37Z

Hey! Gonna resurrect this issue because I forgot about it for a while. @orta do you know what the repo_url is actually used for? It seems to me that we should be able to know where to fetch the changes from even without the repo_url since we have the repo_slug (i.e. {username}/{repo}). Is there any way we can construct a repo_url by using the slug somehow?

JohnRoesler · 2020-02-25T12:56:33Z

I'm having this same issue with github actions - danger can't find the commit from the forked repo because it appears to be looking in the origin.

Kaspik · 2020-03-20T13:26:37Z

Yes, happening for us too on public Open Source repo for Github Actions. Can we somehow work around that?

bundler: failed to load command: danger (/usr/local/lib/ruby/gems/2.6.0/bin/danger)
105
RuntimeError: Commit f28e72a0 doesn't exist. Are you running `danger local/pr` against the correct repository? Also this usually happens when you rebase/reset and force-pushed.

Kaspik · 2020-03-20T13:28:00Z

@orta Let me know if you have any idea what to do here - but it could be easy for someone who knows where is Danger looking for wrong remote?

orta · 2020-03-20T18:07:07Z

it looks like danger is not finding the head commit, so the pull from the remote repo seems to be failing somewhere?

I can't really remember where all that code is anymore though, so I'm afraid you'll have to do some digging to find the commands it runs and try see why danger can't find the commits.

Kaspik · 2020-03-20T18:13:44Z

@orta I already did today, and I think I'm not sure if setup_danger_branches in github.rb:112 is getting the right stuff, if so, then ensure_commitish_exists_on_branch (git_repo:99) uses origin as remote and it might not be the correct one - and I wasn't able to dig into that and get the info from that.

I just checked other repos and it looks like all frameworks / repos / projects not only on Github have the same issue with Forks and some of them just removed Danger for open source with many fork PRs... which is sad 😢

/usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/scm_source/git_repo.rb:117:in `raise_if_we_cannot_find_the_commit'
107
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/scm_source/git_repo.rb:99:in `ensure_commitish_exists_on_branch!'
108
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/request_sources/github/github.rb:112:in `setup_danger_branches'
109
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/danger_core/environment_manager.rb:58:in `ensure_danger_branches_are_setup'
110
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/danger_core/dangerfile.rb:259:in `setup_for_running'
111
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/danger_core/dangerfile.rb:270:in `run'
112
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/danger_core/executor.rb:29:in `run'
113
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/lib/danger/commands/runner.rb:73:in `run'
114
  /usr/local/lib/ruby/gems/2.6.0/gems/claide-1.0.3/lib/claide/command.rb:334:in `run'
115
  /usr/local/lib/ruby/gems/2.6.0/gems/danger-6.3.1/bin/danger:5:in `<top (required)>'
116
  /usr/local/lib/ruby/gems/2.6.0/bin/danger:23:in `load'
117
  /usr/local/lib/ruby/gems/2.6.0/bin/danger:23:in `<top (required)>'

I gave up after about two hours...

orta · 2020-03-20T18:20:19Z

I'd be very surprised if all projects using forks are seeing this, this issue has been open for a year and danger is used extensively in open source projects. I'm not sure why it's working in these cases though.

The code here looks correct though, both head and base references are requested - and if those commands fail then it should also raise I believe

danger/lib/danger/request_sources/github/github.rb

Lines 99 to 114 in c51e39c

    
           def setup_danger_branches 
        
             # we can use a github specific feature here: 
        
             base_branch = self.pr_json["base"]["ref"] 
        
             base_commit = self.pr_json["base"]["sha"] 
        
             head_branch = self.pr_json["head"]["ref"] 
        
             head_commit = self.pr_json["head"]["sha"] 
        
             # Next, we want to ensure that we have a version of the current branch at a known location 
        
             scm.ensure_commitish_exists_on_branch! base_branch, base_commit 
        
             self.scm.exec "branch #{EnvironmentManager.danger_base_branch} #{base_commit}" 
        
             # OK, so we want to ensure that we have a known head branch, this will always represent 
        
             # the head of the PR ( e.g. the most recent commit that will be merged. ) 
        
             scm.ensure_commitish_exists_on_branch! head_branch, head_commit 
        
             self.scm.exec "branch #{EnvironmentManager.danger_head_branch} #{head_commit}" 
        
           end

Kaspik · 2020-03-23T09:30:35Z

And isn't that exactly the problem?

github.rb:112:in `setup_danger_branches'

which means

scm.ensure_commitish_exists_on_branch! head_branch, head_commit

raises an issue...

It seems like git_fetch_branch_to_depthis fetching from wrong place then:

danger/lib/danger/scm_source/git_repo.rb

Line 108 in c51e39c

def git_fetch_branch_to_depth(branch, depth)

Can you point me to any open source repo with Danger and PR from fork that works, please? I'll do my best to find out what's happening...

orta · 2020-03-24T19:25:50Z

This repo has had a few PRs from forks, here's a PR which still has a danger comment: #1207

Kaspik · 2020-03-24T19:46:47Z

Thanks @orta , that might help!

I can see that Circle CI job has setup:

danger/.circleci/config.yml

Line 24 in 69809e8

    
           - run: '[ ! -z $DANGER_GITHUB_API_TOKEN ] && bundle exec danger || echo "Skipping Danger for External Contributor"'

      - run: '[ ! -z $DANGER_GITHUB_API_TOKEN ] && bundle exec danger || echo "Skipping Danger for External Contributor"'
      - run: bundle exec danger init --mousey --impatient

Looking at the Circle CI run on given job, I can see that it skipped the first one due to external contributor, and then tried the second run - https://app.circleci.com/pipelines/github/danger/danger/2/workflows/8f64a9de-41c2-43e7-97ad-1e70eb7084cd/jobs/2865

What exactly the mousey and impatient do? Could it be that?

orta · 2020-03-24T19:53:53Z

Travis should be the one running the dangerfile for PRs (need to test many CIs, but don't want it spamming and confusing for others)

Though I don't see the status, here's the run: https://travis-ci.org/github/danger/danger/jobs/666482321#L2452

mousey and impatient are options to init which makes it not output so much and not wait for user input during the process, that's mainly a lint that the init command works and not useful here alas

Kaspik · 2020-04-06T20:32:14Z

@orta Tried to dig into this. I'm pretty sure this is Danger issue - it's not an issue on Travis, it would be on Circle CI and is on Github Actions.

Lately, even Google and Firebase tried to do it, with no luck: firebase/firebase-ios-sdk#5244

Would you mind trying to setup Github Actions for this repo too? We could play with it then (me from fork for example) and find the issue potentially.

orta · 2020-04-06T21:09:28Z

I've got a PR with it running: #1210 - though it's not from a fork

orta · 2020-04-06T21:49:31Z

Looks like what GitHub Actions does is:

Clone danger/danger

Create a merge commit with the changes in the PR into it

 /usr/bin/git log -1

 commit ac8589d580c00e773bf8e8dcb8bf9ba62bf1147c

 Author: Orta <orta.therox+github@gmail.com>

 Date:   Mon Apr 6 17:40:52 2020 -0400

  Merge 90137a1b12581aab3efa299c1a37776c7998e91b into c577853adbdc50b36b5ed06cf1a195f8554e1c21

Then it uses that as head, so the actual commit from your fork isn't there at all. Which is why danger never finds the HEAD commit from the PR metadata.

This is likely because other CIs clone your repo fork, where as these other one's clone the main repo and merge the changes in.

There are two valid options from my perspective:

Check to see if it's a fork PR and if it is also make sure that the fork is fully fetched as well as the main repo
Allow GitHub Actions, and others to use HEAD instead of the real PR head (which isn't available)

I don't mind either route

Kaspik · 2020-04-06T21:54:37Z

Sounds like the first would take more time as it would be cloning/fetching two repos where the second one would be just using different commit as HEAD, right?

Honestly I don't care, but it's great to see this moving, thank you so much!

I just wonder - is this issue also an issue for Danger-Swift for example? Or do they use this main danger under the hood?

orta · 2020-04-06T22:10:52Z

Nah, only Danger Ruby would get this - the others all use the GH/GL/BB API and don't need local FS access to git for their info.

Your guess is right - it'd have to fetch from two remotes instead of one right now. The latter has a chance for inaccuracy though, it might be a safe assumption that HEAD represents the current tip of the PR, but it might also not. That's why danger is a bit pedantic here and really making sure it knows the full history.

Kaspik · 2020-04-07T20:51:43Z

Let's do what you think is better, or maybe more bulletproof :)

b-onc · 2020-04-10T09:55:32Z

Here to chime in, we're also seeing this behavior in our repo which uses Github Actions.
See GetStream/stream-chat-swift#154 for example

orta · 2020-04-10T11:00:41Z

Cool, then I'd recommend someone make a PR which checks the PR data to make sure both remotes are fetched:

danger/lib/danger/request_sources/github/github.rb

Line 99 in 7da2617

def setup_danger_branches

xorima · 2020-04-10T11:16:38Z

Github Actions also does not pass secrets to any fork builds, which might be a cause.

Danger Ruby just full on doesn't work with forked repos. You can see my and other's many attempts here: danger/danger#1103 (comment) However, the JS version does in fact seem to work well. Move to that. The syntax for the Dangerfile is a bit less pretty, and obviously for a ruby project, we'd prefer a Ruby DSL, but working is better than pretty.

Danger Ruby just full on doesn't work with forked repos. You can see my and other's many attempts here: danger/danger#1103 (comment) However, the JS version does in fact seem to work well. Move to that. The syntax for the Dangerfile is a bit less pretty, and obviously for a ruby project, we'd prefer a Ruby DSL, but working is better than pretty. Signed-off-by: Phil Dibowitz <phil@ipom.com>

Kaspik mentioned this issue Mar 20, 2020

documentation: Loading remote image messages in Example project MessageKit/MessageKit#1294

Merged

maksymmalyhin mentioned this issue Apr 1, 2020

Use GutHub Actions token to run Danger firebase/firebase-ios-sdk#5244

Closed

Kaspik changed the title ~~Danger fails on buddybuild when running on PR from a fork~~ Danger fails on CI when running on PR from a fork Apr 10, 2020

orta changed the title ~~Danger fails on CI when running on PR from a fork~~ Danger fails on CI when running on PR from a fork in GH Actions / Buddy Build Apr 10, 2020

Mkohm mentioned this issue Apr 16, 2020

Integrate with detekt-hint detekt/detekt#2611

Closed

jaymzh mentioned this issue Dec 12, 2023

Move danger runner to dangerjs chef/chef#14134

Merged

11 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Danger fails on CI when running on PR from a fork in GH Actions / Buddy Build #1103

Danger fails on CI when running on PR from a fork in GH Actions / Buddy Build #1103

Goos commented Mar 8, 2019

orta commented Mar 8, 2019

Goos commented Mar 8, 2019

orta commented Mar 8, 2019

Goos commented Mar 8, 2019

orta commented Mar 8, 2019

Goos commented May 7, 2019

JohnRoesler commented Feb 25, 2020

Kaspik commented Mar 20, 2020 •

edited

Kaspik commented Mar 20, 2020

orta commented Mar 20, 2020

Kaspik commented Mar 20, 2020

orta commented Mar 20, 2020

Kaspik commented Mar 23, 2020 •

edited

orta commented Mar 24, 2020

Kaspik commented Mar 24, 2020 •

edited

orta commented Mar 24, 2020 •

edited

Kaspik commented Apr 6, 2020

orta commented Apr 6, 2020

orta commented Apr 6, 2020 •

edited

Kaspik commented Apr 6, 2020 •

edited

orta commented Apr 6, 2020

Kaspik commented Apr 7, 2020

b-onc commented Apr 10, 2020

orta commented Apr 10, 2020

xorima commented Apr 10, 2020

Danger fails on CI when running on PR from a fork in GH Actions / Buddy Build #1103

Danger fails on CI when running on PR from a fork in GH Actions / Buddy Build #1103

Comments

Goos commented Mar 8, 2019

What did you do?

What did you expect to happen?

What happened instead?

Your Environment

orta commented Mar 8, 2019

Goos commented Mar 8, 2019

orta commented Mar 8, 2019

Goos commented Mar 8, 2019

orta commented Mar 8, 2019

Goos commented May 7, 2019

JohnRoesler commented Feb 25, 2020

Kaspik commented Mar 20, 2020 • edited

Kaspik commented Mar 20, 2020

orta commented Mar 20, 2020

Kaspik commented Mar 20, 2020

orta commented Mar 20, 2020

Kaspik commented Mar 23, 2020 • edited

orta commented Mar 24, 2020

Kaspik commented Mar 24, 2020 • edited

orta commented Mar 24, 2020 • edited

Kaspik commented Apr 6, 2020

orta commented Apr 6, 2020

orta commented Apr 6, 2020 • edited

Kaspik commented Apr 6, 2020 • edited

orta commented Apr 6, 2020

Kaspik commented Apr 7, 2020

b-onc commented Apr 10, 2020

orta commented Apr 10, 2020

xorima commented Apr 10, 2020

Kaspik commented Mar 20, 2020 •

edited

Kaspik commented Mar 23, 2020 •

edited

Kaspik commented Mar 24, 2020 •

edited

orta commented Mar 24, 2020 •

edited

orta commented Apr 6, 2020 •

edited

Kaspik commented Apr 6, 2020 •

edited