fix: java generation #673
fix: java generation #673
Conversation
We had to update packaging rules in bazel build recently. The change was supposed to be backward-compatible, but the way synth was unpacking the tar made it backward-incompatible. Specifically, previously the final `.tar.gz` file produced by bazel packaged files in the following format (i.e. this is how the output of `tar -tvf google-cloud-oslogin-v1-java.tar.gz` would look like, using oslogin as an example): ``` ./google-cloud-oslogin-v1-java/gapic-google-cloud-oslogin-v1-java/... ``` Witht the recent change the output of the same build target will look like: ``` google-cloud-oslogin-v1-java/gapic-google-cloud-oslogin-v1-java/... ``` I.e. they should be identical essentially, because the `./` prefix in the first example is a no-op for unpacking. But it still counts as a "component" if `"--strip-component=1"` command line arg is used. Due to technical reasons adding back the `./` prefix in bazel is difficult and would make the rules inconsistent, adding it to synthtool instead.
google-cla
bot
added
the
cla: yes
|
@chingor13 PTAL. |
|
There are also related changes to fix stuff on mac googleapis/gapic-generator#3255 (not required for linux builds) |
| @@ -190,7 +190,7 @@ def _generate_code( | |||
| "tar", | |||
| "-C", | |||
| str(output_dir), | |||
| "--strip-components=1", | |||
| "--strip-components={}".format("0" if language == "java" else "1"), | |||
There was a problem hiding this comment.
Thanks for the terrific PR description.
I see this will fix it, but I'm concerned that synthtool is so fragile that it can't accept the small change in paths. I'd like to investigate why synthtool is choking in the new paths for an hour or two.
|
I tried generating java-asset, and I see the path being passed to move() is: However, the directories that were created were: |
|
So, specifically, the directory |
|
fixed with alternative code #675 |
We had to update packaging rules in bazel build recently. The change was supposed to be backward-compatible, but the way synth was unpacking the tar made it backward-incompatible.
Specifically, previously the final
.tar.gzfile produced by bazel packaged files in the following format (i.e. this is how the output oftar -tvf google-cloud-oslogin-v1-java.tar.gzwould look like, using oslogin as an example):Witht the recent change the output of the same build target will look like:
I.e. they should be identical essentially, because the
./prefix in the first example is a no-op component in the path when you unpack tar normally. But it still counts as a "component" if"--strip-component=1"command line arg is used.Due to technical reasons adding back the
./prefix in bazel is difficult and would make the rules inconsistent, adding it to synthtool instead (since the bug is essentially reproducible only if--strip-componentarg is used).