FirebirdSQL
Provide the github commit GUID that was last at the moment when snapshot creation process did start (QA-related)
Currently regular QA-runs start as cron jobs, daily, about midnight GMT. In most cases this is enough (from frequency POV) and allows to distinguish QA results with accuracy to the full number of snapshot (e.g. "6.0.0.276"). But there are cases when multiple commits occurs at one day, i.e. between two "00:00AM". And for several (or all) of them one need to get QA-results and publish them, making these reaults to be visible in firebirdtest.com page (e.g. https://firebirdtest.com/fb60/windows/ ). It is impossible to 'split' such results onto different columns without having information about last commit (GUID) that did exist in appropriate branch when GH action started to create subsequent ('intermediate') snapshot.
And, because of this, only results for last commit that occured during past day can be seen:
Please provide full GUID of commit that was last at the moment when snapshot creation started. (either by adding some small text file in the snapshot root folder (with name like 'last-commit.txt') or - better - by creation new context variable in the SYSTEM namespacee).
This is not information that belongs in the engine, so IMHO this should not be reported by RDB$GET_CONTEXT. As an aside, this is not a GUID (which has a different format), it is a commit hash
If the test is building Firebird itself (which I guess it does if you have multiple builds of snapshots), then you should be able to obtain the commit hash yourself with git rev-parse HEAD.
If the test is building Firebird itself (which I guess it does if you have multiple builds of snapshots)
No, batch scenarios (both on Windows and Linux) just download ready snapshots from GH. It was decided (about 5+ years ago) that there is no sence to spend time for re-build snapshot if we already have new one, just created and avaliable to download. Despite that i have ability to re-build any of FB 3.x ... 6.x at any time (but currently only on Windows), the problem of total time raises in that case. All snapshots (3.x ... 6.x) will be re-created for about 2 hours. And today all tests for Windows last about 6...7 hours, and they currently are not run in parallel (because we have no additional hardware resources for that). So, presense of small text file in the FB root folder would come in very handy.
IMHO hash should be substituted to some file when file is extracted. See https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes
What about add 7 letters of hash to the package names in FirebirdSQL/snapshots, like this?
Firebird-5.0.1.1348-0-xyzabcd-windows-x64.zip
What about add 7 letters
Can this be done for every major family (3.x ... 6.x) and for both Windows and Linux ? If yes then all fine.
BTW. "5.0.1.1348-0": what means "-0" (it always present after snapshot number) ?
I can do for the ones in https://github.com/FirebirdSQL/snapshots/releases, i.e. >= 4.
-0 means the package version, when the same buildno is packaged more than one time due to some problem not present in the source tree.
OK, for 3.x i can do myself (i.e. get similar left(GH_hash,7)). But only on Windows, because i have implemented appropriate batch that build snapshots. So, the only what remained 'uncovered' is Linux 3.x.
May be Alex can help in this ?
On 3/11/24 14:16, Pavel Zotov wrote:
OK, for 3.x i can do myself (i.e. get similar left(GH_hash,7)). But only on Windows, because i have implemented appropriate batch that build snapshots. So, the only what remained 'uncovered' is Linux 3.x.
May be Alex can help in this ?
Yes.
Would be ok to change the suffix (where currently it is Initial in maste) to the sha-prefix?
It should be the easier way, and actually, it avoids the confusion of use labels Beta or ReleaseCandidate for snapshot builds that are not them.
Would be ok to change the suffix
For QA scenarios this suffix ('Initial', 'Beta1' etc) no matters at all and can be replaced.
Will the current suffix be preserved for official releases? Will the sha-hash be removed from the official releases? Would the sha-hash to removed also for non-GH official releases, e.g. for v3.0.x?
On 3/12/24 08:54, Dmitry Yemanov wrote:
Would the sha-hash to removed also for non-GH official releases, e.g. for v3.0.x?
This can be done in any way we decide.
BTW, in an experiment with HQ I've added sha-hash to the name, not replaced it, i.e.: Firebird-3.0.12.33726-HQbird-c07655c.amd64.tar.gz. Certainly also not a problem to change it - but IMO removing special build name is bad idea..
Will the sha-hash be removed from the official releases?
IMO, sha-hash must present in all builds, including releases. Eventually, any release is regular snapshot, but only marked as kind of 'anchor' (i.e. it is supposed as stable, so users can install it and compare with previous versions).
Would the sha-hash to removed also for non-GH official releases, e.g. for v3.0.x?
Although I've asked about official FB, most of all this feature is required for HQbird, at least currently.
This is my intention, with the commented if being active: https://github.com/asfernandes/firebird/commit/0f2fa3988dfbb41298b7369f4ab5a9981d641a3c
Will the current suffix be preserved for official releases?
Yes.
Will the sha-hash be removed from the official releases?
Yes.
Would the sha-hash to removed also for non-GH official releases, e.g. for v3.0.x?
My change didn't alter any existing script non related to GH Actions.