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.

Sign up for GitHub

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

Jump to bottom

add bundle validate, using reflect to check omitempty #4

Closed
wants to merge 11 commits into from
Closed

add bundle validate, using reflect to check omitempty #4

wants to merge 11 commits into from

Conversation

liangchenye
Copy link
Member

Signed-off-by: Liang Chenye [email protected]

Based on previous PR (mrunalp/ocitools#10).

  1. correct rootfs reading problem
    way to try it:
    make a bundle 'testbundle for example' by ocitools generate & tar xzvf rootfs.tar.gz
    ocitools bvalidate --path=testbundle
  2. add 'reflect' to check 'omitempty' in spec/*go file
    open it once spec version in Godeps updated with opencontainer/specs

mrunalp
mrunalp reviewed Jan 22, 2016
View reviewed changes
bvalidate.go
logrus.Fatal(err)
} else {
if spec.Platform.OS != "linux" {
logrus.Fatalf("Operation system '%s' of the bundle is not support yet.", spec.Platform.OS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/support/supported/

@mrunalp mrunalp mentioned this pull request Jan 22, 2016
Merged
@liangchenye
Copy link
Member Author

Replace original validate.go with new one (bvalidate.go).

@mrunalp @zenlinTechnofreak
so runtimevalidate will not be a sub-command but a test framework, right?

@zenlint
Copy link
Contributor

zenlint commented Jan 25, 2016

@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.

@liangchenye
Copy link
Member Author

@zenlinTechnofreak my opinion is we should provides three official sub-command in ocitools.

  1. generate
    -- generate bundle according to user's input
  2. bundle validate
    -- validate if a bundle is valid
    once the 'layered' bundle released, more validating codes will needed.
  3. runtime validate
    -- validate if a runtime is valid
    pass all the test cases you provided.
    it is very similar to test_runtime.sh, the original requirement is Convert test_runtime.sh into a go program mrunalp/ocitools#8

Other command/program/script like get-stage3.sh is important, but maybe suitable to put into a 'contrib' directory. @wking

@wking
Copy link
Contributor

wking commented Jan 26, 2016

On Tue, Jan 26, 2016 at 02:23:16AM -0800, 梁辰晔 (Liang Chenye) wrote:

Other command/program/script like get-stage3.sh is important, but
maybe suitable to put into a 'contrib' directory. @wking

get-stage3.sh is certainly internal tooling and not part of this
package's public interface. Feel free to put it wherever you like ;).

@mrunalp
Copy link
Contributor

mrunalp commented Jan 26, 2016

@liangchenye Yes, having these 3 commands makes sense.

@ChengTiesheng
Copy link
Contributor

@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?

@wking
Copy link
Contributor

wking commented Jan 27, 2016

On Tue, Jan 26, 2016 at 05:53:44PM -0800, Tiesheng wrote:

oci convert, which converts oci bundle to other container
images(e.g. docker image or ACI image), any thoughts?

Conversions like that are going to be complicated and lossy (at least
in one direction, it seems unlikely that the feature sets are
identical for two tools). I'd rather keep conversion tools like that
in different repositories to cut down on noise in the
conformance-testing tool. But I agree that those tools will be
useful, so +1 to putting them under opencontainers/ if you can attract
enough OCI-member support for them.

@liangchenye
Copy link
Member Author

@ChengTiesheng I'll create a new PR to add 'contrib' directory.
The convert tools could be add to that directory.

@liangchenye liangchenye mentioned this pull request Jan 27, 2016
Merged
@liangchenye
Copy link
Member Author

Use bundleValidateCommand (bvalidate) as the sub-command.

@zenlinTechnofreak maybe you can use
runtimeValidateCommand(rvalidate) as another sub-command to do the runtime test.

@liangchenye
rename to rootfs-builder
607ee90 
Signed-off-by: liangchenye <[email protected]>
@wking wking mentioned this pull request Jan 29, 2016
Closed
Mrunal Patel and others added 2 commits February 5, 2016 10:54
Merge pull request #17 from liangchenye/contrib
0ad2df8 
add contrib directory and mv get-stage3 to that
@liangchenye
add bundle validate as sub-command
50ada03 
Signed-off-by: liangchenye <[email protected]>
@liangchenye liangchenye closed this Feb 5, 2016
@liangchenye liangchenye deleted the bundle branch February 5, 2016 09:40
@liangchenye liangchenye mentioned this pull request Feb 5, 2016
Merged
fmuyassarov pushed a commit to fmuyassarov/runtime-tools that referenced this pull request May 4, 2023
@mndrix
Explicitly test diagnostic output
1a7dac8 
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)
fmuyassarov pushed a commit to fmuyassarov/runtime-tools that referenced this pull request May 4, 2023
@mndrix
Use Diagnostic() inside Check()
53c5e22 
Now that we have a function to generate diagnostic output, we don't
have to construct it manually.

See opencontainers#4
fmuyassarov pushed a commit to fmuyassarov/runtime-tools that referenced this pull request May 4, 2023
@mndrix
Use Diagnostic() inside Check()
324f6e5 
Now that we have a function to generate diagnostic output, we don't
have to construct it manually.

See opencontainers#4
fmuyassarov pushed a commit to fmuyassarov/runtime-tools that referenced this pull request May 6, 2023
@mndrix
Explicitly test diagnostic output
76112da 
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)
fmuyassarov pushed a commit to fmuyassarov/runtime-tools that referenced this pull request May 6, 2023
@mndrix
Use Diagnostic() inside Check()
19f6898 
Now that we have a function to generate diagnostic output, we don't
have to construct it manually.

See opencontainers#4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@liangchenye @zenlint @wking @mrunalp @ChengTiesheng