[azure-ai-ml] Populate DeploymentTemplate.creation_context from systemData

[swarupecenits]

Notes

• Fixes internal bug #5402673: DeploymentTemplate.creation_context was always None when a template was retrieved via get() or list().
• Root cause: DeploymentTemplate._from_rest_object did not deserialize the service's systemData, so the created/modified timestamps and identities were never populated — inconsistent with Model and Environment, which already populate creation_context.
• Fix: read system_data (object) / systemData (raw dict) from the REST object and pass creation_context=SystemData._from_rest_object(...) into the entity. This covers both get() and list() and mirrors the existing Model / Environment pattern.

Testing

• Added test_deployment_template_from_rest_object_populates_creation_context — asserts the timestamps/identities are populated from systemData.
• Added test_deployment_template_from_rest_object_creation_context_none_when_absent — asserts creation_context stays None when systemData is absent.
• Full test_deployment_template.py: 23 passed. black formatting clean.

Description

Fixes internal bug #5402673. DeploymentTemplate.creation_context now surfaces the created/modified metadata (created_at, created_by, last_modified_at, last_modified_by) that the service returns in systemData, making it consistent with Model and Environment. Previously it was always None even though the data was present in the REST response (a deserialization gap in the SDK entity, not missing service data).

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

Root cause

DeploymentTemplate._from_rest_object never deserialized the REST object's system_data,
so creation_context fell back to its default of None. The data is present in the
response (surfaced via the REST properties / systemData), so this was a deserialization
gap in the SDK entity, not missing service data.

Repro Bug (repro_bug.py)

Fix

• Import SystemData in deployment_template.py.
• In _from_rest_object, read system_data (object) / systemData (raw dict) from the
  REST object and pass creation_context=SystemData._from_rest_object(...) into the entity.
  This covers both get() and list().

This mirrors how Model and Environment already populate creation_context.

Tests

• Added test_deployment_template_from_rest_object_populates_creation_context (asserts the
  timestamps/identities are populated).
• Added test_deployment_template_from_rest_object_creation_context_none_when_absent
  (asserts it stays None when systemData is absent).
• Full test_deployment_template.py: 23 passed. black formatting clean.

Related

• Fixes internal bug #5402673.

[swarupecenits]

@microsoft-github-policy-service agree company="Microsoft"

[Copilot]

Pull request overview

This PR fixes a deserialization gap in the azure-ai-ml package where DeploymentTemplate.creation_context was always None after retrieval via get() or list(), even though the service returns created/modified timestamps and identities in systemData. The fix makes DeploymentTemplate consistent with the Model and Environment entities, which already populate creation_context.

I verified that:

• SystemData is imported from the correct module (azure.ai.ml.entities._system_data), and SystemData._from_rest_object reads fields via getattr, so it works with the real REST model.
• The REST DeploymentTemplate model exposes system_data as a top-level rest_field(name="systemData"), so reading it from the top-level object (not properties) is correct, and the system_data/systemData dual-key lookup covers both object and raw-dict payloads.
• DeploymentTemplate.__init__ accepts creation_context via **kwargs and forwards it to the parent Resource, so the new argument is valid.
• The pattern (SystemData._from_rest_object(...) if ... else None) matches ~20 existing call sites across the package.
• The two new tests use the same Mock(spec=[]) approach already used by neighboring tests, and their assertions are logically sound (including the absent-systemData → None case).

Changes:

• In _from_rest_object, read systemData from the REST object and populate creation_context via SystemData._from_rest_object, covering both get() and list().
• Added two regression unit tests (populated and absent systemData cases).
• Added a CHANGELOG entry under the unreleased 1.35.0 "Bugs Fixed" section.

Reviewed changes

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

File	Description
azure/ai/ml/entities/_deployment/deployment_template.py	Imports SystemData and deserializes system_data/systemData into creation_context in _from_rest_object.
tests/deployment_template/unittests/test_deployment_template.py	Adds tests asserting creation_context is populated from systemData and stays None when absent.
CHANGELOG.md	Documents the bug fix under 1.35.0 (unreleased) → "Bugs Fixed".