test: Add a sample generate_config yaml file. #2337
Conversation
library_generation/test/resources/google-cloud-java_config.yaml
Outdated
Show resolved
Hide resolved
| #Required. | ||
| apis: | ||
| #Required. The folder name of the module. This is the destination-name in new-client.py. | ||
| - name: java-asset |
There was a problem hiding this comment.
How are we planning to deal with owlbot files owlbot.py and .OwlBot.yaml? Are we just going to assume they are in google-cloud-java/${name}?
There was a problem hiding this comment.
I think you can assume they exist for each api when the script make it to post-processing. If it does not exist, new-client.py or generate_library.sh should create it. cc: @JoeWang1127
| #Optional. | ||
| rpc_documentation: | ||
| #Required. | ||
| services: |
There was a problem hiding this comment.
What happens if there's a new version defined in googleapis?
Do we want to dynamically get the versioned path or add a service in this file?
There was a problem hiding this comment.
A new service will be added. Are new versions of APIs automatically updated now? I guess yes with proper owlbot.yaml config? if so, we may want to automatically update it with a separate process, or replace owlbot.yaml's functionality with this file. That's probably why @suztomo mentioned this idea in the meeting.
There was a problem hiding this comment.
Are new versions of APIs automatically updated now?
Yes, OwlBot cli copies all versions of the services using .OwlBot.yaml.
I'm thinking the wrapper file (the one reading the config file and generate libraries) can find versioned directory within proto_path.
proto_path in new-client.py is not a versioned directory, i.e., google/cloud/alloydb, while proto_path in generate_library.sh is a versioned directory, i.e., google/cloud/alloydb/v1.
There was a problem hiding this comment.
I think it's better to explicit list them, and/or support a wildcard configuration like google/cloud/asset/**. Because some product like Bigtable needs to include google/bigtable/admin/v2 and google/bigtable/v2, if we only supply google/bigtable, we will have to find all the services recursively and smartly, there might be some folders are excluded as well.
There was a problem hiding this comment.
I think the wildcard/regex is fine.
For example: google/bigtable/v[1-9].* and google/bigtable/admin/v[1-9].*
| #Required. | ||
| products: | ||
| #Required. Can be used for populating the folder name java-{api_shortName}. This is also the destination-name in new-client.py. | ||
| - api_shortname: asset |
There was a problem hiding this comment.
Could you write an example of java-bigtable, which combines two clients: bigtable and bigtable-admin?
library_generation/test/resources/google-cloud-java_config.yaml
Outdated
Show resolved
Hide resolved
| #Optional. This is a relative path to destination-path above. We will create a new versions.txt file if it is not specified | ||
| versions_path: versions.txt | ||
| #Required. | ||
| products: |
There was a problem hiding this comment.
Since gapic-generator-java updates don't reflect immediately in a single PR on google-cloud-java but rather gradually updating the libraries, would it make sense to have products with an optional gapic-generator-java version that could override the repo level config?
There was a problem hiding this comment.
I think that's acceptable for now, but we should remove it and have the whole repo generated with a single version of generator all the time once we switch to the new process.
library_generation/test/resources/google-cloud-java_config.yaml
Outdated
Show resolved
Hide resolved
library_generation/test/resources/google-cloud-java_config.yaml
Outdated
Show resolved
Hide resolved
library_generation/test/resources/google-cloud-java_config.yaml
Outdated
Show resolved
Hide resolved
library_generation/test/resources/google-cloud-java_config.yaml
Outdated
Show resolved
Hide resolved
| #Optional. The root folder name of generated client libraries. If empty, modules will be created under current folder, useful for single module | ||
| destination-path: google-cloud-java |
There was a problem hiding this comment.
useful for single module
By reading the comment, I'm not sure when I want to set a value for destination-path. Is the google-cloud-java repo or the java-bigtable repo a single module?
There was a problem hiding this comment.
We can have detailed instruction later. I mentioned single module because if we set destination-path to java-bigtable, the code will be generated into java-bigtable/java-bigtable, which is not ideal.
library_generation/test/resources/google-cloud-java_generation_config.yaml
Outdated
Show resolved
Hide resolved
|
blakeli0
changed the title
|
|
@suztomo @JoeWang1127 @diegomarquezp, I'm merging this PR now. Please add additional comments regarding the parameters in internal docs. @diegomarquezp Please use this as a template and add more configs for libraries/GAPICs to the file, so that it can replace |
Add a sample generation_config.yaml file for google-cloud-java.
This is intended to be a sample file to make sure we agree on the high level design of the config file. This does not intend to be a exhaustive list of parameters at this moment, we will refine the parameters along the way.