refactor(docker): container workflow and docs

[lbatalha]

What does this PR do?

• Refactor docker workflows to be able to run on forks, and additionally trigger on push for any branch and in PRs to Staging/Master (this allows easy testing of workflow changes, as well as letting people pull container images with future PRs/changes for ease of testing/deployment
• Add docker workflows for iturhfprop and dxspider-proxy microservices
• Refactor docker documentation to have a more centralized location in docs/ as well as add references to the new container images that will be available with the new workflows (so it is no longer necessary for people to clone the repo to build these microservices)
• BONUS 🌟: workflows as they are would break June 2nd 2026 due to github deprecating Node 20 in the action runners - all the actions we are using have versions which still use Node 20, so a separate PR should be created to update the non-docker workflows preemptively. I have submitted fix(actions): update github actions to node24-based versions #1028 with the remaining fixes.

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

1. Check that workflows are being triggered as expected
2. check the packages page for the repo @ https://github.com/accius/openhamclock/packages) for correct artifact creation
3. Review the documentation changes, I did my best to have a unified way of documenting docker stuff, but also dont want to completely reorganize the overall repo structure.

[lbatalha]

The workflows are failing due to installation not allowed to Write organization package - I think that when using $GITHUB_TOKEN for authorizing the actions you need to manually add the write permissions for each workflow in https://github.com/accius/openhamclock/settings/actions or so?
Since they all have new names, they probably need checking.

[accius]

Thanks for the writeup, and good catch on the Node 20 thing. I would've completely missed that until something blew up in June.

Went down a bit of a rabbit hole on these failing checks and I don't actually think it's the Actions settings. Pulled the logs and all three new workflows die at the same spot:

denied: installation not allowed to Write organization package

Which sounds like a perms issue but the existing OHC docker push has been happily shipping from Staging for ages under those same settings, so something else is going on. I'm pretty sure it's that this PR is from a fork, and GitHub hard-caps GITHUB_TOKEN to read-only on pull_request events from forks no matter what you put in permissions:. It's a security thing on their end. Basically prevents a random fork from opening a PR that smuggles secrets out via a malicious Dockerfile. Annoying, but I get why they do it.

Long story short, flipping repo or package settings won't unblock fork PRs. The fix has to live in the workflow itself.

What I'd do is let fork PRs still build (so the Dockerfile gets validated) but skip the push and attestation steps. Something like:

- name: Build and push Docker image
  id: push
  uses: docker/build-push-action@v7
  with:
    push: ${{ github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository }}
    # rest stays the same

And the attestation step needs the same guard (it wants id-token: write which fork PRs also can't have):

- name: Generate artifact attestation
  if: ${{ github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository }}
  uses: actions/attest-build-provenance@v4
  # ...

That gets you basically everything you were going for. Same-repo branches, same-repo PRs, pushes, and releases all still publish images, and fork PRs just quietly build-only instead of red-X'ing the whole PR. If an external contributor really wants a test image they can still push from their own fork, it just lands at ghcr.io/<their-user>/openhamclock, which is honestly probably what you want anyway.

Once that's in I think the checks should clear and we can get this merged. And yeah, I'll spin up a separate issue for the Node 20 upgrade so we don't lose track of it before the deadline.

[lbatalha]

I suppose that works. Doesnt seem like its something that can be worked around while using GITHUB_TOKEN. Seems like most projects that configure it this way just setup a github app which you can use to run workflows instead.