Open zven opened 4 days ago
So currently we automatically deploy the latest package automatically. I imagine that the following options should be possible:
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 webpageI'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?
@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.
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.
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?
At the moment, we have no way of knowing which version is currently deployed on
prod
,staging
orrelease
. 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: