-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Containers] Fix parsing and error reporting of ports that lack port type metadata #43551
[Containers] Fix parsing and error reporting of ports that lack port type metadata #43551
Conversation
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Sanity check - @marcpopMSFT this was targeting 9.0.100 because it's a bug in validation and is hard for users to understand. Guessing we need Tactics approval at this point? |
Closing as @surayya-MS got this merged in already in teh 8.0.4xx prerequisite PR she got merged! |
wrong PR - this one got approved by servicing. |
/backport to main |
/backport to release/8.0.4xx |
Started backporting to main: https://github.com/dotnet/sdk/actions/runs/11205328409 |
Started backporting to release/8.0.4xx: https://github.com/dotnet/sdk/actions/runs/11205329248 |
Description
Users that attempted to use the SDK to declare open ports in their containers had a very difficult time using the documented pathways due to bugs in the validation and error reporting. The reported error didn't match the user's actual data problem, and the suggested fix wouldn't resolve the users' problem.
Customer Impact
Customers could workaround the issue by fully-specifying the Port to declare, but this was hard to discover and the docs, errors, and user expectations for MSBuild didn't guide users to success.
Regression
No, this has been a problem since the first version of the feature
Risk
Low - we have very broad test coverage, and in fact had codified bad behavior in the tests. Making the tests reflect the actual desired user experience verified the error and the fix very easily.
Technical details
Fixes dotnet/sdk-container-builds#596
There were two problems:
Enum.HasFlag
will always return true for the zero value. this is documented and understandable behavior (since HasFlag is shorthand for(value & target) == target
, and anything AND-ed with 0 will be 0.