ASSET-only change (zero-gravity/zerog.Dockerfile). No gitlink bump, no source change, no regeneration — the gitlink stays deploy-owned.
Problem 1 — the release tag cannot be hardcoded
0G publishes aristotle and galileo from two different repositories, and neither uses a consistent tag format. The asset filename is always <spec>-v<version>.tar.gz; only the tag varies. Probed live 2026-08-11:
chain
repo
version
actual tag
aristotle
0gchain-Aristotle
1.0.4
1.0.4
aristotle
0gchain-Aristotle
1.0.6
v1.0.6
galileo
0gchain-NG
3.0.3
v3.0.3
galileo
0gchain-NG
3.0.7
galileo-v3.0.7
galileo
0gchain-NG
3.0.8
v3.0.8
The old Dockerfile hardcoded download/${VER}/ for aristotle and download/v${VER}/ for galileo. Consequences:
aristotle could not be bumped past 1.0.4 — which matters now, because aristotle v1.0.6 carries a double-sign slashing fork (2026-06-26) that we are not on.
galileo could not reach 3.0.7 at all.
Fixed by resolving the tag: try the known forms in order, take the first that yields the asset.
Problem 2 — 404s failed silently, four layers later
curl -sL has no --fail, so a 404 HTML body was written into the .tar.gz and the build died at the next layer with:
tar: not in gzip format
An error that points nowhere near the cause. This has now caused three separate misdiagnoses:
the de-32 build blocker, when node_version: 3.0.3 was inherited by aristotle (3.0.3 exists in 0gchain-NG, not in 0gchain-Aristotle) — fixed by pinning 1.0.4 in vibe-node f3f7f23;
vibe-node PR #3087, which proposed aristotle 1.0.6 and would have reintroduced it;
vibe-node PR #3189, which proposed unifying both networks onto 0gchain-NG.
Now curl -fsSL, plus an explicit guard that names the version, the repo, and every tag tried.
Verification
Resolver logic run verbatim against the real GitHub artifacts:
--- versions that must work ---
✅ aristotle 1.0.4 -> resolved via tag '1.0.4'
✅ aristotle 1.0.6 -> resolved via tag 'v1.0.6'
✅ galileo 3.0.3 -> resolved via tag 'v3.0.3'
✅ galileo 3.0.7 -> resolved via tag 'galileo-v3.0.7'
✅ galileo 3.0.8 -> resolved via tag 'v3.0.8'
--- must fail loudly (regression guard) ---
❌ aristotle 3.0.3 -> FATAL: no asset 'aristotle-v3.0.3.tar.gz' in 0gfoundation/0gchain-Aristotle under any of: 3.0.3 v3.0.3 aristotle-v3.0.3
❌ galileo 9.9.9 -> FATAL: no asset 'galileo-v9.9.9.tar.gz' in 0gfoundation/0gchain-NG under any of: v9.9.9 galileo-v9.9.9 9.9.9
aristotle 3.0.3 is the exact input that caused the original blocker — it now fails in seconds with an actionable message instead of an opaque tar error.
Then end-to-end against the real 68 MB aristotle-v1.0.6.tar.gz (the previously-unreachable case), including the extraction step:
0g: trying tag '1.0.6' -> .../download/1.0.6/aristotle-v1.0.6.tar.gz
curl: (22) The requested URL returned error: 404
0g: trying tag 'v1.0.6' -> .../download/v1.0.6/aristotle-v1.0.6.tar.gz
0g: resolved aristotle 1.0.6 from tag 'v1.0.6'
✅ aristotle-v1.0.6/ present (tarball layout unchanged)
✅ bin/0gchaind (76M)
✅ bin/geth (46M)
The extraction branch and the chmod targets were checked explicitly, since the 1.0.6 layout had never been exercised.
⚠️Not built as a container image — no docker daemon on the controller. The download/extract path is verified against the real artifacts; the surrounding layers are unchanged from what already builds today.
Behaviour for current pins
Unchanged. aristotle 1.0.4 still resolves on the first candidate and galileo 3.0.3 on the first — no extra requests, no behaviour change, for anything pinned today.
Follow-up this unblocks
aristotle → 1.0.6 (the slashing fork) becomes a pure context.yml bump in vibe-node. Land this first — bumping the version before this Dockerfile is deployed would break the build.
vibe-node #2912 (galileo → 3.0.8 + restore chainid: 16602) is independent of this and unaffected.
Context: closed vibe-node #2865/#2967/#3086/#3087/#3145/#3171/#3189 during the 0g cluster triage; full evidence in vibe-node #2865.
**ASSET-only change** (`zero-gravity/zerog.Dockerfile`). No gitlink bump, no source change, no regeneration — the gitlink stays deploy-owned.
## Problem 1 — the release tag cannot be hardcoded
0G publishes aristotle and galileo from **two different repositories**, and neither uses a consistent tag format. The asset filename is always `<spec>-v<version>.tar.gz`; only the **tag** varies. Probed live 2026-08-11:
| chain | repo | version | actual tag |
|---|---|---|---|
| aristotle | `0gchain-Aristotle` | 1.0.4 | `1.0.4` |
| aristotle | `0gchain-Aristotle` | 1.0.6 | **`v1.0.6`** |
| galileo | `0gchain-NG` | 3.0.3 | `v3.0.3` |
| galileo | `0gchain-NG` | 3.0.7 | **`galileo-v3.0.7`** |
| galileo | `0gchain-NG` | 3.0.8 | `v3.0.8` |
The old Dockerfile hardcoded `download/${VER}/` for aristotle and `download/v${VER}/` for galileo. Consequences:
- **aristotle could not be bumped past 1.0.4** — which matters now, because aristotle v1.0.6 carries a double-sign **slashing fork** (2026-06-26) that we are not on.
- **galileo could not reach 3.0.7** at all.
Fixed by resolving the tag: try the known forms in order, take the first that yields the asset.
## Problem 2 — 404s failed silently, four layers later
`curl -sL` has no `--fail`, so a 404 HTML body was written into the `.tar.gz` and the build died at the *next* layer with:
```
tar: not in gzip format
```
An error that points nowhere near the cause. **This has now caused three separate misdiagnoses:**
1. the de-32 build blocker, when `node_version: 3.0.3` was inherited by aristotle (3.0.3 exists in `0gchain-NG`, not in `0gchain-Aristotle`) — fixed by pinning 1.0.4 in vibe-node f3f7f23;
2. vibe-node PR #3087, which proposed aristotle `1.0.6` and would have reintroduced it;
3. vibe-node PR #3189, which proposed unifying both networks onto `0gchain-NG`.
Now `curl -fsSL`, plus an explicit guard that names the version, the repo, and every tag tried.
## Verification
Resolver logic run verbatim against the **real** GitHub artifacts:
```
--- versions that must work ---
✅ aristotle 1.0.4 -> resolved via tag '1.0.4'
✅ aristotle 1.0.6 -> resolved via tag 'v1.0.6'
✅ galileo 3.0.3 -> resolved via tag 'v3.0.3'
✅ galileo 3.0.7 -> resolved via tag 'galileo-v3.0.7'
✅ galileo 3.0.8 -> resolved via tag 'v3.0.8'
--- must fail loudly (regression guard) ---
❌ aristotle 3.0.3 -> FATAL: no asset 'aristotle-v3.0.3.tar.gz' in 0gfoundation/0gchain-Aristotle under any of: 3.0.3 v3.0.3 aristotle-v3.0.3
❌ galileo 9.9.9 -> FATAL: no asset 'galileo-v9.9.9.tar.gz' in 0gfoundation/0gchain-NG under any of: v9.9.9 galileo-v9.9.9 9.9.9
```
`aristotle 3.0.3` is the exact input that caused the original blocker — it now fails in seconds with an actionable message instead of an opaque tar error.
Then end-to-end against the real 68 MB `aristotle-v1.0.6.tar.gz` (the previously-unreachable case), including the extraction step:
```
0g: trying tag '1.0.6' -> .../download/1.0.6/aristotle-v1.0.6.tar.gz
curl: (22) The requested URL returned error: 404
0g: trying tag 'v1.0.6' -> .../download/v1.0.6/aristotle-v1.0.6.tar.gz
0g: resolved aristotle 1.0.6 from tag 'v1.0.6'
✅ aristotle-v1.0.6/ present (tarball layout unchanged)
✅ bin/0gchaind (76M)
✅ bin/geth (46M)
```
The extraction branch and the `chmod` targets were checked explicitly, since the 1.0.6 layout had never been exercised.
⚠️ **Not built as a container image** — no docker daemon on the controller. The download/extract path is verified against the real artifacts; the surrounding layers are unchanged from what already builds today.
## Behaviour for current pins
Unchanged. `aristotle 1.0.4` still resolves on the **first** candidate and `galileo 3.0.3` on the first — no extra requests, no behaviour change, for anything pinned today.
## Follow-up this unblocks
- **aristotle → 1.0.6** (the slashing fork) becomes a pure `context.yml` bump in vibe-node. Land this first — bumping the version before this Dockerfile is deployed would break the build.
- vibe-node **#2912** (galileo → 3.0.8 + restore `chainid: 16602`) is independent of this and unaffected.
Context: closed vibe-node #2865/#2967/#3086/#3087/#3145/#3171/#3189 during the 0g cluster triage; full evidence in vibe-node #2865.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
0G publishes aristotle and galileo from two different repos, and neither uses a
consistent release-tag format. The asset filename is always <spec>-v<version>.tar.gz;
only the tag varies:
aristotle -> 0gchain-Aristotle 1.0.4 = "1.0.4" 1.0.6 = "v1.0.6"
galileo -> 0gchain-NG 3.0.3 = "v3.0.3" 3.0.7 = "galileo-v3.0.7" 3.0.8 = "v3.0.8"
The hardcoded formats meant aristotle could not go past 1.0.4 and galileo could not
reach 3.0.7. Resolve the tag by trying the known forms in order instead.
Also switch curl -sL to -fsSL. Without -f a 404 HTML body was written into the
.tar.gz and the build failed several layers later at 'tar: not in gzip format',
an error pointing nowhere near the cause. That has now caused three separate
misdiagnoses, including a de-32 build blocker.
Verified end-to-end against the real artifacts: aristotle 1.0.4/1.0.6 and galileo
3.0.3/3.0.7/3.0.8 all resolve; aristotle 3.0.3 and galileo 9.9.9 fail immediately
with an actionable message.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
claude
manually merged commit cfac32736e into main2026-08-11 06:23:54 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
ASSET-only change (
zero-gravity/zerog.Dockerfile). No gitlink bump, no source change, no regeneration — the gitlink stays deploy-owned.Problem 1 — the release tag cannot be hardcoded
0G publishes aristotle and galileo from two different repositories, and neither uses a consistent tag format. The asset filename is always
<spec>-v<version>.tar.gz; only the tag varies. Probed live 2026-08-11:0gchain-Aristotle1.0.40gchain-Aristotlev1.0.60gchain-NGv3.0.30gchain-NGgalileo-v3.0.70gchain-NGv3.0.8The old Dockerfile hardcoded
download/${VER}/for aristotle anddownload/v${VER}/for galileo. Consequences:Fixed by resolving the tag: try the known forms in order, take the first that yields the asset.
Problem 2 — 404s failed silently, four layers later
curl -sLhas no--fail, so a 404 HTML body was written into the.tar.gzand the build died at the next layer with:An error that points nowhere near the cause. This has now caused three separate misdiagnoses:
node_version: 3.0.3was inherited by aristotle (3.0.3 exists in0gchain-NG, not in0gchain-Aristotle) — fixed by pinning 1.0.4 in vibe-node f3f7f23;1.0.6and would have reintroduced it;0gchain-NG.Now
curl -fsSL, plus an explicit guard that names the version, the repo, and every tag tried.Verification
Resolver logic run verbatim against the real GitHub artifacts:
aristotle 3.0.3is the exact input that caused the original blocker — it now fails in seconds with an actionable message instead of an opaque tar error.Then end-to-end against the real 68 MB
aristotle-v1.0.6.tar.gz(the previously-unreachable case), including the extraction step:The extraction branch and the
chmodtargets were checked explicitly, since the 1.0.6 layout had never been exercised.⚠️ Not built as a container image — no docker daemon on the controller. The download/extract path is verified against the real artifacts; the surrounding layers are unchanged from what already builds today.
Behaviour for current pins
Unchanged.
aristotle 1.0.4still resolves on the first candidate andgalileo 3.0.3on the first — no extra requests, no behaviour change, for anything pinned today.Follow-up this unblocks
context.ymlbump in vibe-node. Land this first — bumping the version before this Dockerfile is deployed would break the build.chainid: 16602) is independent of this and unaffected.Context: closed vibe-node #2865/#2967/#3086/#3087/#3145/#3171/#3189 during the 0g cluster triage; full evidence in vibe-node #2865.
🤖 Generated with Claude Code