On Wed, 13 Jul 2016 14:47:10 +0000 "Albarran, Josue" <j-albar...@ti.com> wrote:
> Hi, > > Thanks for your help, I fixed it and now it works. > > I want to be able to run a script, have it return a value and have > LAVA detect pass or fail based on the output of the script. Depends on the output - the simplest way to set a pass or fail is to call lava-test-case directly and you can do that inside your script. (It's added to the PATH inside the test job.) Parsing patterns against script output gets difficult and hard to debug. You can do the parsing inside the script and call lava-test-case too: https://git.linaro.org/people/neil.williams/temp-functional-tests.git/blob/HEAD:/lava/dispatcher-branch-unit-tests.yaml calls https://git.linaro.org/people/neil.williams/temp-functional-tests.git/blob/HEAD:/lava/unittests.sh which does some parsing and then calls lava-test-case. This way, you can double-check your scripts against the output in the log files created within LAVA. > Would > something like this http://pastebin.ubuntu.com/19277125/ work inside > of the test action of the job definition? The subshell is entirely unnecessary, just use:. run: steps: - ./my-script.sh arguments To put that into the test job definition - the part you submit to LAVA - so it needs to be inline and you'd need a previous step which downloads or installs that script. run: deps: - wget steps: - wget http://example.com/my-script.sh - chmod 755 ./my-script.sh - ./my-script.sh arguments There are limitations on how complex these run steps can be, so a script is generally better than trying to combine shell commands with pipes and redirects. Inline is useful in development and will be recommended when using the synchronisation within multinode but a VCS like git is the best place for the actual test definitions. To ask LAVA to fetch & execute the test definition from git use something like: - test: timeout: minutes: 1 definitions: - repository: git://git.linaro.org/qa/test-definitions.git from: git path: ubuntu/smoke-tests-basic.yaml name: smoke-tests Distinguish between the job definition and the test definition. Inline tests live in the job definition but are limited compared to tests which live in the test definition. Test definitions benefit greatly from being in a VCS. For "important" tests, all of your results should come from a test definition hosted in a git repository. > If so, where should the > script be located in order for lava to find it? Use a git repo which can be cloned for you, then the script lives in the top level directory of the git repo or a path below that directory. > I read that currently > there is only support for Git and Inline, is this correct? There is bzr support but few people use it - git is the version control system to use. It is best to use a version control system so that you can track what changed in the test definitions themselves. V2 records the commit ID hash of the clone so that you can see exactly which version of the test definition was used. > This will help me understand the process so I can run functional LTP > tests in the future. There already are LTP definitions running for certain devices in LAVA. https://git.linaro.org/qa/test-definitions.git/blob/HEAD:/ubuntu/ltp.yaml That uses a git repo to provide a file in ./common/scripts/ which does most of the work but does rely on a parsing pattern. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp28h2C66tYB.pgp
Description: OpenPGP digital signature
_______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-validation
