Repository navigation
add test coverage for sdk running with different runtime versions #1067
Description
We're fixing to release 1.18 for Python SDK. There will also soon be a 1.18 Dapr runtime version. We want tests that prove that our SDK version can run compatibly with various runtime versions. Tests that should be added include:
- Python SDK v1.16 with Dapr Runtime versions: 1.14, 1.15, 1.16
- Python SDK v1.17 with Dapr Runtime versions: 1.15, 1.16, 1.17
- Python SDK v1.18 with Dapr Runtime versions: 1.16, 1.17, 1.18
All of our existing tests should be ran for these various versions.
https://docs.dapr.io/operations/support/support-release-policy/#sdk-compatibility
Activity
ashoksmore commentedon May 29, 2026
Hi @sicoyle ,
I'd like to take this on as my first contribution to the Dapr Python sdk. Could you assign it to me?
Also, one small question: should we test specific sdk release tags (eg v1.16.x) against each runtime version or the current branch/HEAD?
Thanks!
sicoyle commentedon May 29, 2026
Hiiiii 👋 First of all, thank you so much for your interest in the Dapr Open Source project, and in our Python SDK!! 🙌 Great question, and thank you for asking for clarification early!!
Test branch HEAD, not historical SDK tags. The compat policy is forward-looking: SDK v1.X is supported with runtimes v1.X, v1.X-1, v1.X-2, so what matters is that the code on each release line works against its three target runtimes. The release branches already pin the SDK code and CI just needs to vary the runtime.
PR to main for this pls. I'll add backport labels and our backport bot will fan it out to release-1.18, release-1.17, and release-1.16 branches automatically.
The change lands in .github/workflows/run-tests.yaml. Today it resolves a single DAPR_RUNTIME_VER dynamically. Instead, add a runtime-version axis to the matrix and pass the explicit version into the dapr/.github/.github/actions/setup-dapr-runtime@main action (it takes a version input).
One thing to think about up front since this gets backported: each branch needs a different runtime set (main → 1.17/1.18/1.19, release-1.18 → 1.16/1.17/1.18, etc.). Cleanest is to derive the three versions from the SDK's own version at workflow runtime (read dapr package version, compute N/N-1/N-2) so the same workflow file works unmodified on every backport. If that's awkward or you have issues with it pls lmk. Hardcoding the matrix on main would be less ideal.
Ping me if you need anything!! 😇
ashoksmore commentedon Jun 13, 2026
Update: Opened #1091 with the run-tests.yaml matrix changes. Thanks again for the clear guidance, @sicoyle! 🙌
Rebased and resolved the conflicts. CI is waiting on maintainer workflow approval for now; would appreciate a look when you have a chance. Thanks!
sicoyle commentedon Jun 16, 2026
AMAZING - you rock!! I will review later today :)