CI is currently broken "You cannot extract a file outside of the target path" #52596
Labels
Comments
eerhardt
added
area-Infrastructure-coreclr
blocking-clean-ci
|
Tagging subscribers to this area: @hoyosjs Issue DetailsI'm seeing this same error on multiple PRs:
|
dotnet-issue-labeler
bot
added
the
untriaged
This was referenced May 11, 2021
|
@dotnet/dnceng could you take a look at this and see if this is part of the AzDo issues we are currently seeing? |
|
Has anyone inspected the ZIP to see if it has malformed entries? Things like a rooted (\foo) or relative (..) archive entry might cause that error. |
|
Also, a quick scan through the hits I saw on runfo - all of them seem to be on Windows. Before most of our corruption at download was seen on Linux/macOS. @ericstj this is at download time, so unlikely. The only validation done at this stage on the artifact is that the file size matches the size in the manifest (this was added in microsoft/azure-pipelines-tasks#14065). I am wondering if the asset manifest is correct here, or if it matches whatever typescript considers to be file size when checking the artifact in https://github.com/microsoft/azure-pipelines-tasks/blob/c9771bc064cd60f47587c68e5c871b7cd13f0f28/Tasks/DownloadBuildArtifactsV0/download_helper.ts#L37. |
|
Thanks for reporting this, I'm taking a look. |
|
@chcosta I just checked this manually. The manifest size and the size reported by powershell on the asset reported in the issue and they do differ quite a bit: 208496577 in manifest vs 207457787 in pwsh. |
|
Seems weird to me that the artifact is a zip that has a folder which contains a zip that has the contents. I'm trying to understand how the runtime repo is packaging these artifacts, but it's taking me a while to sort through the mass of yamls. |
|
You can take a look at |
|
You're right, the zip inside does have the expected size - 208496577. However, the task link for the reported failed download gives me a zip with the wrong size. I wonder if they are checking the size prior to decompression and that's why it fails. |
|
Created ICM ticket - https://portal.microsofticm.com/imp/v3/incidents/details/240668523/home |
|
Azdo has made a rollback of an update, and Juan is monitoring to ensure the issue is resolved. If it's not, we'll jump on another call tomorrow. |
hoyosjs
added
area-Infrastructure
and removed
area-Infrastructure-coreclr
untriaged
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsI'm seeing this same error on multiple PRs: Runfo Tracking Issue: Failure to extract packages
Build Result Summary
|
|
Removing blocking CI. No new instances have been spotted since the rollback happened. |
safern
removed
the
blocking-clean-ci
|
Is it a different issue https://dev.azure.com/dnceng/public/_build/results?buildId=1135727&view=results? Started today at 3:21 PM |
|
@sandreenko yes. Different issue. The other one was a Windows only issue. Taking a quick look. |
|
Have you seen it in multiple PRs? I see they appear to have tried to fix the task and updated it. But I don't see any other instances except one from over a week ago. |
No, I saw it in my PR after I added a commit to it, the neighbor runs did not have this issue. |
|
Closing as resolved. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm seeing this same error on multiple PRs:
https://dev.azure.com/dnceng/public/_build/results?buildId=1132154&view=logs&j=a4640945-bbdc-597c-ef1f-fa8333a2fcba&t=a98154d0-d3a5-5a2b-9381-8130b5ef9cd5&l=44
https://dev.azure.com/dnceng/public/_build/results?buildId=1132211&view=logs&j=f827f174-7a88-54e3-54c2-8dcd28f39edd&t=102b6136-808d-5b02-a12e-313a3079cf99&l=45
Runfo Tracking Issue: Failure to extract packages
Build Result Summary
The text was updated successfully, but these errors were encountered: