Current desing suggests that the artifact for which given testset is relevant should be specified as part of the testset name. So for example build or pull-request would be defined this way:
artifact
build
pull-request
/ci/build/free-form-name /ci/pull-request/free-form-name /ci/build/free-form-name/or-even-more-structure
I was thinking a little bit more about this and I'm not completely sure it is a good idea. What if one would like to execute the same testset for three different (or even all available) artifacts?
Brainstorming: What about specifying artifacts under a dedicated attribute? It could look like this:
/freely/chosen/testset/name: summary: Basic smoke to be run for all builds and pull requests artifact: - build - pull-request execute: script: binary --help
If artifacts are not defined, testset would be executed against all. Thoughts?
artifacts
Metadata Update from @psss: - Issue tagged with: L2 Metadata
Hmm, I do not see the problem with this ... if we properly define the artifact types ... Seems more clear that putting it into the testcase name, that is for sure!
@happz what do you think about this proposal?
So an example with gating would look like this?
/freely/chosen/testset/name: summary: Basic smoke to be run for all builds and pull requests artifact: - build - pull-request gate: - merge-pull-request - add-build-to-update - add-build-to-compose execute: script: binary --help
Looks good to me, both artifacts and gates are specified in the same way, that's good.
Yes, exactly. Brings a bit of freedom to the testset name and a bit of consistency with gating config.
One more question: Should the attribute name be artifact or artifacts? If multiple artifacts are expected, we should probably go with plural. The same applies to gate versus gates. Thoughts?
gate
gates
Already included in the tmt specification: https://tmt.readthedocs.io/en/latest/spec/plans.html#artifact
Metadata Update from @psss: - Issue status updated to: Closed (was: Open)