Remove custom version injection because it does not work well due to multi-module build #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…multi-module build
bbeaudreault
added a commit
that referenced
this pull request
Jul 29, 2022
# This is the 1st commit message: Add maven and RPM building in blazar This uses our standard buildpack, but each module must get a custom .blazar.yaml to pass in required properties to the build. One can distribute that .blazar.yaml using build-scripts/copy_blazar_yaml.sh. In order to minimize the duplication, most of the customizations are consolidated in build-scripts/prepare_environment.sh. The RPM build is hooked into the standard build hbase-assembly, as a post-build step. The RPM build scripts in hbase-assembly/rpm-build handle turning the assembled tar.gz into multiple RPMs. We required some minor changes to the descriptor in hbase-assembly to account for the fact that our build processes each module independently instead of as a single reactor build. As a result, moduleSet does not work, so moduleSet usages were converted to dependencySet. # This is the commit message #2: Fixes to get HubSpot build to work - Our branch version munging script set-maven-versions can't parse the pom.xml due to unicode, remove it. - Our build adds build.json files to the jars. Allowlist those files in jar content verification. We could potentially try to upstream generic versions changes of these at some point # This is the commit message #3: Add client bundles for hbase2 (#11) * Add hubspot client bundles * add cdh5 mode and build the client bundles using cdh5 hadoop and java8 for now # This is the commit message #4: Add AggregationClient to client bundle (#12) # This is the commit message #5: Shade hadoop compat classes so they can be loaded in hadoop jobs (#13)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I added this when I initially set up the hubspot build, thinking it'd be nice to reflect our actual build numbers in the various UIs, logs, etc. Unfortunately it doesn't work as well as I'd hope, because of the fact that we use multi-module build. The Version class is written by
hbase-commonmodule, which may not get built for every merged change. For example, if a change is pushed tohbase-server, that will not result in a re-build ofhbase-common. So the Version will not update and this can be misleading.There are other options we could consider for injecting our own version, but for now I'm just going to remove this so that we revert to the default behavior of just having it be the upstream version (i.e. just 2.4.6 instead of 2.4.6-hs.35)
Related to HBasePlanning#764