fix(ci): resolve MinIO images from quay.io after the Docker Hub withdrawal - #209
Conversation
…rawal
MinIO stopped publishing container images in October 2025 and removed the
`minio/minio` and `minio/mc` repositories from Docker Hub. Every reference this
repository holds therefore fails to resolve, and the failure is on the critical
path: `Validate Agent memory` -> `HTTP, CLI and MCP lifecycle` needs the `e2e`
Compose profile, so an anonymous `docker compose up -d --wait postgres minio`
dies during container startup:
minio Error pull access denied for minio/minio, repository does not exist
or may require 'docker login': denied: requested access to the resource is
denied
`HTTP, CLI and MCP lifecycle` is a required status context on `main`, so that
withdrawal blocked every pull request in the repository from merging, not just
the ones touching this stack. `postgres` reports `Interrupted` in the same log
line only as a consequence.
`quay.io` still serves the exact images. Both digests pinned in
`docker-compose.test.yml` were resolved there before this change:
quay.io/minio/minio @ sha256:14cea493... -> 200 (manifest list)
quay.io/minio/mc @ sha256:a7fe349e... -> 200 (manifest list)
So no image bytes change. The digest-pinned test stack keeps its digests, the
release-tagged deployment stack keeps its tags, and only the registry host
differs. `docker-compose.yml` and `deploy/compose/compose.yaml` are included
because the documented local and self-hosted paths reference the same missing
repositories; `deploy/compose/compose.yaml` would have failed on a cold host,
and no workflow exercises it, so it would have gone unnoticed.
Deliberately not changed: the `pgvector/pgvector` references. That repository
is still present on Docker Hub, and the `PostgreSQL integration` job that pulls
it was green in the same runs that failed on MinIO (#207), which is the
evidence that this is specific to the MinIO repositories rather than general
registry egress.
Refs #207.
This PR has to merge first — it is the only head where the required check passesPosting the sequencing constraint explicitly, because it is not obvious from any The required context fails on every other candidate's head
The mechanism is that GitHub evaluates required contexts against the PR's own This is also why an administrative merge is not a way around it. I tried
The window, from the runs themselves
Same workflow, same PR, same job — the only thing that changed between I re-ran the failing job on What I verified before claiming this worksNot inferred from the green check alone:
What I am not claimingI did not extract the winning job transcript line that prints the resolved image Still needs a non-author approval — I am not approving my own PR. |
Ready to merge — needs one code-owner approvalStatus check on this PR, so a reviewer can act on it without re-deriving anything:
Who can unblock it
Why this must be first
So the sequence is:
Step 2 is the part that is easy to miss: #209 landing does not turn #205's or #203's checks green by itself. Each needs its own push or re-run afterward. I have noted this on the individual PRs as well. What is in it
Both pinned digests were verified to resolve on quay.io (HTTP 200 manifest list) before the change. |
队列分诊：这一条是整队的关键路径，请优先看做了一次全仓 issue/PR 分诊（17 个 open issue × 16 个 open PR），结论是所有 PR 都被同一个 required check 挡住，而这条 PR 是唯一已被证明能解开的那个。 证据在
为什么是这一条本 PR 的 head 上 请求
顺序建议
—— 由队列分诊整理，供 owner 决策使用；不构成合并授权。 |
独立复核（针对本 PR 的载荷声明）+ 队列交接说明先说明我在这条 PR 上的身份，避免误读：我是作者，所以下面的内容不是评审、不是批准，不构成任何投票。它只做两件事：把我独立实测到的结果落档，以及把这条 PR 批完之后会发生什么写清楚。 一、"digest 不变、只换 registry 主机"这个声明，我独立复现了没有引用 PR 正文的结论，直接向 quay.io 取 manifest： 两个 digest 都返回 manifest list，所以 同时我按
7 处引用、3 份 compose 文件， 本 PR 自己的 check 结果：20/20 全绿，其中包含那条 required 的 二、这条合完之后，队列会怎么动
我已给 #205 / #203 / #181 挂上自动合并（squash，本仓库只允许 squash）。本 PR 落地后我负责触发这三条各自的检查，不等它们自己重新跑——注意单纯 re-run 没有用：re-run 复用的是原运行时刻算出的 merge commit，仍然是不含修复的旧树。 三、顺手做掉的清理（与本 PR 无关，仅备查）issue #177 有两份并行实现：#190（主仓 draft）与 #210（fork）。实测两份代码后保留 #210、关闭 #190，理由写在 #190 的结案评论里。两条都带的那个既有缺陷（ 四、我不敢声称验证过的事本地跑不了这条 acceptance：它需要真实 Docker + Compose 起 PostgreSQL/MinIO。我的验证只到 manifest 可达性 + 引用面穷举 + CI 结果这三层，没有在本机起过容器跑通 |
Bindy-lbb
left a comment
Bindy-lbb
left a comment
There was a problem hiding this comment.
Review 结论：LGTM (Approved) ✅
quay.io MinIO 镜像地址迁移，digest 保持不变，引用面穷举完整，20/20 CI 全绿，同意合并以解除阻塞。
## Problem and result Refs #211 (revision r2) and bytefolk/design-system#29. The Web client had faint light-theme labels, inconsistent control colors and broadly centered reading content. It now derives its palette from the shared design-system source and aligns content by purpose: names/forms/headings start-align, comparable numeric columns and trailing actions end-align, and button contents and complete empty states center. Narrow layouts keep controls reachable. ## Changes - Add a zero-dependency token generator using an unmodified, licensed snapshot of design-system commit `910456901dda74da4d5b0320cd03d36ad18650b0`; verify its SHA-256 and generated output before every Web build. Preserve alpha and derive readable foreground/solid-action pairs from those source hues. - Keep React 19 and existing primitives; add no runtime dependency or peer-range change. A local empty-state adapter follows the shared title/description/action scale. - Restore reading alignment across navigation, files, filters, forms, cards and dialogs; keep localized confirmation labels visible when omitted by callers. - Use a device-width viewport, wrap provider/detail actions, and keep permission tables locally scrollable on phones. Theme browser chrome follows computed tokens. - Update Unreleased changelog. API, routes, storage and authorization behavior are unchanged. ## Validation With locked dependencies (`cd web && npm ci`), `make test-web` passed: type/lint/build and the existing localization, theme, enrichment, memory, managed embedding and transfer acceptance. Unit tests: 7 files / 69 passed; root independently reran the 2 confirmation regressions. The token check verifies 334 generated/composited pairs at >=4.5:1. Actual browser acceptance captured 82 states across both themes at desktop and 390px touch-mobile widths, covering populated/empty views, dialogs, menus, file/memory/task details, providers, permissions and transfer. All 4,758 sampled visible-text pairs met the selected contrast threshold, with no JavaScript errors or unexpected document overflow. The mobile permission table was actually swiped to its trailing action and the confirmation opened. Root independently inspected the running Web client. A separate source/render review caught and verified the failed-thumbnail badge fix (9.23:1 light /10.14:1 dark). A further12 primary/danger/disabled normal+hover samples reached at least5.55:1; true touch scrolling also kept file-list names and numeric columns reachable. This is fixture-based UI acceptance: all API responses came from MSW; it is not a live-backend integration result. Private screenshots remain local. ## CI dependency and review status Keep this PR **Draft** until required current-head CI passes. The preceding head's HTTP/CLI/MCP lifecycle check failed before application tests because the pinned MinIO image could not be pulled from Docker Hub. The separate fix is #209 (issue #207); it is not copied into this UI diff. Other green checks do not waive that dependency. Current-head results must be read independently after this push. No deployment or formal human approval is included. Revert the scoped commits to roll back; no migration is required. ## Current-head hosted result All checks have finished on `7d941998167c4c6dadd27be348d9b96e1ec28e03`. The only failing check is [HTTP, CLI and MCP lifecycle](https://github.com/bytefolk/mem/actions/runs/35047528915/job/104640536818); all other check entries succeeded, including Web and Web memory/transfer acceptance. The failing job stops while starting isolated dependencies: `minio/minio` reports pull access denied before the application tests. This matches the separate registry fix in #209. The PR remains Draft pending that dependency and a fresh successful CI run. Totoro received the review bundle and explicit blocker status, with successful message delivery verified. This is a handoff, not formal approval.
2 participants
Summary
Resolves #207. Every MinIO image reference in this repository now resolves from
quay.ioinstead of Docker Hub. MinIO stopped publishing container images inOctober 2025 and removed the
minio/minioandminio/mcrepositories fromDocker Hub entirely, so every reference here is dead.
This is not a cosmetic dependency bump.
Validate Agent memory→HTTP, CLI and MCP lifecyclerequires thee2eCompose profile, andHTTP, CLI and MCP lifecycleis a required status context onmain. So theregistry withdrawal blocked every pull request in this repository from
merging — not just the ones touching this stack — and no contributor could do
anything about it.
The failure, verbatim
postgresreportsInterruptedin the same step only as a consequence; the jobdies during container startup, before any script under test is reached.
I confirmed the outage was still live before writing this PR by re-running the
failing job on the current head of #205
(run 34857342711,
attempt 4), which failed at
2026-09-15T05:52:24Zwith the identical error.The fix
quay.iostill serves the same images. Before changing anything I resolved bothdigests pinned in
docker-compose.test.ymlagainst quay.io:Both return their manifests, so no image bytes change. The digest-pinned
test stack keeps its exact digests, the release-tagged deployment stack keeps
its exact tags, and only the registry host differs. Same builds, different
registry.
Changed references
docker-compose.test.ymlminiominio/minio:latest@sha256:14cea493…quay.io/minio/minio:latest@sha256:14cea493…docker-compose.test.ymlminio-initminio/mc:latest@sha256:a7fe349e…quay.io/minio/mc:latest@sha256:a7fe349e…docker-compose.ymlminiominio/minio:latestquay.io/minio/minio:latestdocker-compose.ymlminio-initminio/mc:latestquay.io/minio/mc:latestdeploy/compose/compose.yamlminiominio/minio:RELEASE.2025-04-22T22-12-26Zquay.io/minio/minio:RELEASE.2025-04-22T22-12-26Zdeploy/compose/compose.yamlminio-initminio/mc:RELEASE.2025-04-16T18-13-26Zquay.io/minio/mc:RELEASE.2025-04-16T18-13-26Zdeploy/compose/compose.yamlminio-clientminio/mc:RELEASE.2025-04-16T18-13-26Zquay.io/minio/mc:RELEASE.2025-04-16T18-13-26ZWhy the non-CI files are in scope
docker-compose.ymlis the documented local development stack anddeploy/compose/compose.yamlis the documented self-hosted single-node path.Both reference the same removed repositories.
deploy/compose/compose.yamldeserves specific mention: no workflow exercisesit, so it would have kept a broken reference indefinitely and failed on a cold
host for an operator following
docs/DEPLOYMENT.md. Thedeploy/compose.env.example/backup.sh/restore.shfiles were checked and carry no imagereference of their own.
Deliberately not changed
The
pgvector/pgvectorreferences. That repository is still present on DockerHub, and the
PostgreSQL integrationjob — which pullspgvector/pgvector:pg16@sha256:00ba258a…straight from Docker Hub on the samerunner image at the same time — was green in all the runs that failed on
MinIO. That is the evidence that this is specific to the MinIO repositories
rather than general registry egress, and it is why the fix is scoped to MinIO
alone. See #207 for the full run-by-run comparison.
How this verifies itself
The failing job checks out the PR merge commit and runs
docker compose -f docker-compose.test.yml up -d --wait postgres minio, so onthis PR's own head it exercises the changed file directly.
HTTP, CLI and MCP lifecyclegoing green here is the proof, and it is also the precondition thatunblocks the rest of the queue.
Out of scope
minio/*dependency entirely (e.g. moving to SeaweedFS) — aseparate decision, and the Apache Flink project took that route while Apache
Doris took this one.
docker-compose.yml's floating:latesttags. Those are the localdevelopment stack,
scripts/validate_deploy.shonly rejects mutablelatestin the production deployment files (
deploy/,*/Dockerfile), and tighteningthem is unrelated to this outage.