-
Notifications
You must be signed in to change notification settings - Fork 141
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
add bundle validate, using reflect to check omitempty #4
Conversation
Signed-off-by: Liang Chenye <[email protected]>
logrus.Fatal(err) | ||
} else { | ||
if spec.Platform.OS != "linux" { | ||
logrus.Fatalf("Operation system '%s' of the bundle is not support yet.", spec.Platform.OS) |
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.
s/support/supported/
Signed-off-by: Liang Chenye <[email protected]>
Signed-off-by: Liang Chenye <[email protected]>
Signed-off-by: Liang Chenye <[email protected]>
Signed-off-by: Liang Chenye <[email protected]>
Signed-off-by: Liang Chenye <[email protected]>
Replace original validate.go with new one (bvalidate.go). @mrunalp @zenlinTechnofreak |
@liangchenye @mrunalp I think if we named bundle validation tool as validateCommand of ocitool, the only way to push runtime validation tool into the repo is to create a seperate main programme from ocitool, no matter it is a framework or not. If in that way, I should rebase my PR 'Add initial version of runtimetest command: #9' to a seperate tool, but not a sub command. What is your design in the ocitools repo? It should be nice if you can let me know. Thanks very much. |
@zenlinTechnofreak my opinion is we should provides three official sub-command in ocitools.
Other command/program/script like get-stage3.sh is important, but maybe suitable to put into a 'contrib' directory. @wking |
On Tue, Jan 26, 2016 at 02:23:16AM -0800, 梁辰晔 (Liang Chenye) wrote:
get-stage3.sh is certainly internal tooling and not part of this |
@liangchenye Yes, having these 3 commands makes sense. |
@liangchenye @zenlinTechnofreak @mrunalp @wking, a more command maybe needed: oci convert, which converts oci bundle to other container images(e.g. docker image or ACI image), any thoughts? |
On Tue, Jan 26, 2016 at 05:53:44PM -0800, Tiesheng wrote:
Conversions like that are going to be complicated and lossy (at least |
@ChengTiesheng I'll create a new PR to add 'contrib' directory. |
Signed-off-by: liangchenye <[email protected]>
Signed-off-by: liangchenye <[email protected]>
Use bundleValidateCommand (bvalidate) as the sub-command. @zenlinTechnofreak maybe you can use |
Signed-off-by: liangchenye <[email protected]>
add contrib directory and mv get-stage3 to that
Signed-off-by: liangchenye <[email protected]>
To verify the changes in opencontainers#4, I intentionally broke Diagnostic() by prefixing lines with "!" instead of "#" but the tests still passed. The spec[1] allows a test harness to silently ignore lines it doesn't understand, so that behavior makes sense. Red light green light testing[2] requires that our test be capable of failing if something is broken. This commit adds that by comparing the actual output against our expected output. Hat tip to @wking for suggesting to compare output[3]. 1: http://testanything.org/tap-version-13-specification.html#anything-else 2: http://stackoverflow.com/a/404860/174463 3: mndrix/tap-go#4 (comment)
Now that we have a function to generate diagnostic output, we don't have to construct it manually. See opencontainers#4
Now that we have a function to generate diagnostic output, we don't have to construct it manually. See opencontainers#4
To verify the changes in opencontainers#4, I intentionally broke Diagnostic() by prefixing lines with "!" instead of "#" but the tests still passed. The spec[1] allows a test harness to silently ignore lines it doesn't understand, so that behavior makes sense. Red light green light testing[2] requires that our test be capable of failing if something is broken. This commit adds that by comparing the actual output against our expected output. Hat tip to @wking for suggesting to compare output[3]. 1: http://testanything.org/tap-version-13-specification.html#anything-else 2: http://stackoverflow.com/a/404860/174463 3: mndrix/tap-go#4 (comment)
Now that we have a function to generate diagnostic output, we don't have to construct it manually. See opencontainers#4
Signed-off-by: Liang Chenye [email protected]
Based on previous PR (mrunalp/ocitools#10).
way to try it:
make a bundle 'testbundle for example' by ocitools generate & tar xzvf rootfs.tar.gz
ocitools bvalidate --path=testbundle
open it once spec version in Godeps updated with opencontainer/specs