The Test Results workflow (test-results.yml) failed on run 30100440814 with:
FileNotFoundError: [Errno 2] No such file or directory: 'artifacts/Event File/event.json'
Root cause:
The triggering "Build, Test, and Pack" run (30094840174) had run_attempt: 2 — it was re-run after a failure. On attempt 1, the "Build Windows installers" job uploaded chorus-hub-installer and chorus-merge-module artifacts, then failed at the dotnet pack step:
IOException: The process cannot access the file '...\_runner_file_commands\set_env_...'
because it is being used by another process.
This is a known flaky race in GitVersion.MsBuild, where parallel project builds in the same job write build-agent output to the same runner env file. It's unrelated to any code change.
Someone re-ran the failed jobs (attempt 2). "Build Windows installers" ran again from scratch and re-uploaded artifacts with the same names, succeeding this time. GitHub Actions does not clear artifacts from earlier attempts when only failed jobs are re-run, so both attempts' chorus-hub-installer and chorus-merge-module artifacts ended up coexisting under the same run ID — the Artifacts API returns all of them, duplicated.
The Test Results workflow's download step (test-results.yml:30-35) isn't prepared for that:
gh api "$artifacts_url" -q '...' | while read artifact
do
IFS=$'\t' read name url <<< "$artifact"
gh api $url > "$name.zip"
unzip -d "$name" "$name.zip"
done
unzip has no -o/-n flag. On the second chorus-hub-installer archive it prompted interactively (replace file? [y/n/A/N/r]) on stdin — which is still the piped gh api output feeding the while read loop. The prompt consumed the next artifact's tsv line as its answer, then consumed the line after that as a "new name," desyncing the loop entirely. The remaining artifacts, including Event File (containing event.json), were never downloaded, so the "Publish Test Results" step failed looking for it.
Suggested fix:
Harden the download step, since re-running failed jobs is a normal occurrence and will produce this same duplication again:
- Add
unzip -o to force overwrite, and redirect its stdin away from the loop (</dev/null) so a prompt can never consume pipe data.
- Consider replacing the manual
gh api + unzip loop with gh run download, which handles per-artifact directories and name collisions natively.
Separately, the GitVersion.MsBuild file-lock race in "Build Windows installers" is worth its own investigation (#391) — it's the reason the job needed a re-run at all, and will keep causing spurious failures independent of this issue.
Drafted by Claude Sonnet 5 (claude-sonnet-5).
The
Test Resultsworkflow (test-results.yml) failed on run 30100440814 with:Root cause:
The triggering "Build, Test, and Pack" run (30094840174) had
run_attempt: 2— it was re-run after a failure. On attempt 1, the "Build Windows installers" job uploadedchorus-hub-installerandchorus-merge-moduleartifacts, then failed at thedotnet packstep:This is a known flaky race in GitVersion.MsBuild, where parallel project builds in the same job write build-agent output to the same runner env file. It's unrelated to any code change.
Someone re-ran the failed jobs (attempt 2). "Build Windows installers" ran again from scratch and re-uploaded artifacts with the same names, succeeding this time. GitHub Actions does not clear artifacts from earlier attempts when only failed jobs are re-run, so both attempts'
chorus-hub-installerandchorus-merge-moduleartifacts ended up coexisting under the same run ID — the Artifacts API returns all of them, duplicated.The
Test Resultsworkflow's download step (test-results.yml:30-35) isn't prepared for that:unziphas no-o/-nflag. On the secondchorus-hub-installerarchive it prompted interactively (replace file? [y/n/A/N/r]) on stdin — which is still the pipedgh apioutput feeding thewhile readloop. The prompt consumed the next artifact's tsv line as its answer, then consumed the line after that as a "new name," desyncing the loop entirely. The remaining artifacts, includingEvent File(containingevent.json), were never downloaded, so the "Publish Test Results" step failed looking for it.Suggested fix:
Harden the download step, since re-running failed jobs is a normal occurrence and will produce this same duplication again:
unzip -oto force overwrite, and redirect its stdin away from the loop (</dev/null) so a prompt can never consume pipe data.gh api+unziploop withgh run download, which handles per-artifact directories and name collisions natively.Separately, the GitVersion.MsBuild file-lock race in "Build Windows installers" is worth its own investigation (#391) — it's the reason the job needed a re-run at all, and will keep causing spurious failures independent of this issue.
Drafted by Claude Sonnet 5 (claude-sonnet-5).