-
Notifications
You must be signed in to change notification settings - Fork 676
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
oci-image-tool: initial cut #65
Conversation
gojsonschema: upstream PR xeipuuv/gojsonschema#101 |
6cf4824
to
59fddf8
Compare
@@ -62,9 +62,18 @@ oci-validate-json: validate.go | |||
oci-validate-examples: cmd/oci-validate-examples/main.go | |||
go build ./cmd/oci-validate-examples |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can replace this once you get validation done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. This tool extracts the examples from the spec for validation. Do we intend to replace the markdown extraction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking of moving the markdown extraction to a markdown_test.go invocable via go test
and not have a separate binary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds great. I am not sure why I didn't do that initially.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also removed oci-validate-json
since it is being replaced by oci-image-tool
93c5e52
to
8cfb5d5
Compare
@stevvooe can it be you mentioned to have manifest examples I can validate against? It'd be great to get those. |
@s-urbaniak They are extracted directly from the specification by |
|
||
// withFile opens the named file for reading and executes the given function fn if no error occured. | ||
// If the given function returns an error it will be returned. | ||
func withFile(name string, fn func(f io.Reader) error) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an odd pattern for Go. Just open the file in validatePath
. withFile
isn't used anywhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, removed it, we're validating files right now only anyways.
471b4a8
to
e768f02
Compare
@stevvooe OK, I was assuming you have more samples, nevermind. As mentioned above I'll try to migrate the functionality of |
Sorry about that. I think the idea is that we would add these variations to specification to introduce them in context.
Yep. I think you can port this almost directly. Most of |
4eeb12c
to
d287023
Compare
func main() { | ||
flag.Parse() | ||
func TestSpecExamples(t *testing.T) { | ||
m, err := os.Open("../manifest.md") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's throw a TODO here to have this encompass all specification files.
CooI! I think it might to have this feature in /~https://github.com/opencontainers/ocitools,
What do you think? @s-urbaniak @mrunalp @philips |
|
||
// ManifestValidator wraps a media type string identifier | ||
// and implements validation against a JSON schema. | ||
type ManifestValidator string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nit: these won't always be "manifests".
@liangchenye right, @s-urbaniak please don't worry about validating the ondisk format. We can rely on the oci-runtime-tool for that. |
@s-urbaniak can we merge the tool as-is and do a follow-up PR? Essentially just add the dependencies and then we can do followup PRs for each of the remaining featrues? |
@philips sure, we can mere as is! Let me squash all of this in a sec. I working on an unpacker now. What do you mean with "Essentially just add the dependencies"? Do you mean vendoring the deps? |
This adds the oci-image-tool with the following capabilities: - validate manifest - validate manifest list Signed-off-by: Sergiusz Urbaniak <sur@coreos.com>
@philips squashed, ready to merge once green |
LGTM, can you file individual issues for the remaining things? |
LGTM I have no problems with merging this PR, but let's make sure to get a few more LGTMs in the future. |
This was a bigger kick off of work, but so far we've been merging with one, On Thu, May 19, 2016, 17:30 Stephen Day notifications@github.com wrote:
|
This is work in progress for the oci-image-tool, current TODOs:
http.FileSystem
. I am implemented support forhttp.FileSystem
in gojsonschema now.Validate configfollow-up oci-image-tool: Implement config validation #74Validate unpacked image layout on diskfollow-up oci-image-tool: validate and unpack image #75Validate compressed imagefollow-up oci-image-tool: validate and unpack image #75Unpack imagefollow-up oci-image-tool: validate and unpack image #75Introduce vendored dependenciesfollow-up oci-image-tool: vendor dependencies #76rethink build systemfollow-up oci-image-tool: vendor dependencies #76