The BOINC manager should display the build SHA1 in its About dialog

[brevilo]

Showing the arbitrary build version isn't enough to know exactly the source code version used for a build. Show the abbreviated SHA1 of the HEAD used for building the app in the dialog as well.

[ChristianBeer]

This is needed to better distinguish development versions without creating a new minor release just for a limited test.

[brevilo]

The Android app can be changed in a pretty easy way. I'm going to open a PR for it soon.

Alternatively the client itself could have the SHA1 compiled in (use git describe to fetch the details) and a new RPC (?) added such that the manager can query it. This assumes that manager and client are compiled from the same source though.

[Vulpine05]

I'm interested in working on this feature. I have a few of questions:

1. In theory, the Client and Manager could have different builds. Should both be displayed in the About dialogue?
2. Should the SHA1 be displayed for a pre-release version only, or for a release version as well?
3. How many characters for the SHA1 should be displayed? I would assume 7, similar to what Github displays for commits.

[AenBleidd]

@Vulpine05,

1. Only the Manager. The client reports its version to the console, so technically you can add it to that console message.
2. For every build and every version
3. For Android we do 10 characters, so I'd follow the same approach here as well: https://github.com/BOINC/boinc/actions/runs/17310796416/job/49144675017#step:10:102

[Vulpine05]

Thank you, @AenBleidd. I've been able to get something working for Windows. I have a few more follow-up questions.

First, I think it makes sense to have a dirty tag. It can look like this:

Let me know if you have any comments.

Second, I currently am having Visual Studio run pre-compiler commands to obtain and store the hash, and it is writing to a new file. However, I am thinking it would be cleaner to have hashes stored in version.h in the root directory. That way there aren't separate files for one line (one file for the manager, another for the client when I get to that). However, I want to see what your thoughts are on sharing that same file. I don't want to break anything with the versioning script. I would think I could search and overwrite the definition for the hash.

[AenBleidd]

@Vulpine05.

1. Why did you put 'dirty' there?
2. I don't like the idea of having this information written in the file (because in this case you will always have a changed file in our git repo that is not good). However, you can make a build time variable, that will be passed during the build as a parameter, and during the build itself you can use when it's set, and skip when not. In this way you don't need to change any file during the build phase, and also it will be done in the same way as it done now for Android.

[Vulpine05]

@AenBleidd,

1. That way if anyone is troubleshooting a build, they can determine if the source is modified with uncommitted code. Probably not a frequent problem, but it can provide a sanity check.
2. Ah, I see what you're saying. That makes sense about not having a file modified all the time. Let me take a closer look at that with the Android build.