-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Update Az.PipelineGroup to API version 2024-10-01-preview #27149
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. |
|
@JingchuanHuangMSFT Please follow our migration guide to develop autorest based module: start new development and have prior experience |
|
This PR was labeled "needs-revision" because it has unresolved review comments or CI failures. |
|
Hi @JingchuanHuangMSFT, if you are planning this change for the next release, it still needs to be revised according to this doc: New Guide |
|
Thanks @notyashhh , I'm checking that and will start doing the necessary work this week. |
|
@notyashhh I followed the guide to add the required files, could you review if the latest revision is okay? |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
The build failure was caused by removal of a previously automatically generated property, breaking backwards compatibility static analysis check. I pushed a commit to add those properties back manually. Reproduced this problem locally and confirmed fix: artifacts\StaticAnalysis\StaticAnalysis.Netcore.exe -p artifacts\Debug -r artifacts\StaticAnalysisResults --analyzers breaking-change --modules-to-analyze Az.Monitor |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
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.
I see the src/Monitor is updated to latest api version but not the Autorest part of the module. Can you confirm that this won't cause any breaking between any real-world scenarios?
Ignore this comment, I misunderstood the change.
I think I only intended to update |
|
Why is this PR marked as "public preview"? We are aiming for Az13.4.0 release correct? |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
The service and API version themselves are still in public preview state, so I think choosing public preview for powershell module is more appropriate. Do you think it's better to select general release here? |
|
@JingchuanHuangMSFT, Yes, this is classified as a general release even if the api version is in public-preview, Our "public-preview" option is only used for modules that maintain a series of Az module preview versions. And since this will go in general release, it will be released as 1 minor version upgrade. 😄 |
Got it, I've updated the PR description. |
|
@notyashhh Are there any remaining required actions for me to get this PR merged? Thanks. |
notyashhh
left a comment
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.
Otherwise looks great!
|
Updated. |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
notyashhh
left a comment
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.
Looks Good!
Description
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.mdand reviewed the following information:ChangeLog.mdfile(s) appropriatelysrc/{{SERVICE}}/{{SERVICE}}/ChangeLog.md.## Upcoming Releaseheader in the past tense.ChangeLog.mdif no new release is required, such as fixing test case only.