Fix deployment-id attribution for az webapp deploy (OneDeploy)

[Saipriya-1144]

Related command
az webapp deploy

Description

The runtime-status tracker now identifies its own deployment using the  SCM-DEPLOYMENT-ID  header returned by the publish ( /api/publish ) response, instead of polling the global  /api/deployments/latest  pointer.

The build server normally serializes deployments and rejects a concurrent one with "Another deployment is in progress" — but if two requests arrive before the first acquires its lock, both slip through and run together. In that race, the CLI's old /api/deployments/latest lookup made both runs report the same deployment id. Capturing each publish response's request-specific  SCM-DEPLOYMENT-ID  fixes this, so every invocation reports the deployment its own POST created.

Testing Guide
Before the Change:

Both deployments when triggered around the same time returned same deployment ID

But the actual deployment IDs are different

After the Change:

Tests:
Added  TestDeploymentIdSelection  in  test_deployment_context_engine.py  (offline, mocked):

• uses the request-specific id when present (skips  /latest )
• falls back to  /latest  when the header is absent

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR title and description has followed the guideline in Submitting Pull Requests.

• I adhere to the Command Guidelines.

• I adhere to the Error Handling Guidelines.

[azure-client-tools-bot-prd]

Validation for Azure CLI Full Test Starting...

Thanks for your contribution!

[azure-client-tools-bot-prd]

Hi @Saipriya-1144,
Since the current milestone time is less than 7 days, this pr will be reviewed in the next milestone.

[azure-client-tools-bot-prd]

Validation for Breaking Change Starting...

Thanks for your contribution!

[Copilot]

Pull request overview

This PR fixes deployment-id attribution for az webapp deploy (OneDeploy) runtime-status tracking by preferring the request-specific SCM-DEPLOYMENT-ID header returned from the publish (/api/publish) response, instead of relying on the racy global /api/deployments/latest pointer. This improves correctness when concurrent deployments slip through Kudu’s serialization lock and would otherwise cause multiple CLI invocations to report the same deployment ID.

Changes:

• Capture and store the request-specific deployment id (SCM-DEPLOYMENT-ID) on the per-invocation OneDeployParams object.
• Update runtime-status tracking to use the stored deployment id when available, falling back to /latest only when absent.
• Add offline unit tests to validate both the preferred-path and fallback behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/azure-cli/azure/cli/command_modules/appservice/custom.py	Stores SCM-DEPLOYMENT-ID from the OneDeploy response and uses it for deploymentstatus tracking with a fallback to /latest.
src/azure-cli/azure/cli/command_modules/appservice/tests/latest/test_deployment_context_engine.py	Adds mocked unit tests ensuring request-specific deployment id selection and fallback behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yonzhan]

webapp