Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#9,209 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, docker-compose, github-actions, go
Área
ci-cd, devops, infrastructure

Línea de trabajo

Read .github/workflows/build-builder.yml and compare its credentials and triggers with .github/workflows/build.yml; inspect devops/docker/lake-builder/Dockerfile and the five workflow image references named in the issue. First confirm with maintainers which Docker Hub target to use, since the proposal depends on that decision. Done when the builder image publishes with project credentials on the stated triggers and all five CI jobs consume a pinned tag.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

Fact Source
mericodev/lake-builder:latest is v0.0.15, pushed on 2023-06-30, amd64 only Docker Hub API
It was built from the Dockerfile of that time: debian:bullseye, golang:1.20.4, libgit2 1.3.2, python:3.9-slim-bullseye git show f29d31451:devops/docker/lake-builder/Dockerfile
The only publishing path is build-builder.yml, triggered by a builder-* tag. The newest such tag is builder-v0.0.7 (2022), so v0.0.8–v0.0.15 were pushed outside this workflow git ls-remote --tags origin 'builder-*'
build-builder.yml logs in with DOCKER_REGISTRY_USERNAME / DOCKER_REGISTRY_PASSWORD and pushes to the company namespace mericodev; no run of it is visible in the Actions history workflow file, Actions API

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 #9203,
    and the Go/mockery bump in #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

  • #5041 — push the lake builder to the Apache Docker Hub (closed as stale)
  • #4805 — base images and automated image builds (closed as stale)
  • #9203 — made the lake-builder image rebuildable again (bookworm, Go from go.dev)
  • #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.

Lenguaje dominante
Go
Estrellas
3.2k
Forks
819
Merge medio
3 d 6 h
PR fusionados (30 d)
40

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/devlake

Todos los issues de apache/devlake

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.