build: add a build tag into the version for non-release builds #156
Comments
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the branch name can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
|
This tag is now passable and in the collected metadata. |
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
|
Is there a better way of doing this? On my machine this adds 60+ seconds to the make command before we start even start the build. Is there other information we can collect or a means to collect it faster? On branches that were committed, the "build date" should have been close to what was required -- it is supposed to capture the date/time of the last git commit. Also, this PR modifies the "RocksDB version" string when I believe it means to modify the "Speedb" one... |
|
Is the slowdown happening even in incremental builds, or only after a As for the version, we actually only have a Speedb version string, since this function is only used for outputting to the LOG file and the tools help text, so we don't really care about backward compatibility, and the format is |
|
The slowdown happens every time.
The tag that is generated is also kind of strange. It is meaningless to me: |
|
Woops. I just realised that you also correctly spotted the issue with the version string. I assumed that you meant the |
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The change set includes: 1) A header file that contains the Major, Minor, and Patch versions of speedb as a macro, as well as a set of functions returning info about how/when/where this version of speedb was created. also includes all changes done on build_version.cc.in in the following commits: 1. version: remove superfluous build property The `speedb_build_spdb_key` property is unused and was accidentally imported as part of #1. 2.general: replace RocksDB references in strings with Speedb (#64) This includes references in statuses as well as tools output. 3.build: add a version build-tag for non-release builds (#156) The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead. build_version: apply the build tag to the Speedb version string (#231) 4. The changes in #157 were accidentally applied to the `GetRocksVersionAsString()` function instead of the `GetSpeedbVersionAsString()` function. This replaced the RocksDB patch number with the Speedb one, and added the build tag in the wrong place. Fix it by moving the logic to the intended function.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
The build tag can be set during the build (using either the Makefile or the CMake). If it's not provided, and we're not in a release build, it will be calculated using the state of the git tree since the last release tag (for example, for this PR the build tag will be calculated as `(main+17)-(156-build-add-a-build-tag-into-the-version-for-non-release-builds+1)`. If the git tree state can not be determined, a question mark will be used instead.
For various tasks (especially for the performance tests) we sometimes need to compare builds and tell how they are ordered in the git tree. The current version number is not enough because it's only changed on releases, and while the git hash uniquely identifies a build, it requires access to the git tree in order to find that information, and it becomes useless if the specific commit is later amended or deleted from the tree altogether.
Add an optional build tag to the version and allow setting it during the build (or at configuration time, if using CMake). If it's not set, use a script to calculate a build tag based on the git tree since the last release, falling back to a build tag of
?in case we aren't able to determine the git tree, which would basically mean that this isn't a release build, and that the git hash should be manually checked as we do today.The text was updated successfully, but these errors were encountered: