Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
Description
Problem
From a given install (tarball, RPM, DEB) you only have the version information available, not the GitHash the binaries were built from.
Solution
Compile the following into the binaries
- GitHash the build was from
- Buildbot build number
This info should be available as
- system variable (e.g. VERSION_GITHASH) - Must
- from output of 'mysql -v' (but that's just the githash of mysql and not mysqld) - Should
- from output of 'mysqld --verbose --help' - Must
Rationale
Supportability. Given a random build a user may have, there is no simple mechanism to track back to the GitHash of the commit the code was built with. This is especially important for anybody with a custom build (e.g. feature testing, customer patch etc.).
Workaround
None
Attachments
Activity
If I understand purpose of this MDEV properly - then current solution "Bake the Githash" is not enough to collect information about build, because different branches (e.g. 10.2 and bb-10.2-ext) may show the same version() and the same version-source-revision.
So among "the other info" we need to be able identify source branch name as well , so users can easier distinguish from which branch current instance originates.
The new server "variable" (i.e a constant) is called 'version-source-revision", so it does not depend on git (who knows what source control we'll use in the future)
mysql -V would akso show the revision number
If me merge some trees, like CONNECT, the details from them should also be presented.
Worse still, it should probably be both if possible, because there can be (and there are) also custom builds of different sorts which might come directly from git, and those are most difficult to track.
Note, that most binaries are built from a source tarball, not from a git repository.
So, a git hash must be generated when a source tarball is created, and stored somewhere in a file that is part of the source tarball.
branch does not matter really, git commit hash describes the entire source code repository "as of" when this hash was HEAD.
I can branch current 10.1 and push it as bb-10.1-wlad, and yes it will have the same top git hash. But it does not matter, because the source is exactly the same source as 10.1