Failing CI tests due to Github API limit

[AdaOrbit]

It now happened to me twice that a CI test failed due to Githubs API rate limit.

Both times the tests failed on windows but on different gcc versions. #2051

I'd suggest using a git mirror as not to reach the rate limit (easy but shifting the problem) or better yet, rewriting the tests to be more resourceful (harder but solves the problem).

Another option would be to remove a few CI tests but I don't think that it's a good solution in the long run.

[mosteo]

Is this the self-update test? I suspect that it's a single test the one hitting the limit, so it's not a matter of spreading tests around.

[Seb-MCaw]

My guess is that (if the authentication isn't broken somehow) it is running into one of the secondary rate limits, which reset after a minute, so modifying those two tests to retry after 60secs if the output includes "GitHub API rate limit exceeded" might do it.

[AdaOrbit]

I also have the CI self+toolchain / ubuntu-latest gcc^13 pipeline failing randomly for the (I think?) 5th time now.

It's always the pin__remote-subdir test that creates a corrupted double-linked list glibc error. Rerunning the test solves the issue (sometimes, it's random).

Should that be a new Issue or should I put this in here too?

[mosteo]

It's always the pin__remote-subdir test that creates a corrupted double-linked list glibc error. Rerunning the test solves the issue (sometimes, it's random).

I have never seen this one. Best keep it separate as the issue with API limits is well-defined.

[mosteo]

if the authentication isn't broken somehow

We could XFAIL if there's no token to at least be aware that it's not being used.

The retry looks like a good addition too, rather than having to re-run the entire test suite.