This repository was archived by the owner on Aug 21, 2019. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I thought the graceful back-down times code was really clever - to double the time to poll for the challenge. I'm definitely going to use the method in other places.
Unfortunately, it doesn't quite 'click' here - to double it and retry 9 times, making 10 attempts in total, means that the biggest gap you can have is the last one - 256 minutes waiting. If all fail, then you've spent 511.5 minutes waiting, around 8.5 hours. On GitLab.com's free tier, that's over 1/4 of the allocated minutes you have per month, meaning that if the process fails 4 times, you've already destroyed all your allowed build time for the next month, for all of your projects, not just this one.
Further, there are reports online that the nonces might even expire after around 10 minutes (although I haven't looked into this nor am I an expert). Which means even after 8 hours of build time, if the challenge finally uploaded, it wouldn't even work.
One thing we do know is that polling is cheap - it's just a basic http request so we don't need to worry about doing it too much.
This pull request addresses the above issues by doing the polling every 30s for 15 minutes, and then stopping. 15 minutes was chosen because it was a little more than the reported 10 minute expiry of the nonce, and I feel that if a site has longer than a 15 minute build time, there is probably a whole lot more going on there that they probably aren't hosting it on GitLab's free pages, but writing their own methods in-house.