Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use danger standalone? (danger triggers github rate limit exceeding) #989

Open
divramod opened this issue Feb 11, 2020 · 3 comments
Open

Comments

@divramod
Copy link

Hey,

i am running danger standalone in a kubernets pod-container.
The command i use to run danger looks like that:

export DANGER_GITHUB_API_TOKEN=${GIT_TOKEN} 
danger pr https://github.com/${GIT_OWNER}/${GIT_REPO}/pull/${GIT_PULL_REQUEST}

This is running fine and gives the expected results.
My problem is, that our repo seems to be really large and while running that process danger makes about 1900 calls to the github api, which lets us run into the rate limit really fast.

Now i wanted to ask, if i can somehow avoid that?
I am not really sure where to start here to avoid the github api calls.

thx in advance!

@orta
Copy link
Member

orta commented Feb 11, 2020

This sounds like the code in the dangerfile is doing some overly intense work - honestly, I'd start there - is it accidentally reading every file in the repo somehow?

@divramod
Copy link
Author

hey @orta, thx for the reply.

yeah, the dangerfile seems to do a lot of comparing-work.
but it seems, it should be that way.

can you think of another solution for tackling this problem.

i could think of downloading the branch/commit which danger compares to and do the heavy work locally?

is there a option going into this direction?

i am open to every solution which avoids penetrating the github api.

@orta
Copy link
Member

orta commented Feb 17, 2020

Try wrap up #991 which verifies that you're running on the right commit, and uses the fs instead of the GitHub API for read access to files - that only works if you're running danger on CI, but that's at the 90% use case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants