Show current version at bottom of admin dashboard

[dacook]

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?

• Go to the dashboard for a single or multi enterprise user.
• view the version at the bottom
  • on production, this would show something like "v4.3.12-modified"
  • on staging where we've deployed a PR, it would look like "v4.3.11-182-g61baabb1f-modified"
• click on the version, to open up the releases page in a new tab.

Release notes

Changelog Category: 👀 User facing changes

The title of the pull request will be included in the release notes.

[sigmundpetersen]

Nice. This may actually close one of our ancient issues. I had to re-open 😄

[jibees]

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.

[dacook]

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.

[dacook]

Nice. This may actually close one of our ancient issues. I had to re-open 😄

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 would might enable us to cache (rather than make a system call on every request to the dashboard page).

I don't think caching is important here, so I won't bother updating it for now.

[mkllnk]

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.

[Matt-Yorkley]

Agree it should either go in an initializer or in application.rb so it gets called once when the app boots. There's an invisible newline character (\n) that gets added as well, it might be nice to trim it. That value could be useful in other contexts at some point.

# 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

[Matt-Yorkley]

The file extension should be .html.haml for this file, right?

[drummer83]

Hi @dacook,
Wow, that's a good one! I have always wondered how to find out the version which is currently being used! I love it! 💚

Before staging

There was no version showing - SURPRISE! 😮

After staging

We now have the version at the bottom of the dashboard.
I checked the single-enterprise and the multi-enterprise dashboard. 👍
However I wonder, why I get v4.3.11 while we have 4.3.12 already? Even after rebasing your PR it changed, but it's still some 4.3.11 version. I just don't understand. Maybe you could explain quickly and merge if you think that everything is ok?

Single-enterprise dashboard:

Multi-enterprise 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.
Thanks again! 🎉

[mkllnk]

I wonder, why I get v4.3.11 while we have 4.3.12 already?

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 git fetch then it would get the latest tag information and then it could display the right version. But it may also be that we create a new release after a deployment and no server would automatically fetch that information.

So, this information isn't as helpful in staging as it is in production where we deploy tags all the time.

[dacook]

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.