-
-
Notifications
You must be signed in to change notification settings - Fork 719
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
Show current version at bottom of admin dashboard #11004
Conversation
Nice. This may actually close one of our ancient issues. I had to re-open 😄 |
@@ -0,0 +1,3 @@ | |||
%a{href:"https://github.com/openfoodfoundation/openfoodnetwork/releases", target: "_blank", title: t('.view_all_releases')} | |||
=# Show the latest tag. If there are commits since the tag, show number of commits and an identifier. If the working tree is dirty, show 'modified'. | |||
= `git describe --tags --dirty=-modified` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh wahoo. I didn't know this was actually possible: running git in our view!
I don't have any better suggestion for now (maybe put in a controller ?) as it seems that we don't package a release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it does feel a bit wrong.. but I think to change it would just be more work and obfuscate it further without any benefit.
Thank you for that link! I took a look at the comments and I like Maikel's suggestion, which is a bit more work, but I don't think caching is important here, so I won't bother updating it for now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Looking back at my old comment I would consider an initializer which runs git describe > public/VERSION
. That way we can query the version even if the app completely crashes, or like a public API. And the view could render it like a partial, maybe.
Agree it should either go in an initializer or in # config/application.rb
config.x.git_version = `git describe --tags --dirty=-modified | tr -d "\n"` # overview/_version.html.haml
%a{href: "https://etc..."}
= Rails.application.config.x.git_version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file extension should be .html.haml
for this file, right?
61baabb
to
04e247d
Compare
Hi @dacook, Before stagingThere was no version showing - SURPRISE! 😮 After stagingWe now have the version at the bottom of the dashboard. And what about this file extension? Does it need an update? I'll move it to Ready To Go and leave it for you to merge. |
It depends on the tags the server knows about. And that depends on the deployments before. So if you deploy the tag v4.3.12 and then another pull request then it should display that number. But if the server has never seen v4.3.12 then it can't display it. Or, if you logged into the server and ran So, this information isn't as helpful in staging as it is in production where we deploy tags all the time. |
With generic link to the releases page. We could provide a link to latest tag with `git describe --tags --abbrev=0`. But I thought it better to keep things simple.
04e247d
to
35d9837
Compare
Thanks for explaining Maikel, I have to admit I wouldn't have been able to! I've fixed up the filename, and specs pass, so I will merge. |
Closes #577.
With generic link to the releases page. We could provide a link to latest tag with
git describe --tags --abbrev=0
. But I thought it better to keep things simple.This is visible to any admins.
I considered using view caching, but concluded that it wasn't worth it. When a deployment is made, I'm not sure that the cache is cleared. So we'd need to add a cache key based on the git reference. Which requires another system call to retrieve, which defeats the point of caching.
What? Why?
Most people don't have access to check this on the server, so this allows them to confirm at any time.
Also, sometimes a lot of time can be lost debugging an issue, without realising the platform is running on an older version where the but has been fixed (like yesterday!)
What should we test?
Release notes
Changelog Category: 👀 User facing changes
The title of the pull request will be included in the release notes.