You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem:
Currently 'consume' channels are required to put in the full entry of the other spec - this means duplication of schema refs, key location etc. ideally a reference approach ( some.other.domain._public.events: consume: etc) should be enough.
Implementation:
At runtime/parse-time, Specmesh will use the reference to complete/hydrate the spec using the reference. Of which itself will be publish to the same location/git etc (i.e. using git master as a registry)
Need to work out the story / workflow for validating multiple domains with specs in different repos.
For example, if I remove a public topic, or a grant on a protected topic, in one repo by mistake, the downstream domain need to detect this. Ideally, this is caught as early as possible... e.g. in the build pipeline.
Thoughts:
Maybe we can reference the upstream specs straight out of the main branch of GitHub?
Then users could have periodic builds (nightly or what ever) that check that no changes upstream has broken the current repo.
Later we'll want to think about how to toolify this so that the up stream repo user is notified when removing a topic / grant that still in use...
The text was updated successfully, but these errors were encountered:
Problem:
Currently 'consume' channels are required to put in the full entry of the other spec - this means duplication of schema refs, key location etc. ideally a reference approach ( some.other.domain._public.events: consume: etc) should be enough.
Implementation:
At runtime/parse-time, Specmesh will use the reference to complete/hydrate the spec using the reference. Of which itself will be publish to the same location/git etc (i.e. using git master as a registry)
Need to work out the story / workflow for validating multiple domains with specs in different repos.
For example, if I remove a public topic, or a grant on a protected topic, in one repo by mistake, the downstream domain need to detect this. Ideally, this is caught as early as possible... e.g. in the build pipeline.
Thoughts:
Maybe we can reference the upstream specs straight out of the main branch of GitHub?
Then users could have periodic builds (nightly or what ever) that check that no changes upstream has broken the current repo.
Later we'll want to think about how to toolify this so that the up stream repo user is notified when removing a topic / grant that still in use...
The text was updated successfully, but these errors were encountered: