chore: make version embedding more robust #451
Merged
Conversation
This file contains 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
google-cla
bot
added
the
cla: yes
Codecov Report
@@ Coverage Diff @@
## master #451 +/- ##
=============================================
+ Coverage 59.20% 80.63% +21.43%
- Complexity 19 1116 +1097
=============================================
Files 2 106 +104
Lines 125 6942 +6817
Branches 18 369 +351
=============================================
+ Hits 74 5598 +5524
- Misses 34 1145 +1111
- Partials 17 199 +182
Continue to review full report at Codecov.
|
igorbernstein2
changed the title
igorbernstein2
force-pushed
the
robust-version
branch
from
13b4dc3 to
696dc80
Compare
The previous approach used the jar manifest. Unfortunately that approaches falls apart when the consumer shades the client jar. The new approach uses a combination of releasetool's version tag replacement and maven-resources-plugin to generate a class with an embedded version string.
igorbernstein2
force-pushed
the
robust-version
branch
from
696dc80 to
f6dd067
Compare
product-auto-label
bot
added
the
api: bigtable
kolea2
previously approved these changes
Oct 16, 2020
kolea2
reviewed
Oct 16, 2020
| // Note: this file MUST be named GoogleUtils.java so that it can be picked up by releasetool | ||
| public class GoogleUtils { | ||
| public static final String BIGTABLE_CLIENT_VERSION = | ||
| "1.16.1-SNAPSHOT"; // {x-version-update:google-cloud-bigtable:current} |
There was a problem hiding this comment.
@chingor13, to get this to work, I'm guessing we need to add a path here? https://github.com/googleapis/release-please/blob/master/src/releasers/java-yoshi.ts#L182 Any thing else?
This reverts commit 22d831c.
kolea2
approved these changes
Oct 16, 2020
|
As discussed offline: This is a temporary solution. In the future we will stop relying on maven resource filtering and instead hardcode the version and bump it by release-please |
|
It's worth understanding why the customer was shading, and removing the need for that. |
ad548
pushed a commit
to ad548/java-bigtable
that referenced
this pull request
Mar 13, 2021
* chore: make version embedding more robust The previous approach used the jar manifest. Unfortunately that approaches falls apart when the consumer shades the client jar. The new approach uses a combination of releasetool's version tag replacement and maven-resources-plugin to generate a class with an embedded version string. * Simplify by using a file allowlisted in release-tool * Revert "Simplify by using a file allowlisted in release-tool" This reverts commit 22d831c.
igorbernstein2
added a commit
to igorbernstein2/java-bigtable
that referenced
this pull request
Apr 9, 2021
Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in googleapis#451
igorbernstein2
added a commit
that referenced
this pull request
Apr 13, 2021
* chore: improve embedded version handling Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in #451 * migrate to new version scheme * rename back to Version * config release-please for version bumps * make sure file doesnt get clobbered * add a couple of tests * fmt
kolea2
pushed a commit
to kolea2/java-bigtable
that referenced
this pull request
May 20, 2021
* chore: improve embedded version handling Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in googleapis#451 * migrate to new version scheme * rename back to Version * config release-please for version bumps * make sure file doesnt get clobbered * add a couple of tests * fmt (cherry picked from commit 1af8925)
kolea2
added a commit
that referenced
this pull request
May 21, 2021
* chore: improve embedded version handling (#715) * chore: improve embedded version handling Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in #451 * migrate to new version scheme * rename back to Version * config release-please for version bumps * make sure file doesnt get clobbered * add a couple of tests * fmt (cherry picked from commit 1af8925) * update version * fix test * fix: add back in extraFiles and fix file path (#833) (cherry picked from commit f914954) * fix test Co-authored-by: Igor Bernstein <igorbernstein@google.com>
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.
The previous approach used the jar manifest. Unfortunately that approaches falls apart when the
consumer shades the client jar. The new approach uses a combination of releasetool's version tag
replacement and maven-resources-plugin to generate a class with an embedded version string.