Add cleanroom SDK CLI samples and SDK walkthrough doc#98
Conversation
|
@ShreyaSangwa please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
| # Run this block in every terminal that will call the SDK CLIs. | ||
| # If your terminal starts in C:\Users\...\Downloads\sample, move into the repo first. | ||
|
|
||
| dotnet restore .\packages\mgmt-sample\CleanRoomMgmtSample.csproj |
There was a problem hiding this comment.
Can we create a new csproject for samples, and use the sdk generated from above inside the .cs file for testing?
| @@ -0,0 +1,8 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <configuration> | |||
There was a problem hiding this comment.
What needs to be added if the goal is “create packages for two folders”
If by “create packages” you mean the repo should generate those .nupkg files instead of checking them in manually, then you need a packaging step for each SDK source project.
- Add packable SDK project(s)
You need the actual SDK source projects somewhere, for example:
sdk/management/Azure.ResourceManager.CleanRoom/Azure.ResourceManager.CleanRoom.csproj
sdk/frontend/Azure.Cleanroom.Analytics.Frontend.Client/Azure.Cleanroom.Analytics.Frontend.Client.csproj
Those projects must include package metadata and be packable, e.g.:
sdk/management/Azure.ResourceManager.CleanRoom/Azure.ResourceManager.CleanRoom.csproj
net8.0
false
true
Azure.ResourceManager.CleanRoom
and similarly for frontend:
sdk/frontend/Azure.Cleanroom.Analytics.Frontend.Client/Azure.Cleanroom.Analytics.Frontend.Client.csproj
net8.0
true
Azure.Cleanroom.Analytics.Frontend.Client
1.0.0-beta.1
2. Add a pack command for both projects
You need a build script or workflow that runs something like:
pack-sdks.sh
dotnet pack sdk/management/Azure.ResourceManager.CleanRoom/Azure.ResourceManager.CleanRoom.csproj -c Release -o ./packages
dotnet pack sdk/frontend/Azure.Cleanroom.Analytics.Frontend.Client/Azure.Cleanroom.Analytics.Frontend.Client.csproj -c Release -o ./packages
That is the missing “create packages for two folders” step.
- Ensure sample projects restore from that output folder
This part is already mostly done.
Repo root NuGet.Config points to:
NuGet.Config
Per-sample NuGet.config points to:
packages/mgmt-sample/NuGet.config
v2
and same for packages/sample/NuGet.config.
That means each sample looks one directory up, i.e. packages/, where the .nupkg files live.
| dotnet restore .\packages\sample\AnalyticsFrontendSample.csproj | ||
|
|
||
| # Verify | ||
| dotnet run --project .\packages\mgmt-sample\CleanRoomMgmtSample.csproj -- --help |
There was a problem hiding this comment.
This looks directionally right for consuming local SDK packages, but I think we’re still missing the package-production side of the flow.
The expectation for this change was to support two separately generated NuGet packages — one for the management SDK and one for the frontend SDK — and then use those packages from the sample Program.cs apps. Right now the PR adds the sample consumers and local NuGet.config files, but it appears to rely on checked-in .nupkg artifacts rather than defining how those packages are actually produced.
A few things I think we should add/clarify:
Source-of-truth for package generation
Where are the SDK source projects that produce:
Azure.ResourceManager.CleanRoom
Azure.Cleanroom.Analytics.Frontend.Client
We should have a documented or scripted dotnet pack flow for both.
Package output location
The two sample projects should remain normal PackageReference consumers of those package IDs/versions.
NuGet.config should point to the generated package feed location.
Docs/build instructions
We should document the expected sequence explicitly:
build/pack management SDK
build/pack frontend SDK
restore/build mgmt-sample
restore/build sample
Ignore rules
Suggested direction:
add a script/workflow that runs dotnet pack for both SDK projects
output packages to a dedicated local feed folder
update NuGet.config to consume from that folder
avoid relying on committed .nupkg binaries as the long-term model
If you want, I can also rewrite this into a shorter, more direct review comment for inline PR use
Purpose
Adds SDK-based command-line samples for both management plane and frontend dataplane flows, and introduces a full SDK walkthrough document that replaces the managedcleanroom CLI dependency for this path.
Does this introduce a breaking change?
Pull Request Type
What kind of change does this Pull Request introduce?
Summary of All Changes
How to Test
Expected Result
Verify that the following are valid