Repository navigation
chore(dev): replace the MinIO image by pgsty/silo in the development and CI stacks (#7927) - #7928
Conversation
…and CI stacks (#7927) The upstream MinIO repository was archived and Docker Hub removed the minio/minio image; quay.io only carries frozen releases. Following OpenCTI-Platform/opencti#18239 the openaev-dev-minio and openaev-test-minio services now run pgsty/silo:latest, Silo being the community-maintained fork of the MinIO server (same S3 API, MINIO_* variables, server command, health route and on-disk format). Container names, ports, credentials, command and healthcheck are untouched, so the minio.* configuration keys and the CI actions (which read the image from the compose file) keep working. The documentation, the dev README, the Copilot instructions and the CI action descriptions now name Silo where they named MinIO as the object storage of the stack.
|
📖 Documentation check — ✅ Passed No functional source changes detected. |
There was a problem hiding this comment.
Pull request overview
Replaces the unavailable MinIO image with Silo while preserving S3 configuration, service names, ports, and health checks.
Changes:
- Updates development and CI object storage to
pgsty/silo:latest. - Refreshes deployment and development documentation.
- Updates CI descriptions and readiness messages.
Review findings:
docs/docs/deployment/platform/overview.md:59— Moderate (1 vote): production guidance should use a dated Silo release or scopelatestto development/CI.openaev-dev/docker-compose.yml:32— Moderate (1 vote): pin development and test images to verified immutable digests.openaev-dev/docker-compose.yml:116— Moderate (1 vote): pin the CI image to a verified immutable digest.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.
Show a summary per file
| File | Summary |
|---|---|
openaev-dev/README.md |
Documents Silo usage. |
openaev-dev/docker-compose.yml |
Uses Silo for development and test storage. |
docs/docs/development/environment-windows.md |
Updates Windows setup references. |
docs/docs/development/build-from-source.md |
Updates development dependency guidance. |
docs/docs/deployment/platform/overview.md |
Updates the dependency table. |
docs/docs/deployment/installation.md |
Updates installation documentation. |
.github/skills/activate-tenant-table/SKILL.md |
Updates service references. |
.github/copilot-instructions.md |
Updates repository service guidance. |
.github/actions/start-dev-services/action.yml |
Updates CI service descriptions. |
.github/actions/e2e-tests/action.yml |
Updates E2E readiness messages. |
.github/actions/api-types-check/action.yml |
Updates type-check readiness messages. |
.github/actions/api-tests/action.yml |
Updates API test readiness messages. |
Suppressed comments (3)
docs/docs/deployment/platform/overview.md:59
- issue (blocking): This table describes the dependencies required for production, so
latestmakes the supported Silo version non-reproducible and can silently change the storage server on a fresh deployment. Silo's own installation guidance recommends pinning a release for production; please use a dated Silo release here, or explicitly scopelatestto development/CI instead of presenting it as the recommended version.
| S3 / Silo | latest (Silo is a MinIO fork) | 1 core | ≥ 128MB | SSD | ≥ 16GB |
openaev-dev/docker-compose.yml:116
- issue (blocking):
start-dev-servicesderives the CI image from this service, sopgsty/silo:latestmakes every CI run depend on a mutable registry tag and can introduce an unreviewed server change or regression. Pin the CI image to a verified immutable digest instead oflatest.
image: pgsty/silo:latest
openaev-dev/docker-compose.yml:32
- issue (blocking):
latestis mutable, so the default development stack can silently switch to a different Silo build without any repository change, making local failures hard to reproduce. Pin this image to a verified immutable digest (or provide an explicit, reviewed update mechanism) rather than usinglatest; apply the same policy to the test service below.
image: pgsty/silo:latest
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
For the record, on the three suppressed Copilot remarks about |
Proposed changes
The
minio/minioimage can no longer be pulled: the upstream MinIO repository was archived on 24 April 2026 (the community edition is now source-only), and Docker Hub has since removed theminio/minioandminio/mcrepositories altogether - every tag answers 404 anddocker pullfails withpull access denied for minio/minio. Every fresh deployment or CI run of a stack that still references these images is broken today.Following OpenCTI-Platform/opencti#18239, the stack moves to Silo, the community-maintained fork of the MinIO server published by Pigsty (
pgsty/siloon Docker Hub, amd64 and arm64). Silo keeps the S3 API, theMINIO_*variables, theserver /data --console-addresscommand, the/minio/health/liveroute, the bundledmcclient (somc ready localhealthchecks keep working) and the on-disk format unchanged, so an existing data volume is reused as is.The
latesttag is used on purpose: the MinIO-style dated release tags are not tracked anymore, and the whole Filigran ecosystem is aligned onpgsty/silo:latest(andpgsty/mc:latestfor the client).openaev-dev/docker-compose.yml:openaev-dev-minio(10000/10001) andopenaev-test-minio(11000/11001) runpgsty/silo:latestinstead of the frozenquay.io/minio/minio:RELEASE.2025-06-13T11-33-47Z. Container names, ports,minioadmincredentials,server /data --console-address ":9001"command andcurl /minio/health/livehealthcheck are untouched, so theminio.*configuration keys keep working and.github/actions/start-dev-services(which reads the image from the compose file) starts the new image with no change.openaev-dev/README.md,docs/docs/deployment/installation.md,docs/docs/deployment/platform/overview.md,docs/docs/development/build-from-source.md,docs/docs/development/environment-windows.md: MinIO is named Silo where it is the object storage of the stack; the dependency table points at the Silo documentation and thelatesttag..github/copilot-instructions.md, the CI action descriptions / wait messages (api-tests,api-types-check,e2e-tests,start-dev-services) and theactivate-tenant-tableskill comment: same rename.minio.*/MINIO_*configuration keys, theminioservice names and the MinIO Java SDK dependency keep their names (the S3 protocol and the client are unchanged).Testing Instructions
cd openaev-dev && docker compose up -d openaev-dev-minio openaev-test-miniodocker compose psshows both containershealthy;curl -f http://localhost:10000/minio/health/liveandhttp://localhost:11000/minio/health/liveanswer 200; the console is on http://localhost:10001 (minioadmin/minioadmin).mvn test) or start the backend against the dev stack and upload a document: it lands in theopenaevbucket exactly as before. The CI actions on this PR run against the new image.Verified locally with Docker 29.6 on
pgsty/silo:RELEASE.2026-09-03T13-18-01Z(the currentlatest) with the exact compose settings of the stack: the container reacheshealthythroughmc ready local,/minio/health/liveand the console on 9001 answer 200, and a bucket create / upload / read round trip works withpgsty/mc. The image ships/usr/bin/mc,/usr/bin/mcliand/usr/bin/curl, so both healthcheck styles used across the Filigran stacks are supported.Related issues
Checklist
Further comments
The
latesttag is used on purpose: the dated MinIO-style release tags are not tracked anymore, and the whole Filigran ecosystem is aligned onpgsty/silo:latest(andpgsty/mc:latestfor the client). An existing localopenaev-dev-miniodata volume is reused as is (same on-disk format).