Revisit building the Conductor server from source in E2E CI (and the 6 server.bats tests it skips)

[ambiorix2099]

Summary

CI now builds the Conductor OSS server from source (conductor-oss/conductor at main) for the
E2E jobs. This is correct for the current release — releases are cut from main and no artifact is
published from it — but it carries costs worth revisiting once the release has shipped.

Two related things to decide.

1. Should CI keep building from source, or pin a published RC?

Why we build from source now. There is no published artifact built from main:

• Maven Central's newest org.conductoross:conductor-server is the newest tag (an RC), not main.
• The S3 jar the CLI's server start downloads as latest was last modified 3 June 2026 — months
  stale. Possibly a broken publish; see item 3.

So testing what will actually ship means building it.

Why to reconsider. RCs are cut from main, so a published RC is a main snapshot. When this was
set up, main was 8 commits ahead of v3.32.0-rc.23, and those commits were UI fixes, a CI fix,
provider API-key whitespace trimming, and agent token-usage aggregation — nothing that changed CLI
behaviour. Pinning to an RC would:

• Remove a full Gradle build from every PR run (locally the build took ~41s warm, but a cold CI
  runner with no Gradle cache will be substantially slower).
• Decouple this repo's CI from the server repo's build health. Today a broken main in
  conductor-oss/conductor turns every conductor-cli PR red for reasons unrelated to the CLI.
• Make runs reproducible: a pinned jar is byte-identical between runs, a main build is not.

Trade-off. Pinning trades "tests exactly what ships" for speed, isolation and reproducibility, and
introduces a bump chore. Building trades those for fidelity.

Suggested trigger for revisiting: after this release ships, or the first time a red CI run turns out
to be caused by the server build rather than the CLI.

2. server.bats loses 6 tests under the source-build approach

conductor server start can only download published versions — it has no way to run a local jar. So
CI must launch the source-built server with java -jar directly, which means no CLI-managed pid file
exists, and the 6 server-dependent tests in server.bats skip:

6  no CLI-managed local server is running

They skip loudly with a reason rather than failing, but that is 6 tests of real coverage — including
the server start / server update mutual-exclusion guards — not running in CI.

Options:

• A. Add conductor server start --jar <path> (or --jar-path), letting CI hand the CLI a
  source-built jar. Closes the gap properly and is independently useful for anyone testing a local
  server build. Small feature.
• B. Accept the skip while CI builds from source, and rely on local runs for those 6 tests. Zero
  work, permanent gap.
• C. Revisit item 1 — pinning an RC restores conductor server start as the launch path and the 6
  tests with it.

A is worth doing regardless of how item 1 lands, because it also makes local testing of a server
build possible without bypassing the CLI.

3. The S3 latest jar looks stale

https://conductor-server.s3.us-east-2.amazonaws.com/conductor-server-latest.jar has
Last-Modified: Wed, 03 Jun 2026. If that is meant to track main or the newest release, the publish
job appears to have stopped. Worth raising with whoever owns that bucket — a working latest (or a
main-tracking snapshot) would make item 1 moot by giving CI a cheap, current artifact.

Context

Introduced alongside the E2E tag/tier work. See docs/adr/0001-e2e-tests-are-tag-selected-bats-suites.md
for the surrounding decisions, and test/e2e/README.md for how to run the suites.