Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#9,209 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
35/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
活跃
技术栈
docker, docker-compose, github-actions, go
领域
ci-cd, devops, infrastructure

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Go
星标
3.2k
派生
819
平均合并
3 天 6 小时
30 天内合并 PR
40

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/devlake 的其他 Issue

查看 apache/devlake 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。