Display version on deployed github page

[s-l-teichmann]

Currently there is no user accessible way to tell which version is served as a Github page. That should be possible.

[tschmidtb51]

The version string can be extracted during the build of the GH-pages. We do something similar for Secvisogram - but maybe an easier method can be found (e.g. executing git describe during the build process).

[ThomasJunk]

I tried to implement an easy solution with

• https://github.com/csaf-poc/csaf_webview/commit/8c50c38c780b83cd3bcfe8ffec17bda798165ec9#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519
• https://github.com/csaf-poc/csaf_webview/commit/8b52788c8c9d8f6c21c8554746cac487ccaefd0f

Leveraging git describe to retrieve info and redirect it to a VERSION file. On starting/building I include this information into the runtime context of the app.

This should do the trick (for now).

[ThomasJunk]

TIL: git describe behaves tricky in the context of GithubActions and in consequence broke integration testing even before starting to test.

In https://github.com/csaf-poc/csaf_webview/commit/e53a94be4c60b08c3ae657c8a98bba9858cd71ab I switched to the even simpler concept of using the version info of package.json.

[ThomasJunk]

So it looks like this (for now). I think we can discuss general layout later.

[tschmidtb51]

TIL: git describe behaves tricky in the context of GithubActions and in consequence broke integration testing even before starting to test.

@ThomasJunk: Actually, the checkout/action does only do a shallow checkout by default (which does not capture the tags). In order to do that, you have to run git fetch --depth=1 origin +refs/tags/*:refs/tags/* after the checkout (see https://github.com/secvisogram/secvisogram/blob/main/.github/workflows/github-pages.yml as example). Note: tags need to be annotated - otherwise this will fail.

The nice thing about this approach is, that it already works in development (with each commit) without having to update the version in the package.json ;-)

[bernhardreiter]

@ThomasJunk see https://github.com/csaf-poc/csaf_distribution/blob/7d3c3a68df05e48640e8e2eaec53ee23bb370285/Makefile#L40-L58 for an example that results into a semver compatible version after using git describe in different situations within Github Actions. If fitting, please use that method.

[ThomasJunk]

Is it necessary / meaningful to do this as a github action? ATM we read from the package.json. So it might be a better idea to do this via commit hooks and commit the changed package.json (with the updated version number) along with the other files of the commit? So we always have an up to date version in package.json.

As a hint: https://stackoverflow.com/a/55427831/411645 shows a "recipe" for such a hook. Instead of using bump.js we could do our git describe-logic within that script.

Or use npm version to accomplish our task.

[tschmidtb51]

In general, I'm not a big fan of the package.json solution as it requires somebody to update the package.json. At the end, the solution needs to work - independent which way the user took:

1. create a release via Github
2. local tags of a version that then gets pushed
3. ...

Therefore, I would like to rely on Git tags instead.

Nevertheless, if there is a way to keep tags and the version the package.json and the package-lock.json consistent in each of these cases - please let me know.

BTW: GithubActions use a shallow checkout - that's why I linked to our solution for Secvisogram.

[ThomasJunk]

As far as my understanding goes npm version should do the thing requested:

Run this in a package directory to bump the version and write the new data back to package.json, package-lock.json, and, if present, npm-shrinkwrap.json.

If run in a git repo, it will also create a version commit and tag.

There is even a possibility to use the latest git-tag as a source

from-git will try to read the latest git tag, and use that as the new npm version.

which meets the requirement of

Therefore, I would like to rely on Git tags instead.

The package.json then is only the destination where a current version is written to and the source for the application where it is read from.

And this should run too in the context of a github action.

[bernhardreiter]

Just to remind: Using the latest git tag is not enough for development versions as it would display the wrong version.

[JanHoefelmeyer]

Not yet automated via github actions.