Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#9,209 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
docker, docker-compose, github-actions, go
Lĩnh vực
ci-cd, devops, infrastructure

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
3.2k
Fork
819
Merge trung bình
3 ngày 6 giờ
Pull request đã merge (30 ngày)
40

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/devlake

Tất cả issue của apache/devlake

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.