Repository navigation
feat: publish a v3 runtime feed that can list the image runtime - #11
Merged
Merged
Conversation
Runtime 0.9.1 and earlier reject the whole v2 feed for a runtime they do not know, so v2 stays frozen. v3 has the same entries plus the image runtime once its manifest is published. The v2 generator and verifier refuse any other runtime.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a second runtime feed at
v3/runtime/<channel>/runtime-release-feed.signed.json, next tov2. It uses the same schema, envelope and signing key. Runtime 0.10 readsv3and falls back tov2untilv3exists.v3has everythingv2has, plus the Nexus image runtime (images). The image entry is read fromruntime-manifest.jsonandchecksums.txtundermsty-nexus/runtime/images/on nexus-assets. The stable channel readslatest/and points at the versioned archive. The dev channel readslatest/dev/and pins that archive by SHA-256, the same way Apple Foundation Models does today. If the manifest returns 404, the image runtime is left out of that channel. Any other error fails the refresh.v2is not touched. Runtime 0.9.1 and earlier reject the whole feed for a runtime they do not know, so the v2 generator never asks for the image runtime, and the v2 validator, signer and verifier refuse a feed that lists it. The scripts take a feed version (default 2), and the refresh workflow now generates, signs, verifies and commits both paths. The first scheduled run creates thev3files. CI skipsv3until then.Testing:
node --test scripts/*.test.mjs(61 pass) and the Python bundle tests pass.publishedAtdiffers). The image manifests return 404 today on bothlatest/andlatest/dev/, so noimagesentry yet.images, v3 lists it when the manifest exists and omits it on 404, a bad manifest, a missing checksum and a non-404 error all fail, and the exact artifact fields.Two things to know. v2 dev already lists
foundationmodels, so the v2 allowlist is ollama, llamacpp, mlx, and foundationmodels on dev, as it is today. And the MLX feed code has no dev lane (both channels readmlx/latest/), so the dev rule for images follows the Foundation Models code instead.