spinframework / spinframework/spin
Registry metadata support in application manifest
@vdice is already working on this.
Since Sep 8, 2025.
- Dominant language
- Rust
- Stars
- 6.5k
- Forks
- 310
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 24
Description
The topic of registry metadata support in the Spin application manifest has come up a few times, most recently via https://github.com/fermyon/spin/issues/2612 where it was mentioned that declaration of annotations in the manifest itself could be useful, in addition to or as defaults for those that may be specified via the CLI at time of spin registry push.
Initial brainstorm
The conversation in #2612 provoked a quick initial brainstorm that perhaps a top-level [registry] section could be a good way to go. In addition to a [registry.annotations] section, the section could include other relevant metadata, such as:
nameof registry, egghcr.io/vdiceimage(OCI image/artifact name, defaulting to application name but could be overridden here, egmyapp)tag(image tag, defaulting to application version, but could be overridden here, eglatest).
All together, the following would be an envisioned example:
[registry]
name = "ghcr.io/vdice"
image = "myapp"
version = "latest"
[registry.annotations]
"org.opencontainers.image.url" = "https://www.example.com"
(Note, annotation keys including .'s would need to be quoted.)
In this example, CLI support would be added such that spin registry push would just work, with no need to supply a <REFERENCE>. (Though, if/when supplied, it would take precedence.) Instead, the defaults declared in the manifest would be used. In this case, the default reference published would be ghcr.io/vdice/myapp:latest.
(TBD the CLI behavior when a full default reference cannot be derived from the manifest, for example if registry is missing but image and version are present, and when no <REFERENCE> is supplied at time of command invocation.)
Open questions
-
First, is this general approach something we'd like to pursue? If so, a SIP might be a preferred first action item from this issue.
-
What other metadata or sub-sections might we envision under
[registry]? -
Web Assembly Component Registry interactions?
How would this design interact with a Web Assembly component registry? All of the above assumes the underlying registry is an OCI registry and the resulting image/artifact is an opinionated (read: customized OCI manifest layout and push/pull protocol) Spin app. (Conveniently, for the former, it currently looks like wasm component registries also use OCI registries under the hood.) What if Spin application authors would also (or instead) like to publish just the wasm component to a dedicated wasm component registry? Ref https://github.com/fermyon/spin/issues/2536 and a bit more tangentially, https://github.com/fermyon/spin/issues/1182.
My first hunch would be that all of the metadata supplied in
[registry]would apply to the published wasm component(s) as well, unless somehow specified otherwise. Unless we think of any design-altering items now, perhaps we're okay to relegate the specifics to the implementor of #2536.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.