-
Notifications
You must be signed in to change notification settings - Fork 85
Open
Description
I've been plugging TAP in passing for a while now, so here it is as its own issue. I think we want validate output like:
TAP version 13
ok 1 - v1.0 recognized media type: …manifest.v1+json
ok 2 - v1.0 fetched sha256-a…
ok 3 - sha256-a… has the expected media type
… other local manifest checks, I won't bother counting …
ok 4 - sha256-a… config has a legal media type: …config.v1+json
ok 5 - sha256-a… layers[0] has a recognized media type: …layer.tar+gzip
not ok 6 - sha256-a… layers[1] has a inappropriate media type: …config.v1+json not in […layer.tar+gzip]
ok 7 # skip sha256-a… layers[2] has an unknown media type: image/png
ok 8 - sha256-a… config fetched sha256-b…
… other local config checks, I won't bother counting …
ok 9 - fetched sha256-c…
… other local layer checks, I won't bother counting …
ok 10 - v2.0 recognized media type: …manifest.v1+json
ok 11 - v2.0 fetched sha256-e…
ok 12 - sha256-e… has the expected media type
not ok 13 - sha256-e… config has an illegal media type: image/png not in […config.v1+json]
… other sha256-e… and children checks, I won't bother counting …
ok 14 # skip cover unknown media type: image/png
1..14
Besides giving us a convenient place for warnings (under a # skip), this lets us be nice and granular with our pass/fail messages. Users can use an off-the-shelf TAP consumer to manage the volume. I've mocked up a bit of this using tap-go (previously tap.go) in 4f0b3c1 if folks want to look around. If this sounds like a useful approach, I'm happy to file PRs, although the approach I've mocked up will work better once #5 and opencontainers/image-spec#403 have landed.
Metadata
Metadata
Assignees
Labels
No labels