ci: run python SDK agent e2e against a SQLite server built from source

[ling-senpeng13]

What

Adds a gating python-sdk-e2e job to CI that boots the conductor server built from this commit in SQLite mode (the default persistence — no external DB) and runs the released python SDK agent e2e suite against it. This catches server changes that would break the SDK end-to-end before a release.

Why

Today nothing in this repo's CI exercises the agent SDK against a from-source server. The python SDK ships an e2e suite (conductor-oss/python-sdk, released as the conductor-ai-e2e-python-* bundle); wiring it here means a server-side regression in the agent surface (LLM chat/complete, tools, MCP, guardrails, scheduling, …) fails CI instead of surfacing after release.

How

• From-source server, SQLite: builds :conductor-server:bootJar and boots it on :8080. SQLite is the default (conductor.db.type=sqlite / queue.type=sqlite / indexing.type=sqlite), so no Postgres/Redis/ES services are needed.
• openai auto-config: the server reads conductor.ai.openai.api-key=${OPENAI_API_KEY:}, so setting the env var is enough — no manual integration registration.
• Bundle: fetches the pinned conductor-ai-e2e-python-2.0.0-rc2 bundle from conductor-oss/python-sdk at runtime, sha256-verified; run.sh installs conductor-python[agents]==<version> and runs the full suite.
• Skip support (green today): known failures are xfail-ed via an external pytest plugin (.github/agent-e2e/known_failures_plugin.py, loaded with -p known_failures_plugin) reading a per-repo list (.github/agent-e2e/known-failures-python.json). The suite is green against this server, so the list is empty — the mechanism stays so the lane can gate while any future gap is fixed (a fix XPASSes; a stale/mismatched entry is a harmless no-op that can't hide a regression).
• Cost control: runs on push/dispatch, and on PRs only when agent-relevant paths change (ai/, conductor-agentspan/, server/, core/, sqlite-persistence/, the workflow) via a detect-changes agent filter — so unrelated PRs don't spend LLM budget.

⚠️ Requires a repo secret

The job needs OPENAI_API_KEY (and optionally ANTHROPIC_API_KEY) configured as a repository/organization secret. GitHub does not pass secrets to fork PRs, so this job can only run with real LLM calls on branches in this repo (or once the secret is available) — a maintainer should validate it on a branch. The bundle version pin (2.0.0-rc2) should be bumped deliberately as new python-sdk releases cut their e2e bundles.

[ling-senpeng13]

Validated green ✅ (and the gate already earned its keep)

Ran on an internal branch so the org OPENAI_API_KEY / ANTHROPIC_API_KEY secrets are available (fork PRs can't see them — that's why the earlier fork draft #1350 was superseded by this one).

Final result: python-sdk-e2e job success — 0 failures / 154 tests / 26 skipped against a from-source server booted in SQLite mode (conductor-ai-e2e-python-2.0.0-rc2 bundle, real openai/gpt-4o-mini).

The gate surfaced a real server gap

While bringing this up, the job caught a genuine discrepancy (not infra):

agentspan skill register → POST /api/skills/register returns HTTP 404 "No static resource api/skills/register" on the server built from main.

That endpoint exists in the released 3.32.0-rc.8 (which conductor-oss/python-sdk's own agent-e2e.yml pins, so it's green there) but is absent from a from-source main build. Three Suite16 cli-skills tests hit it:

• test_cli_skill_register_list_get_pull_and_delete
• test_registered_cross_skill_dependency_versions_are_pinned
• test_cli_skill_run_registered_executes_downloaded_script_worker

They're xfail-ed (with the reason above) in .github/agent-e2e/known-failures-python.json so the lane gates green today. Worth a maintainer's look: either the skills-register endpoint needs to land on main, or it's expected to be absent and stays skip-listed. When it lands, those tests XPASS — the signal to delete the entries.

The other 151 tests — LLM chat/complete, tools, MCP, guardrails, termination, and the credential-lifecycle suites — all pass.

How the skip support works (kept even though ~green)

• .github/agent-e2e/known_failures_plugin.py — external pytest plugin (-p known_failures_plugin) that xfails any node-id listed in E2E_KNOWN_FAILURES. Tests still run; a fixed bug XPASSes (cleanup signal); a stale/mismatched entry is a harmless no-op that can't hide a regression.
• .github/agent-e2e/known-failures-python.json — the conductor-oss list (the 3 above).

Cost control

Runs on push/dispatch and on PRs only when agent-relevant paths change (ai/, conductor-agentspan/, server/, core/, sqlite-persistence/, the workflow) via the detect-changes agent filter — unrelated PRs don't spend LLM budget.

[ling-senpeng13]

Correction on the cli-skills failures — root cause + design decision

My earlier note said the skills-register endpoint was "missing on main." That was wrong — SkillController exists; it's gated:

@ConditionalOnProperty(name = {"agentspan.embedded", "agentspan.skills.enabled"}, havingValue = "true")

agentspan.embedded currently resolves true in OSS (via conductor.integrations.ai.enabled=true), but agentspan.skills.enabled is unset, so POST /api/skills/register → 404.

Design decision (per maintainers): agentspan.embedded is intended to be true only for orkes-conductor and false for conductor-oss, and that design may change. So we will not force-enable skills on boot for OSS — the skills API isn't a settled OSS surface. The 3 Suite16 cli-skills tests stay xfail-ed with an accurate reason, tracked in #1353; they'll XPASS (and the entries get removed) once the OSS skills story is settled.

Everything else is unchanged: 0 real failures / 154 tests, gate green.