danger: PR commit race condition

Report

What did you do?

Run bundle exec danger --dangerfile=PreBuild.dangerfile --danger_id=prebuild Run build scripts Run bundle exec danger --dangerfile=PostBuild.dangerfile --danger_id=postbuild

What did you expect to happen?

Run Danger twice, one before builds scripts and one after, without problems.

What happened instead?

The second danger crashed.

fatal: Not a valid branch point: '<hash>'.
fatal: ambiguous argument 'danger_head': unknown revision or path not in the working tree.

The <hash> in the error message points to a commit that was sent to the PR branch after the build started and as such doesn’t exist in the current build git repo when danger runs.

The following build (that’s executed on the <hash> commit) will succeed without problem.

Your Environment

GitHub
Jenkins 2.7.2
Danger 3.3.2

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 16 (16 by maintainers)

Most upvoted comments

So now I’m wondering; why does danger need the latest commit instead of just using the current commit?

This is a complex problem with keeping github metadata and user metadata state in order, in the end we opted to just always rely on github metadata here - as we can have some guarantees there across all CI implmentations

orta on Oct 3, 2016