README section documenting the containerd image store and a troubleshooting checklist for ImagePullBackOff after a deploy.
Changed
The registry auth payload sent during push now includes serveraddress, so Docker Desktop routes credentials to the pinexq registry on every version.
Update build backend uv_build to >=0.12.6,<0.13.0.
Fixed
deploy now aborts when the image push reports an error instead of reporting success. Previously a failed or partial push was swallowed and an unpullable code hash was registered, causing rare ImagePullBackOff failures in Kubernetes.
The registered code hash is now the digest reported for the push and is verified to exist in the registry before it is assigned, instead of a locally derived digest (RepoDigests/image ID) that could name a manifest the registry does not hold.
Security
Update dependency copier to 9.17.2, fixing CVE-2026-53951 (trust-prefix bypass via path traversal that could run template tasks unprompted).
Update dev dependency pytest to 9.1.1, fixing CVE-2025-71176 (unsafe /tmp directory handling).
Read-only list and show commands for six JMA Resources: job, workdata (alias wd), processing-step (alias ps), template, trigger, and folder. Each supports table, JSON, CSV, and quiet (-q) output, --wide, pagination (--limit/--offset/--all), sorting, and per-Resource filters; show accepts a UUID or URL for every noun, name@version for ProcessingSteps, and a /path for Folders. These commands resolve their connection leniently (flag → env → pinexq.toml) and run from any directory.
--help for every read command groups options into Connection / Output / Pagination / Filters panels; the enum filters (--state, --kind, --deployment-state) list their valid values and offer shell tab-completion.
Shell completion is enabled (pinexq --install-completion / --show-completion).
README “Reading Resources” section documenting the new commands.
pinexq job logs <ref> prints the Log entries of a Job, oldest first, following the Job’s Logs link to the monitoring service and paging through the whole log. -o text|raw|json selects the line format (text colours the level on a TTY, JSON is NDJSON), --level, --search, and --tail filter in the CLI, and --no-color (or NO_COLOR) forces plain output.
pinexq job metrics <ref> shows the Metrics of the Worker that ran a Job: a header with status, duration, and peak CPU and memory, followed by terminal plots of both series. -o json and -o csv emit the full series instead.
actions and action on every Resource noun, executing the hypermedia Actions the JMA advertises instead of a hardcoded set. actions <ref> lists what a Resource offers right now with each parameter’s type; action <ref> <name> executes one by name in any spelling. --root targets the Resource type’s creation Actions. Parameters come from --set KEY=VALUE and --json, typed and validated against the Action’s schema before anything is sent, and --dry-run prints the request without sending it.
Bound verbs on every noun, each wrapping exactly one advertised Action with typed flags: job start, delete, hide, unhide, rename, tag, move, set-error, and create; wd delete (with --force for a WorkData whose deletion is not allowed yet), hide, unhide, rename, comment, tag, move, upload, and download; ps deprecate, restore, delete, hide, unhide, rename, tag, move, set-defaults, and clear-defaults; template run, delete, edit, tag --scope, set-params, clear-params, set-input, clear-input, and create; trigger enable, disable, delete, edit, set-templates, set-cron, set-window, and create; folder create, rename, move, delete, and clear.
The multi-reference Bound verbs act on several Resources at once, read references from stdin with - (so job list -q --state failed | job delete - -y works), report a reference that fails and continue with the rest, and exit 1 if any failed.
wd upload <file> creates a WorkData from a local file, guessing the media type from the extension and applying --tag and --folder afterwards; wd download <ref> streams the content to a file, a path, or stdout, and refuses to overwrite without --force.
job create builds a fully configured Job in one request: ProcessingStep, --param values typed against the Function’s own schema, --input WorkData assignments (several per slot assign a collection), tags, a Folder, and --start.
An Action the JMA marks Destructive asks for confirmation before it runs. --yes skips the prompt, and without a terminal the command refuses rather than hanging.
show in table output now ends with the names of the Actions the Resource offers, so the next step is on screen. JSON and CSV output of show are unchanged.
README sections for the Action verbs, every noun’s Bound verbs, job logs, and job metrics.
Changed
The root --help groups the Resource commands under a “Resources” panel, and each noun lists its Bound verbs in a panel of their own.
New runtime dependencies: jsonschema (parameter validation) and plotille (the job metrics plots).
Live contract tests for the ProcessingStep name resolution, run against a real JMA with PINEXQ_LIVE_TESTS=1 uv run pytest -m live (they are skipped otherwise), so a mismatch between what the CLI sends and how the JMA filters is caught (#71).
Fixed
processing-step show <name> and <name>@<version> (and every Bound verb that takes such a reference) reported an existing ProcessingStep as not found. The name lookup sent the JMA’s ShowDeprecated and ShowPrerelease filters as true to include those versions, but the JMA reads true as “only these”, so the two together matched nothing. The lookup now sends no such filter, so deprecated, prerelease, and hidden versions all resolve (#71).
When a pinned version does not exist, the error now says which half failed: no ProcessingStep named <name>, or <name> has no version <version> followed by the versions that do exist (#71).
--hidden on job list, workdata list, and processing-step list, and --deprecated / --prerelease on processing-step list, now include those Resources as documented. They used to return only those Resources, for the same reason. processing-step list also excludes deprecated ProcessingSteps and prerelease versions by default now, as its help text always said.
job start --wait and template run --wait now wait for the resulting Job to reach a terminal state and exit non-zero when it does not complete successfully. --timeout limits the wait while leaving the Job running.
Step-by-step Job composition (#49). job create --name NAME now creates an empty Job to compose, --processing-step keeps the one-shot RapidSetupJob behaviour, and --parent JOB [--inherit-folder] creates a sub-job; a flag the chosen Action has no property for is a usage error before anything is sent.
job select-processing, job configure, job set-input, and job clear-input select a Job’s ProcessingStep, configure its parameters, and assign, source from a folder (--folder PATH [--no-recursive]), or clear the WorkData on one input DataSlot. job configure --param is typed against the Action’s own schema, falling back to the selected ProcessingStep’s parameter schema.
Input DataSlots are addressed by 0-based index or case-insensitive name, on job set-input / clear-input and on the Template verbs, and job show and template show now list the index.
Changed
Actions on sub-entities such as DataSlots stay reachable through the Bound verbs above rather than the generic action command (ADR-0006).
pinexq.toml can state a function’s deployment resources explicitly with cpu, memory and disk as Kubernetes quantities (cpu = "500m", memory = "16Gi", disk = "100Gi"), as an alternative to resource_preset (#79). Setting both, only some of the three, or a value that is not a whole number of millicores, MiB or GiB is a configuration error. A deployment table without either now uses the Medium preset; before, it had to name resource_preset. See the README.
pinexq ps show displays the deployment’s cpu_millicores, memory_mib and disk_gib next to resource_preset, which is empty for resources that match no preset.
Changed
Requires pinexq-client 2.6.1 or later (JMA API 11.1).
A function without deployment resources in pinexq.toml is deployed with Medium’s values as explicit resources (cpu = "1", memory = "4Gi", disk = "10Gi") instead of the Medium preset. The resources are the same.
Deprecated
resource_preset in pinexq.toml is deprecated and will be removed in a future release; state cpu, memory and disk instead. pinexq deploy warns for each function that uses a preset and prints its replacement, e.g. resource_preset "Large" is deprecated, state cpu = "3", memory = "14Gi", disk = "70Gi" instead. Presets keep working until then.
A Global config at ~/.config/pinexq/config.toml (honouring XDG_CONFIG_HOME) holds named Profiles, each pairing an endpoint with an API key, and names a default_profile. Select one with pinexq --profile NAME or PINEXQ_PROFILE. Flags and environment variables still win; a selected Profile overrides a Project’s pinexq.toml, the default Profile does not (ADR-0007). Applies to the Resource commands, deploy, and register. See the README.
Changed
pinexq deploy and pinexq register report their progress as a list of steps under a pinexq banner. A spinner and a running timer show what is in progress; then each step turns into a ✓ line with what was done, the details in muted text (the image size, the functions found, the pushed image’s digest, the CPU, memory, disk and replicas each function was configured with), and the time it took, aligned on the right. Each function gets a block of its own, and the run ends with a DONE badge and a pinexq ps show <name>@<version> line per deployed function. Docker commands, image IDs and raw push status lines are printed only with --verbose, and the push shows one progress bar for the image instead of one per layer. In CI, where there is no terminal, only the outcome lines are printed.
A failure is marked ✗ on the step it happened in, followed by the details and a FAILED badge with the reason.
A --function that names no function in the image is now an error that lists the functions the image has, raised before the linux/amd64 build or any push. Before, the name was ignored.
Fixed
A failed docker build shows Docker’s error summary from the end of the build log instead of only Docker build failed with return code 1. --verbose still prints the whole log.
With --verbose, the build log no longer loses bracketed text such as the [stage-1 3/6] step labels, and the push stream no longer loses the bracketed repository name.
Errors reading pinexq.toml or pyproject.toml were printed with raw markup ([bold red]pinexq:[/bold red]) and could lose bracketed parts of the message. They now go to stderr, formatted.
The image size warning is printed once, for the image that is pushed, instead of once per build.
A deploy without an endpoint says so instead of failing with 'NoneType' object has no attribute 'replace'.
pinexq.toml can state a function’s idle_timeout under [deployment] or [function.<name>.deployment]: how many seconds a job pod waits without a job before it stops, 1 to 3600 (#87). Without it, the platform’s default of 60 seconds applies. Needs a JMA that accepts the idle timeout (pinexq/job-management#232). See the README.
pinexq ps show displays the deployment’s idle_timeout_seconds, empty when the platform default applies.
