ci: add service-free Python smoke workflow

[yousseffaouzi]

Related to #632.

Summary

This is a focused first version of PR-focused Python smoke checks, following the maintainer direction to “Try one.”

The workflow is intentionally narrow and service-free:

• runs only for pull requests touching Python/source or dependency/workflow inputs
• uses explicit contents: read permissions
• reuses actions/checkout@v7 with persisted credentials disabled
• installs pinned uv from the official Astral installer
• verifies the dependency lock with uv lock --check
• exports frozen lock constraints and installs only the direct dependencies needed by the selected smoke tests
• runs src/llm/tests and src/servers/utilities/tests
• uses a 10-minute timeout and cancels superseded runs for the same PR

Validation

Validated from fork commit cd7b97da1affed26a1694708d59df23141eaebc0.

Fork GitHub Actions run 38656000694 (Python Smoke) completed successfully, including the lock check, constrained dependency installation, and configured pytest step. The existing Secret Scan workflow also completed successfully on the same commit.

Local checks also verified the workflow YAML structure and the uv CLI flags used. A local pytest pass is not claimed because the available shell environment did not have the project’s Python 3.12/dependency setup and later lost GitHub/PyPI DNS access.

Scope / limitations

This PR does not:

• make the smoke workflow a required branch-protection gate
• run tests requiring CouchDB, WatsonX/LLM credentials, or TSFM
• add repository-wide Ruff checks
• change benchmark scenarios, scoring, data, or agent behavior
• change branch-protection settings

Whether this workflow fits IBM organization Actions policy remains a maintainer/repository-policy decision; this PR is intended to make that first version concrete and reviewable.

[abhati27]

Nice, good to see this as a real workflow. Ran main (e844f64) on a 3.12 setup, two things:

uv lock --check exits 1 right now, so the job dies at step 1. #629 dropped one of two
duplicate sktime pins without re-locking, so uv.lock:344-345 still lists both. #637
reverts it. Though I'm on uv 0.8.14 vs your pinned 0.13.1, so maybe the newer one doesn't care.

And the paths you picked are green but miss the failing tests:

$ uv run pytest src/llm/tests src/servers/utilities/tests -q      # this workflow
33 passed in 0.98s

$ uv run pytest src/evaluation/tests src/observability/tests -q   # not included
8 failed, 122 passed in 0.26s

Six are a signature mismatch (fix looks like it's on aafeedback_changes), two just want
google.protobuf from --group otel. Nothing breaks at runtime so no rush, but it's the
sort of thing a smoke check is for. Both dirs run in under a second, you'd just need
opentelemetry-api and opentelemetry-sdk in the install step, both already in dev.

Only catch is it'd be red from day one until those get fixed, so maybe a follow-up is
cleaner. Either way.