[robfrank]

Closes #3

Both CI workflows (test-python-bindings.yml, test-python-examples.yml) take a new arcadedb-tag input, on workflow_dispatch and on workflow_call, defaulting to latest. A top-level ARCADEDB_IMAGE_TAG: ${{ inputs.arcadedb-tag || 'latest' }} feeds download-jars, which now pulls arcadedata/arcadedb:<tag> instead of a hard-coded latest. Push, pull_request and schedule runs pass no input, so they still build from latest.

The build jobs take their Docker base image by the engine version read from the jars, not by the requested tag. A pinned tag therefore has to be an exact version tag, and download-jars now fails fast with a clear message if it isn't. The README's Development section documents the input.

Test plan

• RED: on main, gh workflow run test-python-bindings.yml -f arcadedb-tag=26.10.1 was refused with HTTP 422: Unexpected inputs provided: ["arcadedb-tag"].
• GREEN: dispatched test-python-bindings.yml on this branch with arcadedb-tag=26.10.2. download-jars logged Downloading JARs from arcadedata/arcadedb:26.10.2, bundled arcadedb-engine-26.10.2.jar and resolved ArcadeDB version: 26.10.2, and every job passed: https://github.com/ArcadeData/arcadedb-python-bindings/actions/runs/39868652872
• GREEN: the same for test-python-examples.yml, which also resolved 26.10.2, and every job passed: https://github.com/ArcadeData/arcadedb-python-bindings/actions/runs/39868662966
• The default path: this PR's own pull_request runs still build from latest (26.11.1-SNAPSHOT).
• actionlint and pre-commit pass on both workflows.

Coverage

Invariant: in CI, the jars bundled in every wheel come from arcadedata/arcadedb:<arcadedb-tag>, and from latest when no tag is given.

The writers and readers of the image tag, found with grep -rnE 'arcadedata/arcadedb[:"$ ]|arcadedb:latest|ARCADEDB_TAG' .github scripts:

• The workflows had two docker create arcadedata/arcadedb:latest calls, one in each workflow's download-jars. Both now use ARCADEDB_IMAGE_TAG.
• Everything downstream reads the version taken from the jars (needs.download-jars.outputs.arcadedb-tag):
  • build.sh uses it as DOCKER_TAG.
  • Dockerfile.build uses it in FROM arcadedata/arcadedb:${ARCADEDB_TAG}.
  • build-native.sh pulls it with docker run only when there are no jars, and CI always passes the artifact jars.

Entry point	Fixed	Tested
bindings workflow_dispatch	yes	dispatch run above
examples workflow_dispatch	yes	dispatch run above
bindings and examples workflow_call	yes	argued: same inputs.arcadedb-tag expression as dispatch, and no caller exists yet (no release workflow)
push / pull_request / schedule (no input)	yes, falls back to latest	this PR's own runs

Known gaps: None. The tag-mismatch guard is not exercised by a real run, because no published tag holds a jar version different from its own name. It is two string comparisons, linted by actionlint.

Adversarial pass

I ran one independent review of the patch. Its findings and what I did:

1. The pinned tag stops at download-jars; the build jobs pull arcadedata/arcadedb:<jar version>. Real: an alias tag would build against a different base image than requested. Fixed here: download-jars now fails when a pinned tag doesn't name the jar version exactly. I kept passing the jar version on, because build.sh checks the jars against it.
2. workflow_call is untested. Real but argued: there is no caller in the repo yet, and it reads the same expression as dispatch.
3. The defaults differed between dispatch (default: "latest") and call (none). Fixed here: both declare default: "latest".
4. The edited comments ran past the wrap width. Fixed here.

Review cycles

This repository has no Claude review workflow (.github/workflows holds only the two test workflows), so no bot review was waited for. Final state: no-reviewer.

🤖 Generated with Claude Code