Introduce a CPT backend version#199
Conversation
|
what's the purpose of using the git information? Is it to programmatically incorporate git information into the version? |
mfleader
left a comment
mfleader
left a comment
There was a problem hiding this comment.
Why do we need to include all of this information in the version? Is it all supposed to be a part of uniquely identifying any build?
There was a problem hiding this comment.
Why do we need to include all of this information in the version? Is it all supposed to be a part of uniquely identifying any build?
I'm certainly open to arguments that I "went too far"; but I do want to include at least some git information because we're going to have multiple development builds between "versions". Using the git commit hash helps to keep them unique. Adding the active branch was something of an experiment--if I do two container builds from different local PR branches off main, I can tell the servers apart that way. Unfortunately this turns out to be a lot less useful for CI builds as the "branch" isn't distinct or particularly useful (they're headless branches). By the time I figured that out, I didn't feel like backing it out, and it might still be useful for local development.
Including the recent git log history? Well, it was an idea to add context, and I think it's kinda sad (though I haven't bothered to push back) that most of our git commit messages are pretty useless; and if the messages aren't useful, the history probably isn't useful either. My half-formed thought was that I could show the history in a popup from the header version element in the UI; I'm not convinced that's worthwhile ... but I'm also not convinced it's useless. 😆
FYI:
|
I've been playing with the UI ... I may post a draft PR soon, but FY ...
|
Version information is compiled at build time using a Python script, producing a transient JSON file that will be copied into the backend container for access at runtime via `GET /api/version`.
It's still in the details, but this won't be useful for deployed builds and it just takes space. Also, when we don't get a branch name, identify the "buid "branch" as `CI`.
|
Merging this will be an interesting test that we can properly build the container with my version hooks and push it to Quay ... and that ArgoCD actually picks it up and updates the dev deployment. |
2 participants
Type of change
Description
Version information is compiled at build time using a Python script, producing a transient JSON file that will be copied into the backend container for access at runtime via
GET /api/version.Related Tickets & Documents
PANDA-823 CPT aggregator version
Checklist before requesting a review
Testing
scripts/start-reload.sh-- works./local-compose.sh-- works./backend/tests/e2e_backend.sh-- worksbuild-push.ymlaction fails on merge, I'll need another PR to (hopefully) fix it.