Skip to content
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

[Main] Publish Artifacts step failed after rerun #4829

Closed
Winniexu01 opened this issue Jan 16, 2025 · 5 comments · Fixed by dotnet/sdk#46064
Closed

[Main] Publish Artifacts step failed after rerun #4829

Winniexu01 opened this issue Jan 16, 2025 · 5 comments · Fixed by dotnet/sdk#46064
Assignees
Labels
area-build Improvements in source-build's own build process ops-monitor Issues created/handled by the source build monitor role

Comments

@Winniexu01
Copy link
Member

Related to #4537 and dotnet/sdk@e5a8c45, it seems that @ViktorHofer added the condition succeededOrFailed() to the publish artifacts step and it does not support overwriting artifacts.

Failing build (internal Microsoft link):

##[error]Artifact CentOSStream9_Mono_Offline_CurrentSourceBuiltSdk_x64_Artifacts already exists for build 2620900.

Does below solution make sense to you @MichaelSimons @ellahathaway @ViktorHofer ?

  • Add another Publish Artifacts step that only publish on success, and modify the current Publish Artifacts step to include $(System.JobAttempt) that only publish on fail. This will not affect the other pipelines download these artifacts.
@Winniexu01 Winniexu01 added the ops-monitor Issues created/handled by the source build monitor role label Jan 16, 2025
@Winniexu01 Winniexu01 changed the title Publish Artifacts step failed after retry [Main] Publish Artifacts step failed after retry Jan 16, 2025
@Winniexu01 Winniexu01 changed the title [Main] Publish Artifacts step failed after retry [Main] Publish Artifacts step failed after rerun Jan 16, 2025
@ViktorHofer
Copy link
Member

Yes, I had to add the condition back as it was impossible to debug CI issues without artifacts getting uploaded.

@MichaelSimons
Copy link
Member

What about appending _Attempt$(System.JobAttempt) to the artifact name? That would make the artifacts unique per run/retry.

@ViktorHofer
Copy link
Member

@ellahathaway touched on this in the original issue:

Modify the Publish Artifacts step to include the Job Attempt number. This would mean each run would have it's artifacts uploaded to a distinct artifact name. The downside to this, is there are some dependent jobs (e.g. the source-build sdk content tests) which download the artifacts. They would need to account for the possibility of multiple artifacts existing.

@mthalman
Copy link
Member

mthalman commented Jan 16, 2025

I've chatted with AzDO folks on this scenario in the past. Their recommended pattern is to use the _Attempt$(System.JobAttempt) naming for the intermediate publishing step. And then have a final step at the end which publishes the same files to a statically name artifact. You're essentially publishing the files twice but they have de-dupe logic that prevents it from doubling the storage size. This way you get the benefits of early access to the artifacts in case of failure but also a known artifact name on a successful build.

@mthalman
Copy link
Member

One caveat is that this recommendation was given before all the 1ES-injected tasks like SBOM generation. So I don't know what impact that will have on things as there is a fair amount of overhead in publishing any artifacts at all.

@MichaelSimons MichaelSimons added the area-build Improvements in source-build's own build process label Jan 16, 2025
@MichaelSimons MichaelSimons moved this from Backlog to 10.0 Preview 1 in .NET Source Build Jan 16, 2025
@ellahathaway ellahathaway moved this from 10.0 Preview 1 to In Progress in .NET Source Build Jan 16, 2025
@github-project-automation github-project-automation bot moved this from In Progress to Done in .NET Source Build Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-build Improvements in source-build's own build process ops-monitor Issues created/handled by the source build monitor role
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

5 participants