-
Notifications
You must be signed in to change notification settings - Fork 4k
Compute's migration to TypeSpec for API definitions + DiskRP 2025-01-02 #28168
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
Conversation
Thanks for your contribution! The pull request validation has started. Please revisit this comment for updated status. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR removes legacy customizations for VM operations and various model partial classes as part of migrating API definitions to TypeSpec, and adjusts the base type for disk restore points.
- Deletes manual extension and operation implementations for
VirtualMachinesOperations
- Removes numerous custom model partials in favor of generated definitions
- Changes
DiskRestorePoint
to inherit fromProxyResource
and minor project file encoding update
Reviewed Changes
Copilot reviewed 13 out of 409 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
VirtualMachinesOperationsExtensions.cs | Removed hand-written extension methods for VM operations |
VirtualMachinesOperations.cs | Deleted custom operation implementations |
VirtualMachineScaleSetVMExtension*.cs | Removed custom constructors and updated parameter names |
VirtualMachineScaleSetExtensionUpdate.cs | Deleted custom partial class |
VirtualMachineCaptureResult.cs | Deleted custom constructor |
SubResourceWithColocationStatus.cs | Deleted custom partial class |
NetworkInterfaceReference.cs | Deleted custom partial class |
IVirtualMachinesOperations.cs | Deleted interface definitions for VM operations |
DiskRestorePoint.cs | Changed base class from ProxyOnlyResource to ProxyResource |
DiskEncryptionSetParameters.cs | Deleted custom partial class |
CloudServiceNetworkProfile.cs | Deleted custom model code |
Compute.Management.Sdk.csproj | Removed file-level BOM |
Comments suppressed due to low confidence (1)
src/Compute/Compute.Management.Sdk/Customizations/DiskRestorePoint.cs:6
- [nitpick] Changing the base class from
ProxyOnlyResource
toProxyResource
can be breaking for callers relying on the previous type. Document this as a breaking change in the release notes and verify downstream compatibility.
public partial class DiskRestorePoint : ProxyResource
src/Compute/Compute.Management.Sdk/Customizations/VirtualMachineScaleSetVMExtension.cs
Outdated
Show resolved
Hide resolved
@@ -1,4 +1,4 @@ | |||
<Project Sdk="Microsoft.NET.Sdk"> | |||
<Project Sdk="Microsoft.NET.Sdk"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file starts with a BOM character, which may lead to encoding issues in some build environments. Consider removing the BOM for consistent parsing across tools.
<Project Sdk="Microsoft.NET.Sdk"> | |
<Project Sdk="Microsoft.NET.Sdk"> |
Copilot uses AI. Check for mistakes.
…neScaleSetVMExtension.cs Co-authored-by: Copilot <[email protected]>
moved back to #27827 |
Description
Migrated from #27827 as requested by @YanaXu
this PR reflects, two major updates:
after TypeSpec migration, there were many directives that needed to be added and
it kept running into "maximum calls reached" (stack overflow).
I had a meeting with several track 1 SMEs, and they said it is a known autorest 2 issue and will not be addressed. But Compute still has track 1 dependency so the best solution I found, and they suggested the same thing, is to keep the swagger json within the PS repo and do in place file manipulation with file I added: preprocess-rest-api-spec.ps1 To avoid some of the directives
Mandatory Checklist
Please choose the target release of Azure PowerShell. (⚠️ Target release is a different concept from API readiness. Please click below links for details.)
Check this box to confirm: I have read the Submitting Changes section of
CONTRIBUTING.md
and reviewed the following information:ChangeLog.md
file(s) appropriatelysrc/{{SERVICE}}/{{SERVICE}}/ChangeLog.md
.## Upcoming Release
header in the past tense.ChangeLog.md
if no new release is required, such as fixing test case only.