chore: update generation config #10955
Conversation
| local group_id=$1 | ||
| local artifact_id=$2 | ||
| local major_version=$3 | ||
| latest=$(curl -s "https://search.maven.org/solrsearch/select?q=g:${group_id}+AND+a:${artifact_id}&core=gav&rows=500&wt=json" | jq -r '.response.docs[] | select(.v | test("^[0-9]+(\\.[0-9]+)*$")) | .v' | grep ^"${major_version}". | sort -V | tail -n 1) |
There was a problem hiding this comment.
Why do we need a major_version to get the latest released version?
There was a problem hiding this comment.
We don't want to introduce major version bump to the generator in a branch.
There was a problem hiding this comment.
I'm not sure that's something should be guarded in google-cloud-java. Major version bump of the generator should be rare and it should be guarded in the sdk-platform-java. Assuming there is indeed a major version bump, the automation would not work and we have to manually update the generator version.
There was a problem hiding this comment.
Same thing for libraries bom version, it is only used for generating README, and I don't think there is a need of guarding libraries bom version update.
There was a problem hiding this comment.
This is used in supporting multi-version of gapic generator.
For example, we have two version of gapic generator, v2 and v3. In google-cloud-java, one branch (branch-a) is using v2 and another one is using v3. I think we don't want to update the generator to v3 in branch-a in this case.
There was a problem hiding this comment.
I see your point now. I think it is a good consideration and could work well for multi-JDK version scenario, but we probably don't want to guard it this way at this moment because there are other scenarios of multi-version support as well
- We could have multiple branches using the same major version but different minor version of gapic generator.
- We could have multiple branches using the exact same version of gapic generator but different protoc version.
- We may not want any automated version updates in a branch(LTS).
I think for now we can always update to the latest, and adjust our scripts as needed in the future.
There was a problem hiding this comment.
OK, I'll remove the major version limitation here. We can adjust the script when new use case arises.
In this PR:
generation_config.yaml.generation_config.yaml..github/scripts.Example run: https://github.com/JoeWang1127/google-cloud-java/actions/runs/9472827989/job/26098842644