Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-12583

Bake the Githash and other info into the binaries

Details

    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

          Ascending order - Click to sort in descending order
          serg Sergei Golubchik added a comment -

          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.

          serg Sergei Golubchik added a comment - 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.
          elenst Elena Stepanova added a comment -

          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.

          elenst Elena Stepanova added a comment - 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.
          valerii Valerii Kravchuk added a comment -

          If me merge some trees, like CONNECT, the details from them should also be presented.

          valerii Valerii Kravchuk added a comment - If me merge some trees, like CONNECT, the details from them should also be presented.
          wlad Vladislav Vaintroub added a comment -

          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

          wlad Vladislav Vaintroub added a comment - 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
          anikitin Andrii Nikitin (Inactive) added a comment -

          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.

          anikitin Andrii Nikitin (Inactive) added a comment - 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.
          wlad Vladislav Vaintroub added a comment - - edited

          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

          wlad Vladislav Vaintroub added a comment - - edited 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

          People

            wlad Vladislav Vaintroub
            alvinr Alvin Richards (Inactive)
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.