Currently, information about external Hub needs to be described in readme files under set up section. For example, you need to describe that to populate manifests from google/hub-manifests which depends on capactio/hub-manifests such command needs to be executed:
If you forget about --source github.com/capactio/hub-manifests it will not work properly. Instead of doing that, we can describe this relation inside google/hub-manifests repo using Vendor kind. CLI should automatically discover all Vendor manifests and based on them populate data from all additional sources.
Use cases
Content Developer - base on the Vendor kinds, knows which hubs are available. As a result, can consume already existing content like types, or provide new Implementation for already existing Interface.
System User - doesn't need to follow a special instruction for each Hub to set it up properly.
Out of scope
handle private Hubs
caching
support different sources, not only git or Public Hub API. We can try to reuse the same concept developed for the delegated storage.
content synchronization (periodic/hooks). Make it configurable.
Description
As the https://github.com/capactio/capact/issues/560 was done. We can now iterate with a new feature which will make use of Vendor kind.
It's a part of more complex issue about federation: https://github.com/capactio/capact/issues/511
Reason
Currently, information about external Hub needs to be described in readme files under set up section. For example, you need to describe that to populate manifests from
google/hub-manifestswhich depends oncapactio/hub-manifestssuch command needs to be executed:If you forget about
--source github.com/capactio/hub-manifestsit will not work properly. Instead of doing that, we can describe this relation insidegoogle/hub-manifestsrepo using Vendor kind. CLI should automatically discover all Vendor manifests and based on them populate data from all additional sources.Use cases
Out of scope