Show version

[bingxie]

Display the version on two places.

[mkllnk]

I think the --abbrev=0 could be omitted so that people know if they are running the latest code of a branch instead of a release. But it's okay as is. Definitely an improvement.

[mkllnk]

I think this pr can go ahead.

[oeoeaio]

Hey @mkllnk and @bingxie, Rohan and I are just looking at this, and we've noticed a bit of an issue. The logic here depends on the existence of a tag for the version number, which is very dependent on the particular workflow being used, and also on the way that tags are used.

For example, the last tag on our production server in Aus will always be the previous version, rather than the current one, because the current release is generally only created in GitHub after we have pushed to production (which is when tags on the server will be updated). This means that this logic will work quite well on Aus production for intermediate pushes to prod, but not at all for actual releases.

The second consideration is that it restricts the use of tags to releases only - not sure how big an issue this is, but probably not a good idea to assume this will always be the case.

We thought it might be better to use the GitHub API to determine whether the current server commit is a release commit, and if so, to use that version number. This request could be cached, and only invalidated on server initialisation.

Where the server commit does not match a release commit, we can just display the SHA - this will probably only ever happen on Australian production...

How does that sound?

[mkllnk]

That's a good point. But since we deploy quite regularly, it's not a big deal.

If we wanted to use Github integration, it could be better to listen to release events and act on that. For example do a git fetch and reload the version number. We could use that infrastructure later to inform admins about new releases as well.

[bingxie]

Using the github releases API is a very good idea. I went through the API doc, I can only find get a release by tag name API. It still rely on the tag name. I am not sure how can we match a release with server commit.

[mkllnk]

Github always uses a tag for a release. You can't have a release without tag. That's why I think that git describe is a really good solution. The question is just: When do we update our local data about the release?

Even if we use the Github API and retrieve the information on deploy of our production server, we have the same problem that the release doesn't exist yet. We will have an outdated version number on our production server.

[bingxie]

@oeoeaio How should we make decision on this issue?

[oeoeaio]

@bingxie @mkllnk @RohanM

I really like the idea of using GitHub's webhooks to listen for release events and to then update the version number accordingly. How does everyone else feel about that?

[bingxie]

👍 , so we can use webhooks to get the newest version for our australian production server. But for others who deployed a older version, does it still rely on the git tag?

[mkllnk]

That's a good idea. So we extend this pull request so that we update the tag information based on a webhook call. That's cool.

[daniellemoorhead]

---Doing a PR Cleanup---

@oeoeaio @mkllnk do you think this is worth keeping and building on this or should the PR be closed?

[mkllnk]

It would be good to do this. Seems really useful.

[daniellemoorhead]

Closing this, comment added to #577 issue that can be picked up and implemented via a new PR.