feat: companion Docker/Podman image, auto-built and published on release (closes #23)

Built and locally verified (podman build + run --help) before committing,
not just written and assumed correct.

Dockerfile: python:3.11-slim base, builds from local source (COPY +
pip install .) rather than from PyPI - the release workflow tags and
builds this image from the SAME commit that gets published to PyPI,
avoiding any race between "is the new version live on PyPI yet" and
"the image build already started". Non-root user (no reason to run as
root, and the safer default for a container that may eventually have
the Docker/Podman socket mounted into it for #21). Unlike every other
OVOS container (background services), this one needs a TTY attached
(-it) since it's an interactive terminal tool, not a daemon - noted
clearly in both the Dockerfile and the new README section.

New .github/workflows/docker-publish.yml: mirrors publish.yml's own
structure exactly (same v* tag trigger, same test-first dependency via
test.yml's workflow_call, so neither release artifact ships without
tests passing) - builds and pushes to ghcr.io/andlo/ovos-tui-client,
tagged both by version and :latest.

README: new "Docker/Podman companion image" section covering how to
actually reach a messagebus from inside the container (--network host
for a simple local case, joining an ovos-docker install's own compose
network as the better long-term fit), and the elegant case this
enables - if the SAME volumes ovos_core uses get mounted into this
container too, it sees real files at normal paths with none of this
project's own host-side workarounds (--mycroft-conf, log-bridging)
needed at all.

224 tests passing (no code changes to the Python package itself, just
new build/packaging infrastructure); version bumped to 0.1.16 for
release.

Author: andlo

.github/workflows/docker-publish.yml

@@ -0,0 +1,45 @@
+name: Publish Docker image
+
+# Companion image for ovos-tui-client - see issue #23 and the README's
+# "Docker/Podman companion image" section. Mirrors publish.yml's own
+# trigger/test-first structure so both release artifacts (PyPI package,
+# container image) get built from the exact same tagged commit and
+# neither ships without tests passing first.
+
+on:
+  push:
+    tags:
+      - 'v*'
+
+jobs:
+  test:
+    uses: ./.github/workflows/test.yml
+
+  build-and-push:
+    needs: test
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Log in to GitHub Container Registry
+        uses: docker/login-action@v3
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Extract version from tag
+        id: version
+        run: echo "version=${GITHUB_REF_NAME#v}" >> "$GITHUB_OUTPUT"
+
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          tags: |
+            ghcr.io/${{ github.repository_owner }}/ovos-tui-client:${{ steps.version.outputs.version }}
+            ghcr.io/${{ github.repository_owner }}/ovos-tui-client:latest

Dockerfile

@@ -0,0 +1,32 @@
+# Companion Docker/Podman image for ovos-tui-client - see issue #23 and
+# the README's "Docker/Podman companion image" section.
+#
+# Unlike every other OVOS Docker image (audio, listener, messagebus,
+# each skill, etc), this one is NOT a background service - it's an
+# interactive terminal tool. Run it with `docker run -it` (or
+# `stdin_open: true` + `tty: true` in compose) - without a TTY
+# attached, Textual has no terminal to actually draw into.
+#
+# Built from local source (COPY + pip install .), not from PyPI - the
+# release workflow tags and builds this image from the SAME commit
+# that gets published to PyPI, avoiding any race between "is the new
+# version live on PyPI yet" and "the image build already started".
+FROM python:3.11-slim
+
+WORKDIR /app
+
+# Only what's needed to resolve/install dependencies copied first, so
+# this layer caches across rebuilds where only application code
+# changed, not dependencies.
+COPY setup.py version.py requirements.txt README.md ./
+COPY ovos_tui_client/ ./ovos_tui_client/
+
+RUN pip install --no-cache-dir .
+
+# Non-root user - no reason this needs root, and it's the safer
+# default for a container that (in a future iteration) may have the
+# Docker/Podman socket mounted into it for service management (#21).
+RUN useradd --create-home --shell /bin/bash ovos
+USER ovos
+
+ENTRYPOINT ["ovos-tui"]

README.md

@@ -60,6 +60,10 @@ None of this requires working audio hardware, a wake word, or STT accuracy getti
 pip install ovos-tui-client
 ```
 
+A container image is also published on every release - see
+[Docker/Podman companion image](#dockerpodman-companion-image) below
+if that fits your setup better.
+
 ## Usage
 
 ```bash
@@ -130,6 +134,33 @@ documentation directly, not guessed at:
   rather than a file - if a `bus` source never shows up even though
   everything else does, that's likely why, not a bug here.
 
+### Docker/Podman companion image
+
+Unlike every other OVOS container (audio, listener, messagebus, each
+skill), this one isn't a background service - it's an interactive
+terminal tool, so it needs a TTY attached to actually draw anything:
+
+```bash
+docker run -it --rm --network host ghcr.io/andlo/ovos-tui-client:latest
+```
+
+`--network host` is the simplest way to reach a messagebus already
+listening on the host's `127.0.0.1:8181`; on an `ovos-docker` install
+specifically, joining that stack's own compose network and pointing
+`--host` at the messagebus container's name instead works too, and is
+usually the better fit if this is meant to run alongside it long-term.
+Pass this tool's own flags after the image name, same as the pip
+install - e.g. `docker run -it --rm --network host
+ghcr.io/andlo/ovos-tui-client:latest --lang da-dk`.
+
+If the same volumes `ovos_core` uses for config/logs are mounted into
+this container too (`-v`/compose `volumes:`, matching whatever paths
+that install already uses), this tool sees the real files directly at
+their normal locations - no `--mycroft-conf` override or log-bridging
+needed at all in that case, the same as a native install would.
+Images are tagged by version (`:0.1.16`) and `:latest`, built and
+published automatically on every release.
+
 ## Why not just fix ovos-cli-client / neon-cli-client?
 
 `ovos-cli-client` (last released March 2022) installs cleanly via pip,

version.py

@@ -1,5 +1,5 @@
 VERSION_MAJOR = 0
 VERSION_MINOR = 1
-VERSION_BUILD = 15
+VERSION_BUILD = 16
 VERSION_ALPHA = 0
 # END_VERSION_BLOCK