Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの 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 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
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
フォーク
824
平均マージ
2日 22時間
マージ済み PR（30日）
43

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/devlake のほかの issue

apache/devlake の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。