fixes for integration test rate limit issues #8538
Conversation
we don't need to run these on PR close or when we apply labels, for example
chris48s
changed the title
|
@calebcartwright - if you get a chance, it would be really useful to get a 👍 on this one before the dependabot PRs come in for the week. In the current configuration we can only merge about 2 or 3 PRs per hour, so merging this one would be super high impact. |
|
Actually have a question on f0ad7b6 relative to disabling the trigger for pushes to dependabot branches (assuming IUC). What's the potential impact of this in cases where we need dependabot to rebase/recreate, as those involve force pushing to the branch associated with the already created PR, and then the more rare cases where we have to manually push some commits to a dependabot branch ourselves? |
|
As I understand it, a dependabot rebase or recreate should trigger the unhelpfully named
but it is possible this might need another round of tweaks. If we find there are some pull request events which are not triggering a rebuild, we could try inverting the logic: disable workflows for pull requests where the base branch is |
closes #8535
Right. A few things going on here:
First 2 commits should be pretty clear. Just trying to run fewer pointless builds really. Regardless of if the builds are consuming rate limit or not, this is good. Less noise, faster builds, etc
The crucial commit is actually the third one though. What I've done is set a Personal Access Token as both a repo secret and a dependabot secret. Then in the build, we use the PAT if it is available, or fall back to the standard action token (which has the lower rate limit of 1000/hour) otherwise. This will mean PRs submitted from forks can use the standard token without us having to expose a PAT while pushes to master, dependabot PRs, etc can use the PAT with the higher rate limit. That should stop dependabot/repo ranger from completely smashing our rate limit.