[samples] consider stopping management samples publication

[jeremymeng]

Management packages sometimes can have a large number of auto-generated samples but committing them are often not that useful comparing to data-plane packages whose samples are published to learn site. Essentially, we have three copies of files but two of them are not useful. For example, arm-network has 731 sample files under samples-dev/ and arm-network-rest has 631.

The only place where the management samples is consumed is the rest api reference doc page and only JavaScript version is used. For example, https://learn.microsoft.com/en-us/rest/api/compute/virtual-machines/create-or-update?view=rest-compute-2025-04-01&tabs=JavaScript#create-a-custom-image-vm-from-an-unmanaged-generalized-os-image.

We can still keep samples-dev so that validations can be done in sample authoring. We can run the dev-tool command to publish samples as a dry-run. Ideally, we won't commit any of the published samples.

The question is whether the sample collection process is able to checkout our JS repo at a specific tag, publish samples, then collect from the published samples instead.

[qiaozha]

@weidongxu-microsoft I think the sample collection process can check out the JS repo as a specific tag? What kind of information do you need if yes?

[weidongxu-microsoft]

Yes, it can.

Currently it reads the tag on the github release
https://github.com/Azure/azure-sdk-for-js/releases/tag/%40azure%2Farm-elastic_2.0.0

If you need it read from some other tag, you would need to give me a protocol to get the tag (e.g. write it to a metadata file in sdk folder).

[kazrael2119]

@jeremymeng when will this be supported?

[jeremymeng]

@kazrael2119 This is nice to have. There's no timeline.

@weidongxu-microsoft We can probably start with updating the sample collection to publish samples first before collecting? Then we can try removing TypeScript and JavaScript copies for Mgmt packages from our js-repo.

[weidongxu-microsoft]

@jeremymeng

On "publish samples first before collecting", I assume you mean that the repo on that tag will not contains the samples. The "sample collection procedure" will call some tool on the repo (it probably still be the tag of GitHub release) to generate the samples, then collect them?

We should be good on this. Though unsure whether I have the correct understanding of the intention.

[jeremymeng]

@weidongxu-microsoft the idea is that, if possible, we would like to avoid committing hundreds of files to this repo.

On "publish samples first before collecting", I assume you mean that the repo on that tag will not contains the samples. The "sample collection procedure" will call some tool on the repo (it probably still be the tag of GitHub release) to generate the samples, then collect them?

For example, let's say this folder wouldn't exist anymore in the repo: https://github.com/Azure/azure-sdk-for-js/tree/main/sdk/advisor/arm-advisor/samples/v3. Whatever tools that need files from https://github.com/Azure/azure-sdk-for-js/tree/main/sdk/advisor/arm-advisor/samples/v3/javascript/ would need to clone the repo, run pnpm install, go to the sdk/advisor/arm-advisor/ directory, then run npx dev-tool samples publish. The samples would be published to sdk/advisor/arm-advisor/samples/ in the local clone.

[weidongxu-microsoft]

@jeremymeng

Got it. I think this is what I was assume about the "publish samples first before collecting". I am fine to run it on the checked-out repo.

The only concern is that the run of it (pnpm install and npx dev-tool samples publish) would take some time (minutes?). If say we would have 5 or 10 on the daily released lib, that should be OK.

On the collection part, we can adapt and see.

Do let me know when this switch would happen.

[qiaozha]

add @deyaaeldeen and @MaryGao to provide more context about the sample publish.