Clarify the trigger context dimension values

[psss]

Provide a bit more precise definitions of the commit and build trigger values, especially to make it clear that build could be used for the event of promoting draft builds as well.

Related issue: https://issues.redhat.com/browse/OSCI-4586

Pull Request Checklist

• update the specification

[LecrisUT]

Regarding these sections, it would be good to mention who is meant to be implementing these context values. E.g. distro can be a confusing one because after provision, you expect tmt to know what environment it is in, particularly as it is being used to process prepare.install

[happz]

FWIW, I'm not even sure the list of trigger values belongs in tmt documentation.

"The trigger dimension supports the following values" - well, it supports way more values, right? Any string can be a value of the trigger dimension, depending on whoever runs tmt. If I choose to use a string not listed here, tmt will not crash. The same goes for "Supported context dimensions". The dimensions and values listed in this document have meaning just and only among the CI systems our community controls and manages. For tmt,all these values are opaque, evaluated by fmf, dimensions, and values are taken from fmf files and matched against when conditions, and that's it.

In my world, this would be something that belongs to the document "RH & Fedora CI systems", chapter "These are the dimensions RH & Fedora CI systems set for your tmt plans and tests". It'd be nice to have a big rubber stamp on top of such a document, "tmt developers approve this list, these are the dimensions we think are useful and valuable", but I for one don't see it as something tmt itself should define for every possible user out there.

That said, if I'm not mistaken, we don't have a document like that, therefore I approved the improvement, but it might be something to consider during your documentation focus, @psss? :)

[kkaarreell]

In my world, this would be something that belongs to the document "RH & Fedora CI systems", chapter "These are the dimensions RH & Fedora CI systems set for your tmt plans and tests". It'd be nice to have a big rubber stamp on top of such a document, "tmt developers approve this list, these are the dimensions we think are useful and valuable", but I for one don't see it as something tmt itself should define for every possible user out there.

Exactly, on tmt side it could be a recommendation at best and it should be implemented and documented on the CI system side.

[psss]

Yeah, these are very good points. Perhaps, on the tmt side we could have just an outline of the meaning, an overal direction how this could/should be used, but the exact definitions should go to the pipe docs, completely agreed.

[psss]

Regarding these sections, it would be good to mention who is meant to be implementing these context values.

I think this is (at least partially) covered at the beginning of the Context section:

The context is usually defined from the command line using the --context option. All dimensions are optional. It is possible to define your own dimensions to describe the context, just make sure the dimension name does not conflict with reserved names.

Each plan can also provide its own context. The context definition provided directly on the command line overrides defined dimensions. All context dimension values are handled in case-insensitive way.

So far there is no auto-detection from the provision step.

[happz]

Changes specification and docs only, merging without functional tests.