fix: Fixed object paths in autogenerated code in owlbot.py #804
Conversation
product-auto-label
bot
added
the
api: logging
| # For autogenerated sample code, resolve object paths by finding the specific subpackage | ||
| # the object belongs to. This is because we leave out all autogenerated packages from the | ||
| # __init__.py of logging_v2. For now, this is manually copy-pasted from the __all__s of each | ||
| # subpackage's __init__.py. |
There was a problem hiding this comment.
we discussed the possibility of eventually restructuring the gapic/veneer files into different folders, which should remove the need for this fix, right?
It might be a good idea to open a bug for that and add a link to the comment here
There was a problem hiding this comment.
Depending on how the gapic/veneer files are structured we might need to have a different fix for replacing logging_v2 with something like logging_v2.gapic, but yeah we wouldn't need a dictionary structure like it is now.
|
|
||
| # Initialize request argument(s) | ||
| request = logging_v2.CopyLogEntriesRequest( | ||
| request = logging_v2.types.CopyLogEntriesRequest( |
There was a problem hiding this comment.
One thought: these generated samples aren't covered by tests. Have you considered adding tests for these to catch this kind of issue in the future, like the other snippets? Smoke tests could be helpful here (i.e. just executing each function and making sure nothing crashes)
There may be a simple way to programmatically load and execute each sample, but if it's bit more complicated we could open a bug for later
gkevinzheng
added
kokoro:run
yoshi-kokoro
removed
the
kokoro:force-run
Fix object paths by doing a find/replace operation in
owlbot.py, since the gapic objects are not included in the__init__.pyofgoogle.cloud.logging_v2.Fixes #582