Identify BiT dev build by git hash

[ptilopteri]

BiT development builds report version as "backintime 1.4.4-dev" which actually provides little identification.

I propose appending the last commit id to "backintime 1.4.4-dev.c65fc91" so one can tell that his dev version needs updating

[buhtz]

Dear ptilopteri,
thanks for your report.

I like that idea. And we have this still implemented somehow. If BIT starts from a git repo then you will find the current git hash in the About dialog.

backintime/qt/app.py

Lines 1842 to 1846 in c65fc91

	ref, hashid = tools.gitRevisionAndHash()
	git_version = ''
	if ref:
	git_version = " git branch '{}' hash '{}'".format(ref, hashid)
	name = QLabel('<h1>' + self.config.APP_NAME + ' ' + version + '</h1>' + git_version)

But I also support the idea to add the git hash (and branch name maybe) to the version string and also maybe in the window title.

Next time when reporting please consider the use of correct upper case letters (e.g. beginn of sentences, the word "I", ...). It is then more easier to read for us and others. Thanks in advance.

[ptilopteri]

* buhtz ***@***.***> [02-05-24 08:30]:

Dear ptilopteri, thanks for your report. I like that idea. And we have this still implemented somehow. If BIT starts from a git repo then you will find the current git hash in the About dialog. https://github.com/bit-team/backintime/blob/c65fc917a245bdf7dbedc7b12768bf51be39d2c9/qt/app.py#L1842-L1846 But I also support the idea to add the git hash (and branch name maybe) to the version string and also maybe in the window title. Next time when reporting please consider the use of correct upper case letters (e.g. beginn of sentences, the word "I", ...). It is then more easier to read for us and others. Thanks in advance. Message ID: ***@***.***>

rather obtuse method to obtain current build version. shouldn't "backintime --versin" show this instead of just showing "1.4.4-dev"?

…

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[buhtz]

Yes I agree that the git hash could be an element of the regular version string (only in dev versions of course).
But I don't decide this own my own. Let's wait for arguments of other team members.

I forgot to mention that also --diagnostics show the git infos.

$ ./backintime --diagnostics
{
    "backintime": {
        "git-project-root": "/home/UsernameReplaced/mluCloud/my.work/bit/backintime",
        "git-branch": "fix/1634restrictpylint",
        "git-hash": "8c3f7ff6ba063115f56df8d40913afdabc175fa3"
    }
}

[emtiu]

If we make sure to disable this for regular releases, I see no disadvantages :)

[buhtz]

If we make sure to disable this for regular releases, I see no disadvantages :)

The current code works only if it runs from a git repo.

After doing ./configure && make && sudo make install the code won't give you any git information because BIT is then installed into the OS and not aware of a git repo anymore.

I am not a pro when it comes to make. Maybe we could modify the configure script somehow that it takes the current git-hash (if there is one) and store it in a separate file (e.g. /usr/share/backintime/build_version). If BIT finds this file it will present this information. Just a quick n dirty idea. I am not sure about it.

FYI: The version string of BIT is "hardcoded" into the VERSION file. We can not manually add a git hash every time we do a commit.

[ptilopteri]

* buhtz ***@***.***> [02-05-24 09:44]:

Yes I agree that the git hash could be an element of the regular version string (only in dev versions of course). But I don't decide this own my own. Let's wait for arguments of other team members. I forgot to mention that also `--diagnostics` show the git infos. ``` $ ./backintime --diagnostics { "backintime": { "git-project-root": "/home/UsernameReplaced/mluCloud/my.work/bit/backintime", "git-branch": "fix/1634restrictpylint", "git-hash": "8c3f7ff6ba063115f56df8d40913afdabc175fa3" } } ``` Message ID: ***@***.***>

not for what I just built" "backintime": { "name": "Back In Time", "version": "1.4.4-dev", "latest-config-version": 6, "local-config-file": "/home/UsernameReplaced/.config/backintime/config", "local-config-file-found": true, "global-config-file": "/etc/backintime/config", "global-config-file-found": false, "started-from": "/usr/share/backintime/common", "running-as-root": false, "user-callback": "/home/UsernameReplaced/.config/backintime/user-callback", "keyring-supported": true },

…

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[buhtz]

not for what I just built

You build/installed BIT from the cloned repo via ./configure && make && sudo make install. I can see this from your output: "started-from": "/usr/share/backintime/common",. That is technically the reason why you can not see the git hash anymore. Technically you need to run BIT from the git repo without installing it.

I agree this is a shortcoming and we should find a solution for this.

And I need to correct my last post: The version is not "hardcoded" in VERSION file on runtime level. We have a helper script update_version.sh which take the version number from that file and then inject it everywhere in the py files (and some other files) where it is relevant.

To my knowledge of the Filesystem Hierarchy Standard (FHS) a file containting the current git hash (and other static meta information) should be generated/installed into /usr/share/backintime/common and /usr/share/backintime/qt folder. Two folders because technically we do have two separate applications.

EDIT:
Note to myself: There is a redundancy in code. The --diagnostics feature get git infos from diagnostics.py::get_git_repository_info() but the about dialog from tools.py::gitRevisionAndHash().

EDIT2: Adding this line in the Makefile to get branch and hash in json format.

python3 -c "import diagnostics as d;import pathlib as p;import json as j;git=d.get_git_repository_info(p.Path.cwd().parent);print(j.dumps(git))" > bit.git.json

Of course replace bit.git.json with the correct path (e.g. /usr/share/backintime/common/bit.git.json and the same for qt).

$ cat bit.git.json
{"branch": "fix/1634restrictpylint", "hash": "8c3f7ff6ba063115f56df8d40913afdabc175fa3"}

[buhtz]

I have a solution in mind and I would like to present the details in a PR. Before that I would like to know if there are arguments against having such an extra file in /usr/share/backintime/common and /usr/share/backintime/qt containing the branch at git hash at build time?

[emtiu]

I have a solution in mind and I would like to present the details in a PR. Before that I would like to know if there are arguments against having such an extra file in /usr/share/backintime/common and /usr/share/backintime/qt containing the branch at git hash at build time?

Hmm. I'm not well-informed on this topic, but it seems a bit like overkill.

How do other projects do it? There's probably a lot of software that includes its git version in shipped packages.

Is this something that might work more "naturally" once we eliminate make and move to "modern" python packaging?