[...]
Ummm, really not what I was shooting for.
Rather the question is, why should BuildStream have any added
configuration, or any knowledge of "What a manifest is" at all ?
We need to provide ways to access and extract the data that you need,
there is no doubt about that; there are other requests already in queue
for these, and a solution needs to be thought out to better provide
introspection about sources and their refs; which probably need backing
support from Plugins to work at all.
For a project that wants to create some kind of post build summary, I
would expect them to do something like this, which took me all of 20
minutes to write:
https://gitlab.com/BuildStream/buildstream/snippets/1744606
In short, I think that given BuildStream should be very well
scriptable, any concept of a "manifest" in BuildStream proper is just
scope creep.
Can we please instead focus on the `bst artifact` command subgroup, and
ensure there is a proposal to allow similar introspection for Sources
in some way (maybe a `bst source-show` command or similar ?) - and in
this way, ensure that people have the tools they need to accomplish the
tasks they want to achieve ?
I actually still have a draft reply open to the artifact command subgroup :). I do think it makes sense to add something there to the effect you describe above.
Maybe
bst artifact origin <cachekey>
or
bst artifact genesis <cachekey>
Which would return enough information to know what went into producing the artifact. That would enable answering the question "For a given artifact, where did it come from?"
Is that in line with what you were thinking? Are you proposing to do mappings like this outside of BuildStream proper?
Cheers,
Sander
Cheers,
-Tristan
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
