You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: move synthtool templates to library_generation/owlbot (#2443)
This PR transfers the java-specific templates from synthtool to
`library_geneation/owlbot`
There is a new branch in synthtool
(googleapis/synthtool#1923) that has the removed
templates.
The intention is to keep that synthtool branch as parallel until we
fully roll out the hermetic build workflows to both HW libraries and the
monorepo.
### Approach
We add a list of template exclusions to the configuration yaml and call
`java.common_templates` with a custom template path (pointing to our
OwlBot Java Postprocessor implementation here in `library_generation`
plus the template exclusions found in the yaml.
The list of exclusions were obtained from owlbot.py files. Since
google-cloud-java has the same exclusions for all libraries, we use a
repo-level configuration entry. An example of template excludes is:
https://github.com/googleapis/sdk-platform-java/blob/b0a57b70d589e2bdc6e5fcb8cf64d08c3496bc57/java-iam/owlbot.py#L26-L37
### Different approach possible?
We could modify all owlbot.py files to use something other than
`java.common_templates`. For example
```
from custom_owlbot import common_templates
...
common_templates(excludes=[/*preserved excludes*/])
```
With such approach, we would not have to parse owlbot.py files and take
advantage of the fact it's an executable script.
## Follow up?
We probably don't want to call `common_templates` twice, so it may be
better to modify owlbot.py files to reference our own implementation
instead of synthtool. (This is similar to "Different approach possible?"
but it is more of a follow up once the scripts are live).
---------
Co-authored-by: Joe Wang <[email protected]>
0 commit comments