Display the latest commit hash as version in the master Docker image

[immanuelfodor]

Relates to: #1651 (comment)

Although the Shaarli version number is displayed in the footer, the master Docker image always shows dev as the version (hence the vdev in the Material footer):

Shaarli vdev - The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community - Documentation - Theme by kalvn

This makes debugging harder as you have no clue which Shaarli source code version you have within the master image.

Please display the current git commit hash in the footer when using the master image. It can give visual aid of the current release on the master branch, and it could also make reporting errors and testing bugfixes easier.

The CI could replace the static dev string in this file to the latest commit hash: https://github.com/shaarli/Shaarli/blob/master/shaarli_version.php -> 544bbda

Note: The same version is displayed at /admin/server. This page doesn't have a template in the Material theme. kalvn/Shaarli-Material#124

Note: The v prefix could be deleted from the Material theme, it's also not part of Semver (only the X.X.X). kalvn/Shaarli-Material#125

[ArthurHoaro]

This makes debugging harder as you have no clue which Shaarli source code version you have within the master image.

Please display the current git commit hash in the footer when using the master image. It can give visual aid of the current release on the master branch, and it could also make reporting errors and testing bugfixes easier.

That would be a nice feature, but I'm not sure what's the best approach to do so. It could be done through the CI but it would require that it manipulates the Git tree (i.e. create a commit and push/rebase it automatically), which I'm not a really in favor of. It can probably lead to other issues.

Git hooks could be a solution but they aren't really reliable as they can't be enforced.

I think I have seen this in other projects, I'll try to take a look at what's being done there.

[immanuelfodor]

Oh, we do it just for the build at work, we don't push the modified file back. It's really simple, the dev string can act as a placeholder then do sed -i -E "s/dev/$COMMIT_SHA/" shaarli_version.php where the commit sha is provided by the CI as env variable or grabbed from the local repo clone with git.

[nodiscc]

yes the Dockerfile is probably the best place to do such a replacement at build time, using a branch name environment variable provided by the CI. or a custom entrypoint script to do it at runtime (may be overkill)

[virtadpt]

I think I have seen this in other projects, I'll try to take a look at what's being done there.

Look at how RSS-bridge does it. At the bottom of every install is this:

RSS-Bridge ~ Public Domain

git.master.1edec1a
285/285 active bridges.

[ArthurHoaro]

Oh, we do it just for the build at work, we don't push the modified file back. It's really simple, the dev string can act as a placeholder then do sed -i -E "s/dev/$COMMIT_SHA/" shaarli_version.php where the commit sha is provided by the CI as env variable or grabbed from the local repo clone with git.

What do you call the CI in this context? I don't understand how git clone made by someone would be affected by this change.

yes the Dockerfile is probably the best place to do such a replacement at build time, using a branch name environment variable provided by the CI.

This works fine but only works in Docker context.

Look at how RSS-bridge does it.

Thanks, they parse a file in the .git folder directly if it exists. Crafty, but it works in git context (and probably not in Docker).

https://github.com/RSS-Bridge/rss-bridge/blob/93cdf5e342aa5548efd398d9e34a6ba0a177b371/lib/Configuration.php#L239

[immanuelfodor]

For example, Gitlab CI provides these variables: https://docs.gitlab.com/ee/ci/variables/#list-all-environment-variables

Drone also provides these: https://docs.drone.io/pipeline/environment/reference/

As CIs clone the repo locally, and you usually run within this context, you can even run git log or so in a CI step if such env variables are not enough (eg. getting the last commit date: LAST_DATE=$(git log -1 --format=%cd --date=iso8601-strict)

[nodiscc]

This works fine but only works in Docker context.

true. The issue was about the Docker image but it should preferably work in any context.

For example, Gitlab CI provides these variables

Sure but what @ArthurHoaro meant (?), is how to provide the replacement function for people who install from source from the master branch - i.e whose build never goes through the project's CI system.

Since installation from source already uses a few make calls I think an additional make update_dev_version (that parses git log or git reflog) would work in this context.

In general I think most frequently used tools should be called from the Makefile, because it's relatively portable and can be called from any build/test context. Some CI steps would benefit from being moved to the Makefile (as I realized when working on https://github.com/nodiscc/Shaarli/pull/4/files). The Dockerfile could also leverage makefile targets to help dedu(tri)plicate the current tooling.

[immanuelfodor]

Oh, I misunderstood that. Yes, the make approach could work as it's already in place for the source code install flavor. Git is also there, so the replacement can be made. The same could work with the Docker build, too, if it installs Shaarli the same way from the pre-cloned repo.

LAST_SHA=$(git rev-parse --short HEAD)

[ArthurHoaro]

Yes that's what I meant, sorry if I was not clear. Adding a new make target is a good idea. I'd just add that it should be in a git ignored file.

[nodiscc]

Proposed fix in #1945