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
However, we have a few inquires regarding the available fields to hold useful information about service source code and build.
Through our practice, we have found Git commit hash and additional time of the build to be very useful when included in service info - they compliment version information. We do not, however, find adequate fields in the /health response JSON structure where we can put this information. The closest existing field we have found to Git commit hash is releaseId, but the example shows other usage of this field. For build time we did not find anything useful. So currently we added 2 fields in our response, commit and build_time, but they make our response JSON not adhering to the current standard.
What is the best was to proceed? Should this information be added to some of the existing fields somehow, or should the standard be extended?
The text was updated successfully, but these errors were encountered:
We from Mainflux have been following the latest "Health Check Response Format for HTTP APIs" draft in order to standardize our healthchecks: https://github.com/mainflux/mainflux/pull/1541.
However, we have a few inquires regarding the available fields to hold useful information about service source code and build.
Through our practice, we have found Git commit hash and additional time of the build to be very useful when included in service info - they compliment version information. We do not, however, find adequate fields in the
/health
response JSON structure where we can put this information. The closest existing field we have found to Git commit hash isreleaseId
, but the example shows other usage of this field. For build time we did not find anything useful. So currently we added 2 fields in our response,commit
andbuild_time
, but they make our response JSON not adhering to the current standard.What is the best was to proceed? Should this information be added to some of the existing fields somehow, or should the standard be extended?
The text was updated successfully, but these errors were encountered: