Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metadata for WASI OCI artifacts #608

Open
yoshuawuyts opened this issue Jun 14, 2024 · 2 comments
Open

Metadata for WASI OCI artifacts #608

yoshuawuyts opened this issue Jun 14, 2024 · 2 comments

Comments

@yoshuawuyts
Copy link
Member

I was looking today at the WASI OCI images we're publishing, and I noticed we're not yet making use of all of the capabilities ghcr has to offer. For example, the individual images we're publishing don't include descriptions or license data.

GitHub currently renders the following annotations, but even more annotations exist. If we applied what GitHub currently supports, we'd be adding the following keys to the Wasm OCI Artifact Layout:

"annotations": {
   "org.opencontainers.image.description": "<description>",
   "org.opencontainers.image.source": "https://github.com/webassembly/<package>",
   "org.opencontainers.image.licenses": "<spdx license>"
}

Given the annotations section just covers metadata, and not anything else, maybe we should just reuse these? Unless there are plans to create our metadata specific to Wasm Components encoded as OCI Artifacts?

@ricochet
Copy link
Contributor

Yes, we should definitely fill these in. I manually set the source repo label for all of these.

For the license, we should set the SPDX ID as Apache-2.0 WITH LLVM-exception. The WASI effort is under the W3C CLA, however we release software artifacts in the wasi-sdk with Apache-2.0 WITH LLVM-exception.

@ricochet
Copy link
Contributor

ricochet commented Aug 7, 2024

With the WASI 0.2.1 release, we now have these set for all WIT packages pushed to OCI. Check them out here: https://github.com/WebAssembly/WASI/releases/tag/v0.2.1

We set these on the oci push, here is an example for wasi:io

cd preview2/io
wit build

export WASI_DESC="Wasi I/O is an API providing I/O stream abstractions. There are two types, input-stream, and output-stream, which support read and write, respectively, as well as a number of utility functions."
export WASI_PACK="io"

wkg oci push "ghcr.io/webassembly/wasi/$WASI_PACK:0.2.1" \
    --annotation "org.opencontainers.image.description"=$WASI_DESC \
    --annotation "org.opencontainers.image.source"="https://github.com/webassembly/wasi" \
    --annotation "org.opencontainers.image.url"="https://wasi.dev" \
    --annotation "org.opencontainers.image.version"="0.2.1" \
    --annotation "org.opencontainers.image.licenses"="Apache-2.0 WITH LLVM-exception"

# to validate:
wkg oci pull "ghcr.io/webassembly/wasi/io:0.2.1"
wasm-tools component wit webassembly_wasi_io.wasm

From an automation perspective, the following process once we have it, will simplify this:

  1. Capture registry metadata with wit build. There's some of this in place today in wasm-tools, but this isn't integrated through to the wit tool yet.
  2. Then when running wkg oci push, I shouldn't have to set the annotations because the .wasm is parsed, the relevant custom sections read, and then the annotations are set automatically. This allows us to cast from a .wasm to OCI and back again.

Establishing this convention is tracked in WebAssembly/tool-conventions#230

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants