embabel version

Which appliance this is, in the four layers that can actually differ between two installs. There is no single number, and printing one would be a lie:

Checkout	this repo’s commit — the pin for everything in files rather than images: the compose files, setup.py, the skills
Release	what the appliance follows — stable, beta, nightly, canary or one build — and a legacy EMBABEL_VERSION pin, if one outranks it. embabel release says more
Server	the image tag as compose resolves it, and the digest that tag currently means. A release names a stream, so the tag is a name; the digest is the artifact
Built from	the commit the server’s jar was built from, read out of git.properties inside it — with the branch, the subject line, and whether the build carried uncommitted changes
Graph	the Neo4j image and its digest — or, on the Embabel engine, that the graph is inside the server, whose version is its version

A build from a dirty tree says so, loudly, because its commit names where the build started rather than what is in it. A build old enough to carry only an abbreviated SHA is marked (abbreviated only) rather than printing seven characters as though they were an answer.

It does not call the server. /actuator/info carries the same build and git blocks, but it is authenticated, and the moment anyone needs the version is the moment the appliance will not boot, is wedged, or is halfway through an upgrade — when an endpoint answers nothing. This reads the image and the jar instead, and works with the container stopped (a little slower: it starts a throwaway container to read from the image).

Reading the jar is cheap despite the jar being ~400MB: the zip index lives at the end of the file, so it takes the tail, finds one entry’s offset, and reads a couple of hundred bytes.

Flag
--json	the same four layers, as JSON

embabel backup records exactly this in each backup’s manifest.json, so a year-old backup can still say what wrote it.