Identify BiT dev build by git hash #1637

ptilopteri · 2024-02-04T18:06:03Z

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 · 2024-02-05T13:29:01Z

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 · 2024-02-05T13:43:47Z

* 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 · 2024-02-05T14:43:33Z

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 · 2024-02-05T14:52:36Z

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

buhtz · 2024-02-05T15:01:12Z

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 · 2024-02-05T15:35:33Z

* 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 · 2024-02-05T15:41:38Z

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 · 2024-02-06T09:41:00Z

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 · 2024-02-06T09:49:00Z

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?

buhtz · 2024-02-06T10:16:08Z

it seems a bit like overkill.

Yes, I also would treat this as an temporary workaround until we find a better solution.

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

Good question. I guess that C/C++ and other compile-linking languages do inject the version string into their source files (e.g. via configure/make) before starting the compiler. But it is just a guess.

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

Very good question! 😄 I will ask the community. But to my current low expertise on that topic I would add a "custom build step" to inject git info somewhere in the source files. I am not sure. It feels also like a workaround or hack.

buhtz · 2024-02-06T12:56:25Z

About a pythonic solution: It seems to be that there are plugins for the several Python build-tools (e.g. setuptools, hatchling) solving that problem without hacking around. I will investigate a solution further in my demo project.

Anyway. This won't happen early. As a short solution and workaround I currently see only this extra file generated while make install.

Maybe Jürgen will have another idea.

ptilopteri · 2024-02-06T13:53:08Z

* buhtz ***@***.***> [02-06-24 04:41]:

I have solution in mind 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? Message ID: ***@***.***>

not if "backintime --version" reported it.

…

-- (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

ptilopteri · 2024-02-06T13:54:54Z

* buhtz ***@***.***> [02-06-24 05:18]:

> it seems a bit like overkill. Yes, I also would treat this as an temporary workaround until we find a better solution. > How do other projects do it? There's probably a lot of software that includes its git version in shipped packages. Good question. I guess that C/C++ and other compile-linking languages do inject the version string into their source files (e.g. via configure/make) before starting the compiler. But it is just a guess. > Is this something that might work more "naturally" once we eliminate `make` and move to "modern" python packaging? Very good question! 😄 I will ask the community. But to my current low expertise on that topic I would add a "custom build step" to inject git info somewhere in the source files. I am not sure. It feels also like a workaround or hack. Message ID: ***@***.***>

darktable does it: https://github.com/darktable-org/darktable

…

-- (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

aryoda · 2024-02-08T01:29:20Z

The point is that the git commit hash shall only be injected into a non-release build.

So we need either

an automatic way to recognize 100 % correctly if make ... is building a release or dev version
or add a different make target to build releases (eg. make release) to let the (human) builder decide if the commit hash shall be part of the version number

I propose to extend our configure script

to append the (or replace an existing) commit hash to the version.txt only if it contains the word dev
and then always call the updateversion.sh

PS: The commit hash is a hex number so it may never contain the word dev

buhtz · 2024-02-08T08:31:45Z

The point is that the git commit hash shall only be injected into a non-release build.

I would suggest a slightly different and IMHO easier to implement approach. The version.txt (better gitversion.txt?) is created every time. But BIT will read from it only if it finds a dev at the end of its regular version string.

When BIT asking for its version string (via --version, --diagnostics, About dialog or main window title bar) I would suggest this decision cascade:

Running in a git repo? I often start BIT from the repo without installing it. This question is still implemented in the --diagnostics section. TRUE: Read branch and hash from the existing repo. FALSE: Next step.
-dev at the end of the regular version string? TRUE: Read the gitversion.txt file and add the hash to the version string. I would also somehow add the branch name to it or maybe only add the branch name when it is different from "main" or "dev".

This would cover all known to me use cases.

BIT use the last commit hash in its version string if it is a "*-dev" version. Additionally some refactoring: - "Config.VERSION" moved into new file "version.py" as "__version__" - "diagnostics.py::get_git_repository_info()" moved to "tools.py". - Removed "tools.py::gitRevisionAndHash()" Some more - File "VERSION" no longer part of "make install" target Close #1637

ptilopteri · 2024-02-13T15:09:39Z

you have closed this but the last build incorporating this patch, cf02bee, does not display the current level of 1.4.4-dev, nor does it indicate any way for a non-programmer to find it. backintime --version backintime 1.4.4-dev ???

buhtz · 2024-02-13T15:12:43Z

Have you re installed BIT common and BIT qt as described here?

~~The git-hash is "injected" only when when doing make install.~~

The git hash is determined only when calling updateversion.sh and then installing BIT common and BIT qt.

./updateversion.sh
VERSION: 1.4.4-dev.98246546
Update 'common/version.py'
Update 'common/doc-dev/conf.py'
Update 'common/man/C/backintime.1'
Update 'common/man/C/backintime-config.1'
Update 'common/man/C/backintime-askpass.1'
Update 'qt/man/C/backintime-qt.1'
Update 'debian/changelog'

This might not fulfill all your needs but it is how we have discussed it the related PR #1640.
If you have further needs please open a new Issue and try to describe your needs and use case as specific as possible.

ptilopteri · 2024-02-13T15:17:53Z

> Have you re installed BIT common and BIT qt as described [here](https://github.com/bit-team/backintime/blob/dev/CONTRIBUTING.md#build-and-install-via-make-system-recommended)?

that is what I just said. and applied your patch for opensuse tumbleweed.

buhtz · 2024-02-13T15:26:11Z

@aryoda Is that the reason why you wanted to add the "updateversion.sh" call to the "make install" target? Make sense now to me. 🤣

aryoda · 2024-02-13T22:30:42Z

@aryoda Is that the reason why you wanted to add the "updateversion.sh" call to the "make install" target? Make sense now to me. 🤣

@buhtz Yes, every "manual protocol" to follow ("step-by-step" TODO lists) may be forgotten or applied in the wrong way so make install is the best place to free our (and the "installers" mind :-)

aryoda · 2024-02-13T22:35:36Z

I vote to close this issue as "fixed" since "building" with make install injects the Git hash.

Edit: Looks like make install does not yet contain the call of updateversion.sh but the build target is suggested instead in PR #1641

Starting BiT directly from the repo without installing it does not inject the Git hash but
a) the user knows the Git hash then
b) and this is not valid end user scenario (only for developers or testers)

The git-hash is added to every "*.dev" version string while calling "make install". Close #1637

buhtz self-assigned this Feb 5, 2024

buhtz added Feature requests a new feature Discussion decision or consensus needed GOOD FIRST ISSUE Used by 24pullrequests.com to suggest issues labels Feb 5, 2024

buhtz added this to the Upcoming release (1.5.0) milestone Feb 5, 2024

buhtz changed the title ~~identify BiT dev build~~ Identify BiT dev build by git hash Feb 5, 2024

buhtz mentioned this issue Feb 9, 2024

Build: Display last commit hash in "*-dev" version strings #1640

Merged

buhtz removed the GOOD FIRST ISSUE Used by 24pullrequests.com to suggest issues label Feb 9, 2024

buhtz closed this as completed in #1640 Feb 13, 2024

buhtz reopened this Feb 13, 2024

buhtz added the Feedback needs user response, may be closed after timeout without a response label Feb 13, 2024

buhtz mentioned this issue Feb 13, 2024

Fix: git-hash injection on every build #1641

Merged

buhtz closed this as completed in #1641 Feb 15, 2024

buhtz added a commit that referenced this issue Feb 15, 2024

Build: git-hash injection on every build

75089bd

The git-hash is added to every "*.dev" version string while calling "make install". Close #1637

buhtz mentioned this issue Jul 23, 2024

Release Candidate: Back in Time 1.5.0 #1806

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Identify BiT dev build by git hash #1637

Identify BiT dev build by git hash #1637

ptilopteri commented Feb 4, 2024

buhtz commented Feb 5, 2024

ptilopteri commented Feb 5, 2024 via email

buhtz commented Feb 5, 2024

emtiu commented Feb 5, 2024

buhtz commented Feb 5, 2024 •

edited

Loading

ptilopteri commented Feb 5, 2024 via email

buhtz commented Feb 5, 2024 •

edited

Loading

buhtz commented Feb 6, 2024 •

edited

Loading

emtiu commented Feb 6, 2024

buhtz commented Feb 6, 2024

buhtz commented Feb 6, 2024 •

edited

Loading

ptilopteri commented Feb 6, 2024 via email

ptilopteri commented Feb 6, 2024 via email

aryoda commented Feb 8, 2024

buhtz commented Feb 8, 2024

ptilopteri commented Feb 13, 2024 via email •

edited by buhtz

Loading

buhtz commented Feb 13, 2024 •

edited

Loading

ptilopteri commented Feb 13, 2024 via email •

edited by buhtz

Loading

buhtz commented Feb 13, 2024

aryoda commented Feb 13, 2024

aryoda commented Feb 13, 2024 •

edited

Loading

Identify BiT dev build by git hash #1637

Identify BiT dev build by git hash #1637

Comments

ptilopteri commented Feb 4, 2024

buhtz commented Feb 5, 2024

ptilopteri commented Feb 5, 2024 via email

buhtz commented Feb 5, 2024

emtiu commented Feb 5, 2024

buhtz commented Feb 5, 2024 • edited Loading

ptilopteri commented Feb 5, 2024 via email

buhtz commented Feb 5, 2024 • edited Loading

buhtz commented Feb 6, 2024 • edited Loading

emtiu commented Feb 6, 2024

buhtz commented Feb 6, 2024

buhtz commented Feb 6, 2024 • edited Loading

ptilopteri commented Feb 6, 2024 via email

ptilopteri commented Feb 6, 2024 via email

aryoda commented Feb 8, 2024

buhtz commented Feb 8, 2024

ptilopteri commented Feb 13, 2024 via email • edited by buhtz Loading

buhtz commented Feb 13, 2024 • edited Loading

ptilopteri commented Feb 13, 2024 via email • edited by buhtz Loading

buhtz commented Feb 13, 2024

aryoda commented Feb 13, 2024

aryoda commented Feb 13, 2024 • edited Loading

buhtz commented Feb 5, 2024 •

edited

Loading

buhtz commented Feb 5, 2024 •

edited

Loading

buhtz commented Feb 6, 2024 •

edited

Loading

buhtz commented Feb 6, 2024 •

edited

Loading

ptilopteri commented Feb 13, 2024 via email •

edited by buhtz

Loading

buhtz commented Feb 13, 2024 •

edited

Loading

ptilopteri commented Feb 13, 2024 via email •

edited by buhtz

Loading

aryoda commented Feb 13, 2024 •

edited

Loading