Open tameware opened 4 years ago
git describe --always --dirty
is an helpful command for this purposes. It generates version numbers like 0.99.1-62-gf388191-dirty
if repository has version tags in history. I took the example from dealer -V which prints both configuration version and built version reported by git describe
.
Perfect! I presume the build process would write out a file with this info and api.py would read the file and log the info or inject it into the JSON response or both.
I think a common approach for versioning would be a capability query request. This query would return version number and list of capabilities supported. For example current service would only advertise calc table. When Solve board is added later play analyze then it could be added to the capability list.
GET api/capability
info {
version: $(git describe --always --dirty),
capabilities: ["dds-table"]
}
I like this a lot. It's better than injecting the version into the analysis JSON. The server should also log this info when it starts up.
On Sun, Jul 12, 2020 at 11:43 AM suokko notifications@github.com wrote:
I think a common approach for versioning would be a capability query request. This query would return version number and list of capabilities supported. For example current service would only advertise calc table. When Solve board is added later play analyze then it could be added to the capability list.
GET api/capability
info { version: $(git describe --always --dirty), capabilities: ["dds-table"] }
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/online-bridge-hackathon/DDS/issues/70#issuecomment-657253924, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABC4PYAR5XRZF6FQZZF5HOTR3HY5NANCNFSM4OXPT5EA .
Embed version number, deploy timestamp, and Git hash into the api.py JSON response, or log them on the cloud console, or do both.