feat(pkg-cache): add the hex ecosystem #112

Merged
binjovi-bot merged 1 commit from feat/pkg-cache-hex into trunk 2026-09-01 07:17:17 +00:00
Owner

Hex is the last unmanaged language upstream in the fleet: builds fetch straight from repo.hex.pm with zero HEX_* config anywhere. It also needs the least machinery of any ecosystem — immutable tarballs behind one registry, ed25519-signed metadata, outer checksums pinned in mix.lock — so the client's native HEX_MIRROR support is satisfied by pkg-cache's existing pull-through shape. This is the next step on the roadmap recorded in cilium/buildkitd-networkpolicy.yaml: route every remaining upstream through pkg-cache/zot/athens.

Changes:

  • Two eco map entries (the documented extension point): hex -> repo.hex.pm, base "".
  • A dedicated location for hex's mutable signed registry resources (/names, /versions, /packages/NAME, /installs/*). These live at bare paths TIER 1's slash-anchored filename regex cannot match; without this they would land in TIER 2's 30-day tier and mix hex.audit would miss new package retirements for up to a month. Same 1m+revalidate semantics as TIER 1. Tarballs and /public_key correctly take the generic immutable tier.
  • config-rev 2 -> 3 (subPath mounts do not hot-reload).
  • binjovi's buildkit-world profile gains pkg-cache:8080 egress, cloned from its athens rule (toEntities: world does not cover in-cluster endpoints).

Inert until a consumer passes HEX_MIRROR; the binjovi-side wiring (ARG in its Dockerfile plus a build-args param in its Shipwright executor) follows as a separate binjovi PR once this is live. tests/binjovi-argo-execution.sh passes; both touched kustomizations build clean.

https://claude.ai/code/session_01LeVatedQ4sCA1u6LHjo7B5

Hex is the last unmanaged language upstream in the fleet: builds fetch straight from repo.hex.pm with zero HEX_* config anywhere. It also needs the least machinery of any ecosystem — immutable tarballs behind one registry, ed25519-signed metadata, outer checksums pinned in mix.lock — so the client's native HEX_MIRROR support is satisfied by pkg-cache's existing pull-through shape. This is the next step on the roadmap recorded in cilium/buildkitd-networkpolicy.yaml: route every remaining upstream through pkg-cache/zot/athens. Changes: - Two eco map entries (the documented extension point): hex -> repo.hex.pm, base "". - A dedicated location for hex's mutable signed registry resources (/names, /versions, /packages/NAME, /installs/*). These live at bare paths TIER 1's slash-anchored filename regex cannot match; without this they would land in TIER 2's 30-day tier and mix hex.audit would miss new package retirements for up to a month. Same 1m+revalidate semantics as TIER 1. Tarballs and /public_key correctly take the generic immutable tier. - config-rev 2 -> 3 (subPath mounts do not hot-reload). - binjovi's buildkit-world profile gains pkg-cache:8080 egress, cloned from its athens rule (toEntities: world does not cover in-cluster endpoints). Inert until a consumer passes HEX_MIRROR; the binjovi-side wiring (ARG in its Dockerfile plus a build-args param in its Shipwright executor) follows as a separate binjovi PR once this is live. tests/binjovi-argo-execution.sh passes; both touched kustomizations build clean. https://claude.ai/code/session_01LeVatedQ4sCA1u6LHjo7B5
feat(pkg-cache): add the hex ecosystem
All checks were successful
binjovi/ci Binjovi completed the frozen plan
4a9c6f2d53
Hex needs no Athens-style middleware: packages are immutable tarballs
behind one registry, metadata is ed25519-signed, and mix.lock pins outer
checksums, so a dumb pull-through satisfies the client's HEX_MIRROR
support. The mutable registry resources live at bare paths that TIER 1
cannot match, so a dedicated short-TTL location keeps mix hex.audit
retirement data fresh instead of caching it for 30 days.

The binjovi buildkit-world profile gains pkg-cache egress, cloned from
its athens rule. Inert until a build passes HEX_MIRROR.

Claude-Session: https://claude.ai/code/session_01LeVatedQ4sCA1u6LHjo7B5
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
sean/seanfarm!112
No description provided.