Add workflow for publishing custom Docker images from any branch

[robacourt]

Why

We sometimes need to publish Docker images from feature branches for testing (e.g. electricsql/electric:subqueries-alpha) without going through the release flow. The existing workflow only supports release tags, so there was no clean way to do this from CI.

Usage

In GitHub Actions, go to "Publish custom Electric image to Docker Hub" → Run workflow, and fill in:

• Git ref: branch name, tag, or commit SHA (e.g. rob/simple-subqueries-with-dnf)
• Docker Hub tag: the tag to publish as (e.g. subqueries-alpha)

This publishes a multiarch image to electricsql/electric:<your-tag>. It does not touch latest, canary, or the canary repo.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.67%. Comparing base (93e5d40) to head (10201ba).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4065   +/-   ##
=======================================
  Coverage   88.67%   88.67%           
=======================================
  Files          25       25           
  Lines        2438     2438           
  Branches      609      611    +2     
=======================================
  Hits         2162     2162           
  Misses        274      274           
  Partials        2        2           

Flag	Coverage Δ
packages/experimental	87.73% <ø> (ø)
packages/react-hooks	86.48% <ø> (ø)
packages/start	82.83% <ø> (ø)
packages/typescript-client	93.81% <ø> (ø)
packages/y-electric	56.05% <ø> (ø)
typescript	88.67% <ø> (ø)
unit-tests	88.67% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[alco]

Have you considered modifying the existing sync_service_dockerhub_image.yml workflow to add support for arbitrary ref building? I'd prefer that instead of having a dedicated workflow file since the two should follow the same approach for building multi-arch images. Future changes in any one of the two will lead to diverging build logic.

[robacourt]

Have you considered modifying the existing sync_service_dockerhub_image.yml workflow to add support for arbitrary ref building? I'd prefer that instead of having a dedicated workflow file since the two should follow the same approach for building multi-arch images. Future changes in any one of the two will lead to diverging build logic.

Yeah, I did consider it, and you can see it in the commit history:

8b269cd - both in one but a rather confusing UX of release_tag, custom_ref and custom_tag
9a1702b - better UX from splitting into two workflows but sharing workflow, bit of an odd abstraction though
ced2154 - a better abstraction for the shared file, but now the publishing is not shared

at that point I gave up, also worrying about breaking the release workflow and perhaps overcomplicating things. But you're right, it would be better to have the common workflow shared.

I could either:

• go with one of the earlier commits if you think they look good
• push on with the direction ced2154 was going and share the publishing too
• go back to having one workflow but with two inputs, git_ref (mandatory) and docker_tag (optional - and if it's not provided, is calculated based on git_ref) but I'd need to change other workflows that call this one to use git_ref rather than release_tag

What do you reckon?