fix: correct deep-remove and deep-preserve regexes - #2572
Conversation
|
@diegomarquezp We should not merge this PR before release a new version of sdk-platform-java because the common proto updates only comes in with the release. |
|
@diegomarquezp could you use this branch and generate all libraries to check whether there are other changes (it should be no change except shopping and chat). |
commented
Mar 14, 2024
Sounds good. Adding a do not merge label in the meantime |
commented
Mar 19, 2024
|
sdk-platform-java has been released already. It should be ready for a review |
Co-authored-by: Joe Wang <106995533+JoeWang1127@users.noreply.github.com>
commented
Mar 19, 2024
|
commented
Mar 19, 2024
|




In this PR we fix the
deep-removeanddeep-preserveregexes in.OwlBot.yamlfiles in the monorepo by creating a temporary.OwlBot.hermetic.yamlwith the corrected paths.Why?
Because the paths specified in
deep-remove-regexanddeep-preserve-regexstart from the library name, so if we runcopy-codefrom inside a library, these regexes won't match any files.What about deep-copy?
We don't need to correct the library path because
copy-codesends the files fromgoogleapis-gen(or our built temp folder in our case) to theowl-bot-stagingfolder. These regexes don't deal with the monorepo, they deal with the source repo, which for our case is the temp folder we build after calling generate_library. This is whydeep-copywas always being "respected".Proof
After running

python generate_repo.py generate --generation-config-yaml google-cloud-java/generation_config.yaml --repository-path google-cloud-java --target-library-api-shortname merchantapi &> out, we get