Azure / Azure/azure-rest-api-specs
[SDK Validation] Improve behavior when TSP package versions diverge across repos
- Dominant language
- TypeSpec
- Stars
- 3.1k
- Forks
- 6k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 444
Description
In this PR, all the "SDK Validation" checks were failing, even though we believe the changes in the PR are valid:
https://github.com/Azure/azure-rest-api-specs-pr/pull/24395/checks?sha=028d4d7cae9471f24a06aea6a1f60bf01f37f567
The checks are failing, because the version of `typespec-client-generator-core` (aka `tcgc`) was newer in the specs repo than the sdk repo, and the TSP sources require the newer version of tcgc.
specs: `typespec-client-generator-core@0.60.0`
* https://github.com/Azure/azure-rest-api-specs-pr/actions/runs/17650306470/job/50159322681?pr=24395#step:3:522
SDK (JS): `typespec-client-generator-core@0.59.1`
* https://github.com/Azure/azure-rest-api-specs-pr/pull/24395/checks?check_run_id=50159783441
* https://dev.azure.com/azure-sdk/internal/_build/results?buildId=5325483&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=00be4b52-4a63-5865-8e02-c61723ad0692&l=237
The mismatched caused a TSP compilation error:
```
04:06:25.453 cmderr [automation_generate.sh] /mnt/vss/_work/1/s/azure-sdk-for-js-pr/sdk/advisor/arm-advisor/TempTypeSpecFiles/Advisor.Management/back-compatible.tsp:7:37 - error invalid-ref: Namespace Azure.ClientGenerator.Core.Legacy doesn't have member flattenProperty
```
https://dev.azure.com/azure-sdk/internal/_build/results?buildId=5325483&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=00be4b52-4a63-5865-8e02-c61723ad0692&l=237
However, it was not immediately clear to either me or the spec author, that this error was caused by the version mismatch.
How could this check be changed to improve this experience?
1. Fail-fast, with a clear error message, if TSP package versions in specs and SDK are not the same?
2. Allow TSP package versions to diverge, but **if** validation fails, ensure all error pages include a clear **warning** that the failure **may** have been caused by mismatched packages, including the specific packages and versions in question.
3. Always use the package versions from the specs repo, instead of the SDK repo? Because, we are running on a PR to the specs repo (not the SDK repo), so it shouldn't matter **in this PR** what package versions are in the SDK repo? That's the problem of the PR to the SDK repo?
CC: @raych1, @mayurid, @timotheeguerin
Contributor guide
Assessment
This issue has not been assessed yet.