[BUG] Bitrise - Could not add a commit status, the GitHub token for Danger does not have access rights.
- Dominant language
- TypeScript
- Stars
- 5.5k
- Forks
- 381
- Avg merge
- 2h 8m
- Merged PRs (30d)
- 6
Description
# Describe the bug
The following is printed even when providing the right GitHub token:
>Found no issues or messages from Danger. Removing any existing messages on GitHub.
>**_Could not add a commit status, the GitHub token for Danger does not have access rights._**
>If the build fails, then danger will use a failing exit code.
>Danger: ✓ passed review, received no feedback.
I know what you're thinking:
- [x] Is the scope right? Yes, I even created a Personal Access Token with global admin permissions (ticking all scope boxes)
- [x] Did you really provide the token? Yes, in fact the bot **is** able to post, in certain scenarios - see below
- [x] Were you able to reproduce this locally or just in CI? Both locally and in CI, both in Danger JS and Danger Swift.
# To Reproduce
This issue is only reproducible in Bitrise CI environment (and locally, replicating CI's env vars), **when Danger's output doesn't have any comments to make.**
## Steps to reproduce the behavior:
### Locally:
1. Set env vars:
- `export DANGER_GITHUB_API_TOKEN=132123312312132312`
- `export BITRISE_IO=true`
- `export BITRISE_PULL_REQUEST=9001`
- `export GIT_REPOSITORY_URL=https://github.com/artsy/eigen`
- NOTE that setting e.g. `DANGER_FAKE_CI` and similar env vars doesn't work, see below.
2. Run `danger ci --id "Danger Static Analysis test" --verbose`
3. Observe the GitHub PR not updating its status check, and danger logging the error message aforementioned.
### In Bitrise:
1. Set `DANGER_GITHUB_API_TOKEN` as either a secret or env var (doesn't matter, but use secret to avoid exposing it)
2. Run `danger ci --id "Danger Static Analysis test" --verbose`
3. Observe the GitHub PR not updating its status check, and danger logging the error message aforementioned.
## Similar steps that DO NOT reproduce the issue (instead, they work as expected!):
- If Danger realizes it **has** comments to post in the PR, it **is** able to post the comment, and it **is** able to update the status check correctly, as expected. 🧐
- If instead of setting the 3 bitrise-specific env vars, I set `DANGER_FAKE_CI`, `DANGER_TEST_REPO` and `DANGER_TEST_PR`, things work as expected, updating the status check correctly. Weird 🤔
- If I clone this repo, set the 3 bitrise env vars as well as github token env var, and run it locally using `yarn build; node --inspect distribution/commands/danger-ci.js --id "Danger Static Analysis test2" --verbose`, it also works as expected. Go figure 🤔
# Expected behavior
At the risk of sounding obvious, if I provide the github api token I expect the bot to be able to update the status check to green when it finds no issues.
# Screenshots
Nothing would help probably, let me know if this is needed.
# Your Environment
| software | version
| ---------------- | -------
| danger.js | 10.6.2
| node | v15.7.0
| npm | 7.4.3
| Operating System | macOS 11.2.1 intel-based machine (CI is in 10.15 though)
# Additional context
We use Danger Swift actually. But since Danger Swift uses JS under the hood, I thought of testing the same scenario in Danger JS and it could be reproduced as well, hence why I'm opening this issue in this repo :)
So just for completeness sake, here's the command we're using in Danger Swift:
`swift run danger-swift ci --id 'Danger Static Analysis test' --dangerfile ./Dangerfile.swift --verbose`
Now, I tried debugging this issue as much as I could, so I went on a code review journey:
- I thought this regex could be flaky/wrong:
https://github.com/danger/danger-js/blob/c4fa1308d969af7acc1b2ae052c1a75fbe26a9c3/source/ci_source/providers/Bitrise.ts#L59-L63
But it's not, I verified using real values (from my CI, and local tests).
- I reviewed all the other values in Bitrise.js and they all look right, except:
- This env var looked wrong: https://github.com/danger/danger-js/pull/1113
- `commitHash()` uses `BITRISE_GIT_COMMIT`, which is documented as:
> The commit hash of the Git commit that triggered the build, when applicable. There is no commit hash, for example, in the case of a pull request build.
So, naturally, since Danger is required to run in a Pull Request build, then the commit will never be available. This sounded like a problem initially, I still don't know if it is, but then if that was the case, Danger would have to fail at all cases when running locally cuz we never provide any commit hash to it 🤷 PS: I still tested this possibility by explicitly setting BITRISE_GIT_COMMIT to the right commit hash and it still won't work.
Contributor guide
Research direction
Start with source/ci_source/providers/Bitrise.ts, especially the regex at lines 59-63, and compare the Bitrise environment values with the related pull request #1113. Reproduce with the listed Bitrise variables and the danger ci command, then verify that a run with no comments updates the GitHub status check successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, typescript
- Domain
- ci-cd
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100