feat(azure-ai-projects): add endpoint evaluator samples for API Key auth and entra id auth

[ahmad-nader]

Add two E2E samples demonstrating endpoint-based evaluators:

• sample_endpoint_evaluator_with_api_key.py: API Key authentication flow
• sample_endpoint_evaluator_with_entra_id.py: Entra ID (managed identity) authentication flow

Both samples show the full workflow: create connection, register evaluator, create evaluation, run with inline data, and poll for results.

Description

Please add an informative description that covers that changes made by the pull request and link all relevant issues.

If an SDK is being regenerated based on a new API spec, a link to the pull request containing these API spec changes should be included above.

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.

[github-actions]

Thank you for your contribution @ahmad-nader! We will review the pull request and get back to you soon.

[Copilot]

Pull request overview

This PR adds two end-to-end sample scripts to azure-ai-projects demonstrating endpoint-based evaluators — one using API Key authentication and one using Entra ID (managed identity). Each sample walks through creating a workspace connection, registering an evaluator, creating an evaluation, running it with inline data, and polling for results. The samples are intended to live alongside the existing evaluation samples under samples/evaluations/.

The main blocking concern is that both samples depend on a model (EndpointBasedEvaluatorDefinition) that does not exist in the package on the PR's base branch (main), so neither sample can import or run as-is. There is also a Black-formatting issue in the API Key sample, and the new samples are not added to the evaluations README.md index (which the repo convention maintains, though that file is outside this PR's diff).

Changes:

• Adds sample_endpoint_evaluator_with_entra_id.py (managed-identity auth flow via a CustomKeys/AAD connection).
• Adds sample_endpoint_evaluator_with_api_key.py (API key auth flow via an ApiKey connection, with an EvaluatorMetric definition).
• Both rely on EndpointBasedEvaluatorDefinition, which is not present in the SDK.

Reviewed changes

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

File	Description
sdk/ai/azure-ai-projects/samples/evaluations/sample_endpoint_evaluator_with_entra_id.py	New Entra ID auth endpoint-evaluator sample; imports nonexistent EndpointBasedEvaluatorDefinition.
sdk/ai/azure-ai-projects/samples/evaluations/sample_endpoint_evaluator_with_api_key.py	New API Key auth endpoint-evaluator sample; imports nonexistent EndpointBasedEvaluatorDefinition and has a mis-indented metrics block that fails Black.

[glharper]

Summary: Adds two well-structured, end-to-end evaluation samples to  sdk/ai/azure-ai-projects/samples/evaluations/ . The API surface usage is correct — I verified  EndpointBasedEvaluatorDefinition ,  EvaluatorVersion ,  EvaluatorMetric ,  EvaluatorCategory ,  EvaluatorType , and the  project_client.beta.evaluators.create_version(name=..., evaluator_version=...)  call all match the actual models/operations. Both files compile, follow the existing sample conventions ( get_openai_client() ,  DataSourceConfigCustom ,  CreateEvalJSONLRunDataSourceParam , polling loop), and contain no hardcoded secrets (all creds come from env vars).

🔴 Blocking —  sample_endpoint_evaluator_with_api_key.py  fails the  black  check

The  metrics=  block (lines ~154–160) has misaligned indentation (one extra leading space, and the inner dict is under-indented). The repo's  black  CI check (line-length 120) will fail.  black  reformats it to:

            definition=EndpointBasedEvaluatorDefinition(
                connection_name=connection_name,
                metrics={
                    "score": EvaluatorMetric(
                        type="ordinal",
                        min_value=1,
                        max_value=5,
                    )
                },
            ),

Fix: run  black -l 120  (or  azpysdk black . ) on the file.  sample_endpoint_evaluator_with_entra_id.py  passes black as-is.

🟡 Minor nits (non-blocking)

1. Env var inconsistency: These samples use  AZURE_AI_PROJECT_ENDPOINT , but the overwhelming convention in this folder is  FOUNDRY_PROJECT_ENDPOINT  (379 vs. a handful). Consider aligning for consistency.
2. Metric vs. docstring mismatch (api_key): The metric is declared  type="ordinal", min_value=1, max_value=5 , but the docstring's example response shows  "score": 0.85  (a continuous 0–1 value). Cosmetic, but slightly confusing.
3. No cleanup / idempotency: Both samples create a connection + evaluator with fixed names and never delete them; re-running may fail if the connection already exists. Existing samples often skip cleanup, so this is optional.
4. Not listed in  samples/evaluations/README.md  (many samples aren't, so low priority).

✅ Good

• Thorough docstrings covering request/response contract, prereqs, and env vars.
• Correct auth wiring:  ApiKey / credentials.key  header vs.  AAD / Audience: api://  bearer flow.
• CHANGELOG omission is fine — this is samples-only.

Recommendation: Approve after the  black  reformat on the API-key sample (required for CI). The env-var naming is worth aligning but optional.

[dargilco]

Please exclude these samples from the test for now, in order to get the build green (see tests\samples).

[dargilco]

Please don't forget to run the formatter tool

black --config ../../../eng/black-pyproject.toml .