-
Notifications
You must be signed in to change notification settings - Fork 175
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
Investigate new ci-artifacts
flakiness
#81
Comments
For the record, today the |
The latest three runs worked without any need for re-runs. May have been an overzealous Defender... I'll give it another week, and if there are no other instances of this flake, I'll close this ticket. |
The problem is back. |
The error happened today, too. Here are the latest |
After 7 consecutive successful runs, it happened again. |
After 8 consecutive successful runs, it happened again. |
After only one successful run, there was another failing one. |
As of https://github.com/git-for-windows/git-sdk-64/actions/runs/7895871817/job/21548925651, it seems that there is a flaky problem. The symptom looks like this:
This problem usually goes away after re-running a couple of times (once I had to re-run 3 times to make it succeed).
The lucky thing is that the
strip
Makefile rule is apparently not used ingit/git
's own CI, therefore things don't fail there (which would be disastrous). So we do not need to drop everything and fix this Right Now, but it needs to be fixed.Now, the commit corresponding to the first build that exhibited the problem is 863c871. Contrary to what I first thought, that commit did not update the MSYS2 runtime. That update came in the next commit.
Comparing the first failing job with the corresponding job of the previous build, I see in the
Set up job
step that the runner version changed, from v2.312.0 to v2.313.0. But I don't see any obvious culprit in that version's release notes.Also in the
Set up job
step, I see a difference in the runner image (but not in the Windows version), but the corresponding diff also does not shed any light into the issue.It is possible, of course, that the previous build succeeded on first attempt due to flakiness rather than by virtue of being non-flaky. More investigation is needed here.
The text was updated successfully, but these errors were encountered: