Mastodon: Display version number on Admin page

[thegibsonmainframe]

Please add version numbers somewhere in admin pages..

---

• [ ] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[wxcafe]

It would be nice to add it somewhere user-facing too, like in this text

[ericblade]

Wouldn't it be probably most useful on the login screen?

[thegibsonmainframe]

Probably so.

---- On Fri, 14 Apr 2017 22:42:42 -0700 [email protected] wrote ----

Wouldn't it be probably most useful on the login screen?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[wxcafe]

I'd say both, cause logged-in users never see the login screen

[SuliacLEGUILLOU]

I would like to try to work on this o/
I was thinking about some parsing on git status during asset compilation so dev could have information on the branch they are looking at.
Does anyone saw some other way around this issue ?

[wxcafe]

git status and git log if it's not on master, yeah, sounds good

[ashfurrow]

I think git describe --tags might strike the balance between useful and concise. It outputs something like v1.2-80-gadeda7bf, where v1.2 is the latest tag, 80 is the number of commits done since that tag, and gadeda7bf is the specific commit git is on.

[ashfurrow]

I took a look at this and the difficult part is getting the information into the Docker/Vagrant container. Anyone have any suggestions?

[ericblade]

wow, never knew about git describe --tags. That could be really handy to me in other things, too.

You could use environment variables, such as here https://github.com/moby/moby/issues/14191#issuecomment-242718433 ..

Although I think you'd also need to tweak docker-compose as well to get that solution to work, and I'm just not familiar enough with Docker and Compose to advise beyond that.

I did just try adding git to the container and running the git describe inside it, but the .git directory doesn't make it to the container (this is not surprising)

[wxcafe]

you could also just add it to a file when you docker-compose and when you build the assets

[SuliacLEGUILLOU]

@ashfurrow I just tested : My vagrant container has access to git and there for can sumon git describe
but I don't have any docker environment set up to test on the production env :/

[ashfurrow]

Okay, hmm. I'll try to do some investigating tonight, I'm happy to try any ideas in my instance :wink:

[ashfurrow]

I'm asking for suggestions from some Docker admins at work, hopefully they have something.

[ashfurrow]

The build directory specified in the docker-compose.yml file is . so it _should_ copy in the .git directory too? I'm going to investigate more.

[ashfurrow]

Okay, so it's totally possible to evaluate git describe --tags within the Rails web image (it has the .git directory) but git wasn't installed so it failed. I've opened a PR to install git on the images.

The only remaining question is Heroku/Scalingo. Do they have access to git to evaluate and grab a version number?

[mjankowski]

It seems weird to make "you must have git installed" as a requirement to be an app server ... even if that's a typical tool to deploy apps ... I think it's better to have as few requirements/deps on servers as is possible.

What about tossing a ::VERSION constant somewhere which gets bumped when we tag, and then gets output somewhere in the admin UI?

People who are interested in and capable of running non-tagged-releases should also be capable of reporting back on which git commit they are running when they need to talk about it?

[ashfurrow]

Agreed, that might be a better approach. I've not done this before, so advice is welcome.

However, I would advocate for having this be visible in the /about/more page, to help diagnose user bugs. It would;d be helpful to know what version of Mastodon they're seeing bugs on, especially as the number of releases increases over time.

[csu]

It might also be useful to have this exposed via the API. That way, clients can alter their behavior depending on what version of the API they're interacting with.

For example, the latest release just made the "retrieve status" API accessible without authentication. With the version exposed through the API, a client could first check the version of the instance/API and then determine whether or not it can use the "retrieve status" API or if it has to fall back to some other method (e.g. fetching HTML/Atom, for this case).

[thegibsonmainframe]

This would be VERY Useful for an extensible future for the federation.

From: Christopher Su [mailto:[email protected]]
Sent: Wednesday, April 19, 2017 4:59 PM
To: tootsuite/mastodon [e-mail]
Cc: thegibsonmainframe [e-mail]; Author [e-mail]
Subject: Re: [tootsuite/mastodon] Display version number on Admin page (#1789)

It might also be useful to have this exposed via the API. That way, clients can alter their behavior depending on what version of the API they're interacting with.

For example, the latest release just made the "retrieve status" API accessible without authentication. Clients could first check the version of the instance/API and then determine whether or not they can use the "retrieve status" API or if they have to fall back to some other method (e.g. fetching HTML/Atom, for this case).

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/tootsuite/mastodon/issues/1789#issuecomment-295462631 , or mute the thread https://github.com/notifications/unsubscribe-auth/AaO4iknSRUPcgRCmKbgbsGcJV-S2N3Nzks5rxoOwgaJpZM4M95g- . https://github.com/notifications/beacon/AaO4ikVZzVTSN_4NAIEy1tgeJsRLeGaCks5rxoOwgaJpZM4M95g-.gif

[ashfurrow]

Okay, I've closed my PR; I'd like to take a crack at this if that's okay.

[ashfurrow]

Okay, had fun with this. Let me know what y'all think.