mint-o-badges / badgr-ui

GNU Affero General Public License v3.0
4 stars 2 forks source link

ui | server: show version on website and api page #769

Open zven opened 4 days ago

zven commented 4 days ago

At the moment, we have no way of knowing which version is currently deployed on prod, staging or release. After discussing with @umut0 it would make sense to have information on the current version:

On the OEB website we could put in in the very bottom of the imprint page: https://staging.openbadges.education/public/impressum For the server, this could be on the api documentation pages: https://api.openbadges.education/docs/v2/ https://api.openbadges.education/docs/v1/

First ideas:

timber-they commented 4 days ago

So currently we automatically deploy the latest package automatically. I imagine that the following options should be possible:

  1. Get the commit hash from the package that is currently deployed and display that in the footer (e.g. 67c7137b5f7c7ee77b06203e5142e9e55ea607f4, or in short 67c7137). This information is contained in the package and can be retrieved with (for example for the develop badgr-ui image) docker image inspect ghcr.io/mint-o-badges/badgr-ui:develop-Develop | grep "org.opencontainers.image.revision" | sed -E "s/^\\W*\"org.opencontainers.image.revision\": \"([0-9a-f]+)\".*/\1/g" or docker image inspect ghcr.io/mint-o-badges/badgr-ui:develop-Develop | grep "org.opencontainers.image.revision" | sed -E "s/^\\W*\"org.opencontainers.image.revision\": \"([0-9a-f]{7})[0-9a-f]+\".*/\1/g" respectively. Then we would just somehow need to integrate it into the webpage
  2. Get the tag of the most recent commit that is not newer than the commit from the package that is currently deployed. This information should be available since we already know how to get the commit that is currently deployed
  3. Change the way we deploy stuff so that we only deploy if a commit gets tagged. Than extract that tag information
  4. Add some version information in the code (or actually use it, I think we already have something like this) and display that. That would mean that we manually need to update the version information though. That would be the easiest to execute, but it would involve more manual steps
  5. Have some version information like that hardcoded somewhere that gets automatically incremented on commit with a commit hook
zven commented 4 days ago

I'm strongly gravitating to suggestion 1. (display commit hash) or 3. (deploying things once we tag a commit). Could 3. be realized in a way that we don't need to increment / create tags manually? No 1. sounds nicely simple. We could also check out how the opensensemap does that: https://opensensemap.org/about It looks like a compination of versioning and commit hash.

@umut0 What do you think?

timber-they commented 3 days ago

@zven yes opensensemap seems a good inspiration! From the code, this is the relevant part:

            {
              match: "VERSION",
              replacement: "<%= pkg.version %>",
            },
            {
              match: "NAME",
              replacement: "<%= OPENSENSEMAP_RELEASE_NAME %>",
            },
            {
              match: "REVISION",
              replacement: "<%= gitinfo.local.branch.current.shortSHA %>",
            },

So there seems to be a package version (that is independent of git) and the git short commit hash. I'm gonna look into how we could integrate the git hash then.

timber-they commented 3 days ago

There is an angular schematic that gives us all the information we need. I've integrated it into this branch. what it does is create an environment file in src/environment/version.ts with all the relevant git information. Since we build every time we deploy, this gets updated automatically. Right now for example it looks like this:

// IMPORTANT: THIS FILE IS AUTO GENERATED! DO NOT MANUALLY EDIT OR CHECKIN!
/* tslint:disable */
/* eslint-disable */
export const VERSION = {
    "dirty": true,
    "raw": "v1.4.0-162-ge382db90-dirty",
    "hash": "ge382db90",
    "distance": 162,
    "tag": "v1.4.0",
    "semver": {
        "options": {
            "loose": false,
            "includePrerelease": false
        },
        "loose": false,
        "raw": "v1.4.0",
        "major": 1,
        "minor": 4,
        "patch": 0,
        "prerelease": [],
        "build": [],
        "version": "1.4.0"
    },
    "suffix": "162-ge382db90-dirty",
    "semverString": "1.4.0+162.ge382db90",
    "version": "0.0.0"
};
/* tslint:enable */

Note that it contains the short git commit hash of the latest commit (though for some reason there's a g added at the beginning, but we can truncate that), and it also contains the latest tag! So we can simply decide to tag release commits (or any commit in between) and then the displayed version also gets updated. If we don't tag it, the version stays the same, but the commit hash still indicates which version we're on.

timber-they commented 3 days ago

I've also added a similar mechanism to retrieve the git commit hash and latest tag in the server. You can check it out on this branch. It's a bit more complicated and I still need to test it on our servers, but it seems to work.

@zven is this what you intended?