glycam.org Status page missing useful metadata

[Pshepp]

Tool:
https://glycam.org/status/versions/ is missing useful metadata we have

Bug Description:
I was kind of hoping to avoid doing a larger report, but since I am already kinda redoing this due to not being precise with my language, it is the perfect time to just go over everything.

• Improve given naming to be more useful
  • For each of the fields that take the form of *_GIT_BRANCH, the accompanying field will always say actual this can be useful to make sure we are always following our deployment pattern where only commits(/branches <-?) with that tag(/name <-?) are spun up. But having the codename tag (i.e. wistful-walker) for each bit of the stack will be easier for the brain. Yes, can copy past hash or enter in the first couple bits of hash but having the actual codename for each part of our deployment can be easier. Plus, they are cool names so why not have them here where we get our code metadata? It will also be nice for another more human way to check our test site vs our actual site. Finally in gems and gmml, by having the codename tag listed, we can more cleanly get to the interesting commit; now going to actual in those repos takes you to the commit of the actual branch not the repo we would make changes in, overall just smoother but yes I know I'm a little zany but it is logically nicer.
  • If we always want the *_GIT_BRANCH: fields to say actual, I would say we don't even have to display these fields if they are all actual as expected, and then have a dynamic warning message in red pop-up on the top of the status page saying something along the lines of Deployment pattern where all parts should be actual broken and then we display all of the fields that should always be actual. This is a nitpick, and I am a monkey with making UI/pretty things, so I can really only express how we just need to see the fields that should always say actual if something is different than what we expect and defer to others for exact implementation so it doesn't look like a c++ dev made it lol.

To Reproduce:
go to https://glycam.org/status/versions/

In gitkraken, open up the tags option in gems or gmml and try out using the codename tags of the deployments instead of using the actual branch as your marker. Unsure how to say this better, will be more observant of my workflow to better explain in future.

Expected behavior
Have the ability to see what is the codename tag that was deployed, and only see the fields that should always be actual if we need to see em aka they're not actual

[gitoliver]

"Our branch names say actual, which with the way how deployments are currently being done, will always be the case."
This was not the case today, and having the branch names say what they actually are instead of yearning-yael diagnosed the problem for us.

[Lachele]

Branch names should not be the codename. We don't do branches that way. It's not a bad idea,but it's not what we do. The codename is merely a tag, not a branch. They should say the branch is Actual for glycam.org, X-dev on LiveDev, etc

…

On Fri, Feb 3, 2023 at 3:25 AM Oliver ***@***.***> wrote: "*Our branch names say actual, which with the way how deployments are currently being done, will always be the case.*" This was not the case today, and having the branch names say what they actually are instead of yearning-yael diagnosed the problem for us. — Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCV7DZHKF5FFIKTNPLWSXTWVS6G5ANCNFSM6AAAAAAUPZCTVA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- :-) Lachele ***@***.*** lachelefoley.com I'm happy people are learning that sleep is important. Now, please stop trying to kill the nocturnal folks.

[Pshepp]

Sorry seems like I wasn't communicating clearly. Will edit the bug report to be more precise

Lachele (not tagging you cause you're still on vacation, and thanks for popping in to respond here and on slack) I will go ahead and edit the bug report to be more clear. I knew that the codenames were tags, but was not being precise with my wording; sorry about needlessly causing you to respond but on the bright side I feel bad enough to really focus on fixing my wording.

[gitoliver]

For the above issue I recommend an extra field with the info Preston wants, rather than changing what the branch name field shows.

A further enhancement: If there is a way to also ensure the gems/gmml compile "version" matches the tag and is shown on the status page. Now we can be on the "actual" branch but the compiled version of gems/gmml can be from a separate branch. Idk how we do this, but it would be a nice safeguard.

[cexum]

Summary: feature request is to add a new field to each branch meta-data that shows its branch tag.

[cexum]

#110

Related issues

[Pshepp]

@GRAYgoose124 peep this may help with some direction

[Lachele]

@gitoliver - the hash is what it was compiled against. The 'actual' branch isn't really different from the 'X-test' branch. It is a shortcut that always points to the code for the site that is currently answering at glycam.org. That is... the compilation is against the same code even though the branch changes. The hash is the thing that matters.

@Pshepp - I see your point. All the codenames and branches should match. Maybe we should make that check be part of the deployment. That is, a move to LiveDev or Actual should fail if all the branches and tags are not the same. @thecoulter

If we do that, we can just show the one branch and the one codename at the top. We can also make the code that collects this info return a warning if they are not all the same. @danwentworthart @cexum

One day, when we start having more refined versioning, this will all need to change, of course. One step at a time.

[gitoliver]

Is your feature request related to a problem? Please describe.
Ensure that all docker image tags in the settings.sh are updated when needed. When key parts that cause changes to the built docker image are changed, we need make sure that the tag with the date and everything is also updated. Also, make sure that if someone is merging branchA into branchB, check that branchA has a later date than branchB in the docker image tag
​
Describe the solution you'd like

Use git diff on "interesting" files that, if changed, require a settings.sh tag update. Check for any changes. @Lachele would know which specifics other than the more obvious ones (i.e. docker-compose file changes, etc.)
    If changes exist in those files since the last push, then ensure changes have also been done to the relevant settings.sh docker image tags by trying to grep out the tag string bits from the relevant docker-compose files. Also need to check that the relevant children docker image tags have been updated.

Describe alternatives you've considered
Turning my computer off and on again
​
Additional context
Something to help with the logic when trying to merge:

https://stackoverflow.com/questions/19102714/how-would-i-write-a-pre-merge-hook-in-git
V_2/bin/gather_image_info.bash will grab all the image tags, so some decent logic bits can probably be yoinked from there to ensure children image tags are also updated