ONE
ONE copied to clipboard
Samsung
[onecc-docker] Add test directory
This commit adds test directory.
The test directory helps to test onecc-docker command line tool by installing prepare_test_materials.sh script and generating runtestall.sh script automatically.
ONE-DCO-1.0.-Signed-off-by: Dongwan Kim [email protected]
Co-authored-by: seunghui-lee [email protected] Co-authored-by: Junsu Kim [email protected]
draft : #9731 issue: https://github.com/Samsung/ONE/issues/9712
Umm..
@jyoungyun I think installing tests on the same place with one-cmds causes conflicts.
I've looked in #9731 but could not find any .test nor .cfg files. Can you please share about the tests?
- what to test
- how to test
@seanshpark
I've looked in #9731 but could not find any .test nor .cfg files. Can you please share about the tests?
- what to test
- how to test
First, we add the PR that constitutes the test enviornment of onecc-docker, and then the test files will be added soon.
This will test the following:
- input argument (maybe token ?)
- whether to call
oneccwell - whether to build the docker image well
How to test?
- Use
runtestall.shscript.
I'm sorry for the answer that SSAFY teams have to do....
@jyoungyun please understand me that it would be better to provide by draft codes not in written words for this so I could test or see the test results. I'm conserned about (1) duration with the test (2) will work in CI (3) will work in internal setup CI. If SSAFY members can't prepare actual test codes in this period, it's OK. But I don't want to land current code without seeing actual test codes.
@seanshpark
please understand me that it would be better to provide by draft codes not in written words for this so I could test or see the test results. I'm conserned about (1) duration with the test (2) will work in CI (3) will work in internal setup CI. If SSAFY members can't prepare actual test codes in this period, it's OK. But I don't want to land current code without seeing actual test codes.
Oh, I understand your thought. Actually there is no test code yet. But the test environment will be needed someday, so I thought it is good to put this code first. There is not many testcodes to test onecc-docker. Therefore, I thought that the SAFFY team would be able to complete it within this period, and that implementing test rather than simply creating script would be a better experience.
What about implementing the test code first on the draft PR, then add the environment and add tc?
What about implementing the test code first on the draft PR, then add the environment and add tc?
That would be great :)
@seanshpark
@Samsung/ootpg_docker team adds test case for onecc-docker. Currently, the argparse is not processed, so it is tested only if onecc-docker executes onecc well. After supported argparser, they will add more test case for verifying the input parameters. :)
@holawan Please create a new PR for configuring the test environments.
@jyoungyun can you please add a comment of how long this test takes ?
from @seanshpark https://github.com/Samsung/ONE/pull/9793#issuecomment-1257645117
I had a short offline discussion with @jyoungyun and have some concerns of this change
- our CI is running in Jenkins inside Docker. That is building and running Docker inside a Docker. Technically I think this is possible but not sure currently it is within our CI
- how long would it take of running test? current codes don't run the test. I didn't check the draft yet.
- I think we need some policy about the changes
Thus I don't want to land this PR as of now but after some on-line discussion with an issue.
from @seanshpark https://github.com/Samsung/ONE/pull/9793#issuecomment-1257667715
@jyoungyun
In the process of testing onecc-docker, we want to verify that the docker image was created successfully by adding a test file.
Currently, the image name we generate is imported using the Github API to create an image with the latest version name.
For example, onecc:1.21.0
However, it is not clear to statically declare the version 1.21.0 in the test file.
So, I'm wondering if I should bring Github API in the test process, or if we should specify onecc:latest when we create an image (because we don't consider the ONE version at this time)
I'd appreciate it if you could give me your opinion.
@holawan
In the process of testing onecc-docker, we want to verify that the docker image was created successfully by adding a test file.
Currently, the image name we generate is imported using the Github API to create an image with the latest version name. For example, onecc:1.21.0
However, it is not clear to statically declare the version 1.21.0 in the test file.
So, I'm wondering if I should bring Github API in the test process, or if we should specify onecc:latest when we create an image (because we don't consider the ONE version at this time)
How about just checking the image name? I think it's better to specify a specific version clearly than latest.