Support fetching `fmf` metadata from a remote location

[kkaarreell]

When stored in the tmt root dir, main.fmf is the source of metadata that gets inherited by all child nodes. That suggests that it is a place where a common "configuration/setup" is stored. The downside is that this "common" setup is limited to a single git repository and it is not possible to re-use the same setup in a different repository - other than copying it.

It would be nice if one could load main.fmf from a remote location. Could be something similar to test plan imports. A user would clearly state that the content should be downloaded from a remote location which would happen prior further metadata processing.

Eventually, it won't be main.fmf node directly but its parent so one could still store adjustments in main.fmf.

Having something like an include would be even better (but more difficult to implement).

[psss]

Definitely sounds reasonable and useful. We should clarify at which level the import should happen. At the first sight it looks like pure fmf metadata should be fetched and incorporated into the fmf tree before tmt starts the validation and normalization?

[lukaszachy]

How about extending fmf's directives to have (eg)

/:
  fetch: URL_OF_FMF_FILE

[comps]

Maybe it would be then good to clarify how that's different from referencing remote fmf nodes, https://fmf.readthedocs.io/en/stable/concept.html#identifiers

[psss]

How about extending fmf's directives

That sounds like a great idea, I like that! It's close to inherit: false key which is already implemented there. I would just rather suggest to use the standard fmf identifier instead of a plain url. And, perhaps import would be a bit more appropriate name?

/:
    import:
        url: https://github.com/teemtee/tmt
        ref: main
        name: /common/prepare

Anyway, it seems we have a concensus that this functionality should rather go to fmf. @kkaarreell, would you agree here?

[kkaarreell]

So when using Fmf ditective, does it mean it would clone a repo, evaluate fmf metadata up to the level of a node identified by the name and then use those metadata for a parent node?

[kkaarreell]

I can imagine some more complex scenarios which would be possible.. I agree it would be a better fit fmf-wise.

[psss]

So when using Fmf ditective, does it mean it would clone a repo, evaluate fmf metadata up to the level of a node identified by the name and then use those metadata for a parent node?

Yes, that's what I would expect: Clone the repo, build the fmf tree, check the requested node specified by name and inject the node data into the current node as the starting point before applying inheritance.

I can imagine some more complex scenarios which would be possible.. I agree it would be a better fit fmf-wise.

Seems there is a clean concensus to cover that on the fmf side, moving the issue to the fmf repo.