Add custom Docker image publishing to the existing workflow

[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 supported release tags via release_tag, so there was no clean way to do this from CI.

Usage (custom builds)

In GitHub Actions, go to "Publish Electric images to Docker Hub" → Run workflow

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>. Custom builds don't touch latest, canary, or the canary repo.

Implementation

Rather than adding a separate workflow, this extends the existing Docker Hub workflow with a new optional docker_tag input and replaces release_tag with the more general git_ref.

The workflow now has three build modes, determined automatically from the inputs:

Trigger	git_ref	docker_tag	Build mode	Docker tags
Push to main	—	—	canary	canary, electric-canary:latest, electric-canary:<sha>
Release event / changesets	release tag	—	release	latest, <version>
Manual with both inputs	any ref	custom tag	custom	<custom tag> only

Also updates changesets_release.yml to use the renamed git_ref input.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.67%. Comparing base (cb2c45e) to head (117931d).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4065      +/-   ##
==========================================
+ Coverage   85.90%   88.67%   +2.77%     
==========================================
  Files          51       25      -26     
  Lines        3399     2438     -961     
  Branches      610      616       +6     
==========================================
- Hits         2920     2162     -758     
+ Misses        477      274     -203     
  Partials        2        2              

Flag	Coverage Δ
elixir	?
elixir-client	?
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% <ø> (+2.77%)	⬆️

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?

[netlify]

✅ Deploy Preview for electric-next ready!

Name	Link
🔨 Latest commit	117931d
🔍 Latest deploy log	https://app.netlify.com/projects/electric-next/deploys/69cab768ce2c2d0008b273bb
😎 Deploy Preview	https://deploy-preview-4065--electric-next.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[robacourt]

I've gone with

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)

what do you think @alco ?