feat: docker-compose support + Docker Hub publish workflow

[dj4oC]

Problem

This repo has no docker-compose.yml (a contributor has to build the binary or run a bare
docker run by hand to test changes), and no GitHub Actions workflow publishes the
owncloud/ocis-mcp-server image anywhere. owncloud/ocis PR
#12603 added this image as an optional
service in the ocis_full deployment example, but flagged as a known limitation that the
image doesn't exist on any registry yet — verified via a 404 from Docker Hub.

Solution

• Added docker-compose.yml + .env.example for local dev: cp .env.example .env, fill in
  your oCIS URL and a secret, docker-compose up --build. Always uses the HTTP transport
  bound to 0.0.0.0:8090 (required for port publishing), so OCIS_MCP_HTTP_SECRET is
  required — same fail-closed posture as the owncloud/ocis ocis_full wiring.
• Fixed a pre-existing bug in README.md's "Quick Setup" and "Docker" sections: they used
  OCIS_URL / OCIS_ACCESS_TOKEN, which internal/config/config.go has never read (the
  real names are OCIS_MCP_OCIS_URL / OCIS_MCP_APP_TOKEN_USER /
  OCIS_MCP_APP_TOKEN_VALUE). Following the old docs literally failed at startup. Fixed
  both sections and added a new "Docker Compose" section.
• Added .github/workflows/docker.yml:
  • build job (every push + PR, no credentials needed): builds linux/amd64, loads it,
    and smoke-tests that the binary actually starts and fails config validation with the
    expected error; separately validates linux/amd64 + linux/arm64 both build
    (push: false).
  • publish job (push to main, v* tags, or manual workflow_dispatch): logs into
    Docker Hub and pushes a multi-arch image — latest on main, semver tags
    (vX.Y.Z/X.Y/X) on version tags.

Testing

• docker-compose config --quiet, docker-compose up --build, and a live curl round-trip
  (401 unauthenticated, 200 + valid JSON-RPC initialize result when authenticated)
  confirmed locally.
• Reproduced the workflow's smoke-test assertion locally with a plain docker build +
  docker run (linux/amd64 only, this machine has no local buildx for the arm64 leg).
• The real PR-triggered run of .github/workflows/docker.yml for this branch did not
  run to completion: it finished with conclusion startup_failure, 0 jobs created, 0s
  duration, no logs —
  https://github.com/owncloud/ocis-mcp-server/actions/runs/29567752175. See "CI Status"
  below for the investigation and likely cause.

Known Limitation / Manual Prerequisite

The publish job needs repository secrets DOCKERHUB_USERNAME and DOCKERHUB_TOKEN (a
Docker Hub access token, not a password) added under Settings > Secrets and variables >
Actions, using an account with push access to the owncloud Docker Hub org/namespace.
This PR cannot configure that — a maintainer needs to add both secrets. Once the workflow
is allowed to run at all (see "CI Status" below), the build job will pass on every PR
while publish will fail at the login step on main/tag pushes until these secrets exist.
Once the secrets are added, either push to main or a v* tag, or
trigger workflow_dispatch manually, to get the first real Docker Hub image published —
that also unblocks owncloud/ocis#12603.

CI Status: docker.yml Workflow Currently Fails to Start

The new .github/workflows/docker.yml workflow does not run at all on this branch. The
actual run — https://github.com/owncloud/ocis-mcp-server/actions/runs/29567752175 —
completed with conclusion startup_failure, 0 jobs created, 0s duration, and no logs of
any kind. This is a more fundamental blocker than the Docker Hub secrets prerequisite
noted above: until it's resolved, neither build (which needs no secrets) nor publish
can run at all.

This was investigated and is not a workflow-authoring bug or a transient blip:

• The YAML validates cleanly with both PyYAML and actionlint — no syntax or schema
  errors.
• It isn't a one-off infra hiccup: the sibling ci.yml workflow ran successfully on the
  identical commit.
• Querying the Actions-permissions API for this repository returned 403 from this
  session — there's no org-admin visibility available here to inspect or change the
  setting directly.

Most likely explanation: a startup_failure with zero jobs created is the known signature
of an organization-level GitHub Actions allow-list rejecting a workflow before any job is
even scheduled. If the owncloud org's Actions settings are configured to Settings >
Actions > General > "Allow select actions and reusable workflows", and the docker/*
actions this workflow uses (docker/setup-qemu-action, docker/setup-buildx-action,
docker/login-action, docker/metadata-action, docker/build-push-action) aren't on that
allow-list, GitHub blocks the entire run at dispatch time — before any job or log is
produced, which matches exactly what was observed.

This requires an owncloud org admin to check and, if applicable, add docker/* (or the
five specific actions above) to the allow-list. It cannot be checked or fixed from this
session. Until resolved, this workflow cannot be verified to run at all, independent of the
Docker Hub secrets issue above.

Risk

Low. Purely additive (new files, one doc bug fix); no existing runtime code changed.

🤖 Generated with Claude Code

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.