[Refactor][CI] Publish the lake-builder image with the project's Docker Hub credentials instead of a manual tag #9209

What and why to refactor

Five CI jobs run inside mericodev/lake-builder:latest:
test.yml (unit-test), test-e2e.yml (mysql and postgres),
golangci-lint.yml and migration-script-lint.yml.

That image is out of date and, as far as I can tell, can no longer be
refreshed through the intended path:

The CI copes by re-installing the toolchain on every run
(install-libgit2.sh, install-go.sh, install-mockery.sh), so the jobs pass,
but:

• each job rebuilds what the image should already contain;
• changes to devops/docker/lake-builder/Dockerfile (most recently build(builder): make the lake-builder image rebuildable (bookworm, go.dev) #9203,
  and the Go/mockery bump in build(backend): bump Go to 1.26.9 and mockery to 3.8.1 #9208) are never exercised by the upstream CI;
• the base layers (bullseye, Python 3.9) are past or close to end of life.

Simply pushing builder-v0.0.16 may not help: it depends on credentials for a
non-ASF namespace whose validity I cannot check from outside.

Describe the solution you'd like

The repository already has working Docker Hub credentials:
build.yml logs in with DOCKERHUB_USER / DOCKERHUB_TOKEN and pushes to
${{ secrets.DOCKERHUB_OWNER }}/devlake on every push to main (last
successful runs on 2026-10-11). It already publishes auxiliary, non-release
tags there as well (devlake:amd64-builder, :base, :build-cache-*).

Proposal, in two small PRs:

1. Publish — change build-builder.yml to
   • use the same secrets as build.yml;
   • run on push to main when devops/docker/lake-builder/** (or the
     workflow itself) changes, plus workflow_dispatch — no manual tag needed;
   • push to the ASF namespace, either as a tag in the existing repository
     (e.g. apache/devlake:lake-builder-<short-sha>, following the
     amd64-builder precedent) or to a new apache/devlake-builder
     repository, if you prefer that and it can be created.
2. Consume — once the first image exists, point the five container:
   lines to the pinned new tag instead of mericodev/lake-builder:latest.

This also completes the idea of #5041 ("push the lake builder to … apache
dockerhub"), which was closed by the stale bot without a change.

I have validated the current Dockerfile on my fork: its CI builds the builder
image from devops/docker/lake-builder/Dockerfile and runs unit, lint and e2e
(MySQL, PostgreSQL) inside it — all green
(run, with the
changes from #9208).

Questions for the maintainers:

• Is moving the builder to the project's Docker Hub credentials acceptable,
  and which target do you prefer: a tag in apache/devlake or a separate
  apache/devlake-builder?
• Alternatively, if the mericodev credentials are still valid and you prefer
  the existing path: could someone push a builder-v0.0.16 tag on main?

I'm happy to open the PRs for option 1 once the direction is clear.

Related issues

• [Refactor][lake-builder] push the lake builder to not only merico dockerhub but also apache dockerhub  #5041 — push the lake builder to the Apache Docker Hub (closed as stale)
• [Refactor][Build] Unify common parts of CI and Prod Dockerfile into base images and automate Prod image builds #4805 — base images and automated image builds (closed as stale)
• build(builder): make the lake-builder image rebuildable (bookworm, go.dev) #9203 — made the lake-builder image rebuildable again (bookworm, Go from go.dev)
• build(backend): bump Go to 1.26.9 and mockery to 3.8.1 #9208 — Go 1.26.9 / mockery 3.8.1, including the lake-builder Dockerfile

Additional context

The latest policy discussed in #4805 (only update latest for formal
releases) is not affected: the proposal uses explicit, pinned tags for the CI
image and does not touch the release images.