Artifact field #280
Artifact field #280
Conversation
spec/tests/artifact.fmf
Outdated
| Test can produced artifacts as coverage data, junit summaries, | ||
| coredumps or other interesting data. By listing them in this attribute | ||
| execute steps collects them from the environemnt where test is running and saves | ||
| it to the run directory. |
There was a problem hiding this comment.
So this part is now already happenning: The test is executed in it's directory, as defined by path, and after test execution is completed workdir is pulled back from the guest using rsync. Do you propose some additinal processing?
There was a problem hiding this comment.
What if I store files outside of workdir?
Note that current test aren't supposed to create any content in their workdir.
Maybe we need rethink and, at least for beakerlib tests support rlFileSubmit
There was a problem hiding this comment.
Or let executor to "submit" files - beakerlib (and restraint) allow test tu submit file.
I'd like to have those file in 'artifacts' field.
So report plugin knows that something was submitted from the test.
The additional dictionary is to provide meaning to some files - Now I have xunit in mind, but let's make it dynamic.
So say there is junit: file in artifacts and I use report --how junit - plugin knows what files it should check for (parsing any file or arbitratry xml files doesn't seem good idea) and will process them.
|
I'll split this into two PRs. Artifact seems to need more discussion. |
|
Not planned as 'test' attribute. Might be part of 'result', depending on solution for issue 2108 |
Document duration as a possible result attribute
Document Artifact as possible test, and later result attribute