-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Official builds are broken because of OS (RID, ...) property updates #48647
Comments
Tagging subscribers to this area: @ViktorHofer Issue Details
Caused by #48505 (it's the only change in the failing official build). @am11 can you please take a look?
|
This happens when multiple legs produce identical assets (identical based on their PackageId and PackageVersion). The affected packages are:
And the colliding configurations are:
The Linux arm leg produces the following assets: The Linux musl arm leg produces the same assets: Does that help meanwhile?
@dotnet/dnceng for ideas how to validate this scenario in public CI. |
Repeated asset entry is the correct check in the official build. It ensures that the same asset wasn't published twice (for this exact reason), and it's an error. The most common case for this are where two different legs build the same non OS specific asset (e.g. System.IO.Pipelines), ending up with a non-deterministic build Really tough to validate in public CI, since (by design) you have no join point where you would know about artifacts from all the inputs. Maybe you could make a set of validation rules for package names? |
Honestly, I think that based on the number of times this hits (it's very infrequent), not validating it in public PRs is fine. We don't validate the entire test set in a public PR, and we can't validate the entire official build pipeline either. |
Exactly:
From the previous successful official build. Linux arm: Linux arm musl as it should be: What is interesting is that in the good build for
Absolutely, I agree. We need to follow-up on this to make sure that we have protection in place that checks if we have colliding packages in different legs that would later then be uploaded. This has happened numerous times in the past with musl in play... |
Removing blocking-official-build label as the change has been reverted meanwhile. |
I think the failure here was caused by |
@ViktorHofer is this issue still relevant? |
We reverted the change some months ago and the issue can be closed. Thanks for reminding. |
Caused by #48505 (it's the only change in the failing official build).
Official build (internal only): https://dev.azure.com/dnceng/internal/_build/results?buildId=1007559&view=logs&j=5c24930e-0ae1-546c-7353-8c3b261a7651&t=15a0e93a-4b94-56d6-ccae-6c186febb6f4&l=42
@am11 can you please take a look?
The text was updated successfully, but these errors were encountered: