Add Dockerfile and ghcr publish workflow (ovos-persona-server) - #19
Add Dockerfile and ghcr publish workflow (ovos-persona-server)#19JarbasAl wants to merge 3 commits into
Conversation
Move packaging from setup.py to pyproject.toml, matching the sibling ovos-solver-plugin-aiml layout, and register the plugin under the modern opm.agents.chat entry point group by porting RiveScript to ChatEngine. The legacy neon.plugin.solver entry point is kept pointing at the original RivescriptSolver class, so nothing that still looks there breaks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ship a runnable image instead of just a pip-installable plugin, so RiveScript can be tried as an OpenAI-compatible chat endpoint with one docker run. The image runs ovos-persona-server with a bundled persona whose solver list names this plugin, following the pattern already used by ovos-plugin-linguonnx for its own server image. ovos-persona-server[mcp] is pinned to >=0.17.0a1 and --mcp is passed explicitly, matching that release's change where the extra alone stopped mounting the MCP endpoint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Checking the status... all automated tasks are done! ✅I've aggregated the results of the automated checks for this PR below. 🔨 Build TestsThe build results are looking solid. 💎 ✅ All versions pass
Automating the path to a better future 🌈 |
1 participant
This stacks on #18 (the pyproject.toml / ChatEngine migration) and gives the plugin a runnable image, since a plugin entry point alone still needs a server around it before anyone can actually talk to it. The Dockerfile installs
ovos-persona-server[mcp]from PyPI and this plugin from the local checkout, then runsovos-persona-serverpointed at a bundled persona file whose solver list names this plugin's entry point. Both the ChatEngine and the legacy QuestionSolver share that same entry point name across their two groups, and ovos-persona-server prefers the ChatEngine when both are present, so the image gets the modern code path automatically.The
ovos-persona-server[mcp]floor is pinned to>=0.17.0a1and--mcpis passed explicitly on the entrypoint, because from that release installing the[mcp]extra alone no longer mounts the MCP endpoint. The workflow copies the ghcr publish pattern already used by ovos-plugin-linguonnx: build on PRs touching the Dockerfile without pushing, and pushlatest/dev/tag images on the real branches.I built this image on ser9 (not this machine, which has no Docker) and ran it as a throwaway container named rstest-rivescript-run on port 8385, one of the free ports in the assigned test range.
docker logsshowsloaded RivescriptChatEngine plugin: ovos-solver-rivescript-plugin, confirming the server picked the ChatEngine over the legacy solver. A real round trip against the running container:request:
POST http://localhost:8385/v1/chat/completions {"model":"rivescript-bot","messages":[{"role":"user","content":"hello there"}]}reply:
{"choices":[{"finish_reason":"stop","index":0,"message":{"role":"assistant","content":"Hey, how are you? Go on..."}}], ...}No credentials were needed, as expected for a RiveScript backend. The container and image were removed afterward and the build directory deleted; nothing from this test was left running on ser9.