-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorporate Adapter Version # at buildtime #25
Comments
I think adding a new proto functions is a good solution. Maybe we could add a more general function, like The function call can be handled in In the adapters, the Any more general functionality should go into |
Of course, it should be |
@mgfeller, you're right that there is an argument for inclusion of this component-version-reporting functionality to land in MeshKit. For example, consider this mockup: If you have motioned to move this enhancement to |
Hmm... I might have mentioned something related to that before (but can't find the conversation). The individual components will expose this information. For adapters, this means implementing it (also) as a function in the gRPC service, in How are other components exposing information about themselves? Client functionality could of course be implemented in A Could |
@mgfeller, good call. @uds5501 the |
@leecalcote @uds5501 yes, I thought something along those lines, but more fields, or a map, or a composed message. This is controller info, though, not component. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Sounds good to me, @mgfeller |
Issue to expand meshops.proto meshery/meshery#2449, needs to be implemented first. |
Looks like it would be preferable to merge #34 first. |
Quick check... this component version information is now coming through and is available to Meshery Server, correct? If so, it's time for an issue to expose this in Meshery UI. Excited about this one. 😄 |
I'll check the status on this one. And create a Meshery UI issue if it doesn't exist and hasn't been implemented. // @leecalcote |
// @leecalcote
|
Progress. @mgfeller, in a non-obvious way, we've begun to expose some of this in the UI and show to the user on hover of an adapter chip. We need to do more in this regard; need a separate Meshery System Dashboard. @ramrodo, heads-up: we might not be including build information in each of the Meshery Adapter build workflows, at least not for OSM, NSM, Consul, CPX. It should be the case that we can propagate workflow updates to include version and tag into these adapter repos with relatively little pain. |
For meshery-nsm see meshery/meshery-nsm#124 |
I suggest this general issue can be closed now - and will be if no-one objects within a few days or so. // @leecalcote |
Hmm I would have expected that e.g. Consul edge-latest returns |
|
Same for |
Consul, NSM, OSM return version and gitsha now, tested with edge and using closing this issue now 🎉 |
Current Behavior
Meshery adapters have their version # hardcoded. See https://github.com/layer5io/meshery-adapter-library/blob/master/common/defaults.go#L34
Desired Behavior
An adapter's version number should be retrieved at buildtime from the CI workflow.
Resources
Alternatives / Additional Context
The text was updated successfully, but these errors were encountered: