Infrastructure

It would be nice to have time also in About of bibisect repos. When I run master, how do I know when it was built?

Now when we have just 2 Win daily builds (which is enough), Win-x86_64@tb77-TDF/ builds should be named clear and similar to @39: with time in name (@39: master~2019-11-02_00.08.13_LibreOfficeDev_6.4.0.0.alpha1_Win_x86.msi).
It's important when one is using "Separate Install GUI" to see if build is updated, should it be downloaded. That's not the same as time in About dialog, this is in addition.
Now @77 is just "LibreOfficeDev_6.4.0.0.alpha0_Win_x64.msi".

Another issue with @77 is that Current doesn't point to the latest. Today 07.11. Current is from 16.10. and latest is 07.11. So just by looking at Current one might think build is not accurate.

Xisco, what are your thoughts on this? Something for ESC or team call?

At least the dbg builds have the date:

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: e9e41795e6b2bf680a5f74e5684b76af00bf677b
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF-dbg, Branch:master, Time: 2021-03-02_03:34:22
Calc: threaded

so the solution would be to use '--with-extra-buildid' with autogen

Florian Effenberger wrote:

Xisco Fauli Tarazona wrote:

Time and date is displayed in dbg builds from https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/current/ ( see screenshot )
However, the build id is not there. To me, and I think for QA/DEV people in general, it is more important to have the build id than the date and time. Some days, there are more than 50 commits submitted to master

If that is a demand by QA, can you raise that during the next ESC meeting and report back in this ticket?

Build ID is present in recent daily builds, same as date, see my comment 9. No need to discuss anything in the ESC meeting

Win tb77 builds don't have it and based on what Steve talked about, macOS builds don't either.

This is a rather old ticket, with a due date in Q4/2020
What's the status of this - still relevant? Who handles it, and by when?

Waiting this one and Task #3063, which was closed as a duplicate but it's not, I add a note:
seems to me that time at https://dev-builds.libreoffice.org/daily/master/current.html is time of build finish, but it should be time of build start?

For example: you see a commit from 05:00 UTC and build from 05:30, one would think that commit is in. But after download it turns out that last commit is just from 00:00, 5 hours earlier.

Timur Gadzo wrote in #note-14:

Waiting this one and Task #3063, which was closed as a duplicate but it's not, I add a note:
seems to me that time at https://dev-builds.libreoffice.org/daily/master/current.html is time of build finish, but it should be time of build start?

For example: you see a commit from 05:00 UTC and build from 05:30, one would think that commit is in. But after download it turns out that last commit is just from 00:00, 5 hours earlier.

Next to the time, you have a link to the commit, clicking on it you can see the time of the last commit included in the daily build

I would like this one to be reopened, for several reasons:

1. Copy-paste'd appearance: One often uses the text in Help|About to describe the version used. In most contexts where this text is pasted - there is no auto-linkification of the build ID, and the reader simply sees a hexadecimal string.
2. User convenience: It is not "easy" to start a browser and read a tag next to a line on the resulting web-page. That is to say, it is easy as information lookup tasks go, but as UI features go - it's hard.
3. Inaccuracy of target web page: When pressing the linkified build ID, the resulting page gives low-resolution information about the build date, e.g. "6 months ago" or "2 years ago". Yes, one can click the shortened hash and find the accurate timestamp, but that exacerbates cause (2.) further
4. Dependence on Internet connection: Sometimes, a user may wants to know when their version was built - while not connected to the Internet. That's not possible with the build ID
5. Ease of implementation: When obtaining the commit id, the build mechanism can easily also determine the commit timestamp, and plug that in as well.

So - it's a good idea to do this even if not absolutely crucial.