tmt_id and tooling around

[sopos]

We are gonna introduce the id (uuid) of the fmf nodes. Such id should be path-agnostic within the git repo but furthermore it could be also repo-agnostic with help of a central registry.

For that purpose I propose to call it the _tmtid. The purpose of such _tmtid is basically to be able to translate it into the _fmfid which points to an existing fmf node.

Following would be the possible forms of the references of:

• an _fmfid inside a git repo

  url: https://..
  id: f20f2608-d048-11ec-87f3-c72d591e53dd

• an _fmfid stored in a specific key-value store

  db: http://...
  id: f20f2608-d048-11ec-87f3-c72d591e53dd

• an _fmfid stored in a central registry configured in the tmt configuration

  id: f20f2608-d048-11ec-87f3-c72d591e53dd

  The last two are basically the same except where the db information comes from.

Such id-only references could be then easily used in the ReportPortal, Polarion, Jira, Bugzilla, ...

Scope:

• [x] MUST: to create an _tmtid spec in tmt (covered with id)
• [ ] MUST: to create another project under https://github.com/teemtee/ which would cover the DB (maybe just an ansible playbook) this could be extended in the future to hold complete metadata of the fmf nodes to act as an web presentation layer
• [ ] MUST: a way to get the data to the DB
  • SHOULD: to teach tmt to export the data to the key-value store (tmt tests export --how DB)
  • COULD: the DB fetches the data regularly on its own based on a configured list of monitored repos
• [ ] WOULD: to teach tmt to use such id as a require or recommend (e.g. for beakerlib libraries)

Let's discuss it and polish the scope.

[psss]

Thanks for outlining the solution! Sounds good and proposes a nice answer to the question shared on the hacking session:

How to represent test case ID in a form of a URL (for future Jira linking)?

If there would be a central database available at a known location the url could look simply like this:

• https://tmt.db.org/f20f2608-d048-11ec-87f3-c72d591e53dd

A simple caching server could provide a nice web page with details about the tmt object (test, plan or story) including links to the git repository web interface to allow users to quickly check the source code. Plus a machine readable format could be provided as well, for example:

• https://tmt.db.org/f20f2608-d048-11ec-87f3-c72d591e53dd.yaml

@kkaarreell, what do you think?

[sopos]

I just updated the scope with priorities proposal

[kkaarreell]

I am not sure about the central DB reference. For test case URL I would prefer something not dependent on the presence of the actual DB. E.g. something like http://path/to/repo?ref=REF&name=/name/of/test, even though it would be artificial.

Regarding the caching DB itself, I think it should not only rely on a case ID but it should be able to work also with repo, ref, testname in some form since not all tests in a monitored repo have to have ID assigned. Ideally, it would find testcase using both the ID and using the other reference (e.g. in a form of URL mentioned above).

[psss]

I think it should not only rely on a case ID but it should be able to work also with repo, ref, testname in some form since not all tests in a monitored repo have to have ID assigned. Ideally, it would find testcase using both the ID and using the other reference (e.g. in a form of URL mentioned above).

Agreed, it should be possible to look for a test case using both/all available identifiers.

[jharuda]

How about separating this feature into a centralized database and a one-liner for specifying fmf-id?

one-liner: http://path/to/repo?ref=REF&path=/path/of/&name=/name/of/test

[kkaarreell]

I have just filed related RFE https://github.com/teemtee/tmt/issues/2445