docs(docker): improve container documentation#1014
Conversation
Release v26.3.1 — Staging → main
Hotfix: guard PropagationPanel against empty/invalid timeZone (RangeError on first load)
…g_line787 [Hotfix main] bug fix spelling of console.debug
Release v26.3.2 — pre-Hamvention drop (MeshCom + VOACAP hotfix)
whatsnew(26.3.2): correct MeshCom contributor attribution
Cuts Staging into main for the v26.3.3 release.
…ction
The socket idle timeout (60s) was the shortest of all failure timers, so
any 60s gap between spots — normal on quiet bands overnight — tore down a
healthy connection. Keepalive (120s) was too slow to prevent it and the
180s activity watchdog (the graceful node-failover) never got to run.
- socket timeout 60s -> 300s, as a last-resort TCP backstop; the 180s
activity watchdog now owns failover as designed
- keepalive 120s -> 60s so the connection stays warm
- destroy the socket in the 'timeout' handler — Node does not auto-close
on timeout, leaving a zombie socket that kept feeding data and
spuriously reset the failover counter after [RECONNECT]
- mark authenticated on first spot; the DXSpider prompt has no trailing
newline so prompt-based detection never matched, and sh/dx output lines
("...de Helmut<DF4IY>") false-matched the prompt regex
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
accius
left a comment
accius
left a comment
There was a problem hiding this comment.
Thanks for picking this up — the GHCR images aren't discoverable today and the iturhfprop microservice compose example is a nice add. The docker-compose → docker compose (V2) update is overdue. Verified the GHCR image is real: docker-image.yml publishes to ghcr.io/accius/openhamclock on every tagged release.
One blocker, one substantive note, a couple of small things.
Blocker — wrong base branch. This PR targets main, but all in-flight work for this repo merges to Staging first (main only takes a release at a time). External docs PRs are no exception. Could you retarget the PR to Staging? (Easiest from the GitHub UI under "Edit" on the PR title; no need to recreate.)
docker-compose.yml has both build: . and image: .... With both present, docker compose up still builds by default and tags the build as the image name — it doesn't pull the prebuilt image automatically. So the README change implies "use the prebuilt image" but the compose file's default behavior is unchanged. Two cleaner options:
- For the "pull the prebuilt image" UX: remove
build: .from the default compose file and documentdocker compose buildfor users who want to build from source. - Or split into two files —
docker-compose.yml(pullsimage:) anddocker-compose.build.yml(overrides withbuild:).
As written, anyone following the new docs will still do a local build on first up, which defeats the point of pointing them at GHCR.
Smaller notes:
- README reorders Quick Start to put "Container Deployment" before "Local Install". Fine editorially, just confirming it's deliberate.
- iturhfprop compose snippet — the
iturhfprop:service has noimage:tag, norestart:policy, no healthcheck, and no port mapping. Users following the snippet will get a working container but it's less robust than the main service block. Minor — could mirror the main service's structure for consistency, or leave it minimal since it's an internal-only service on the compose network. - The dropped sentence "(in the
iturhfprop-service/directory)" → "(documentation and deployment examples initurhfprop-service/README.md)" is a slight regression in discoverability — the directory pointer is useful for people who don't think to open the subdir README. Could mention both.
CI itself: the checks list is empty here, which usually means GitHub didn't trigger them for an main-targeted PR with this profile — that'll sort itself once the base is changed to Staging.
— K0CJH
|
I have repointed the PR to Staging from my side. |
|
After pointing to staging it looks like you will need to run a prettier on the code and update the PR. |
|
The lint issue was related to me leaving the correct indentation for the compose file in the code snippet, this is important so new people copy pasting dont accidentally break the yaml, so I added a quick skeleton of a compose file to provide more context, what do you think? As for the compose build issue, not sure how claude got that review wrong as its well documented behavior 😅. As for the small comments:
Sorry about targeting this to main, completely forgot its supposed to go to staging 🤦♀️ |
2 participants
What does this PR do?
I think it would be nice if the ITURHFPROP service also had a github action to build a container image similar to OHC, to simplify new deployments.
Type of change
How to test
To test the compose file change simply
docker compose pulland verify that the image is pulled from ghcr.io