googleapis / sdk-platform-java

Tooling and shared libraries for Cloud SDK for Java
https://cloud.google.com/java/docs/bom
Apache License 2.0
68 stars 53 forks source link

Implement downstream javadoc generation test on sdk-platform-java #2380

Open alicejli opened 10 months ago

alicejli commented 10 months ago

To help catch javadoc errors upstream, implement a downstream check on the generator similar to this one: https://github.com/googleapis/java-shared-config/pull/662/ that checks javadoc generation on a couple of libraries to ensure javadoc generation works.

In terms of what the javadoc generation should test for:

1) The current cloud RAD generation uses Java11 with this doclet: https://github.com/googleapis/java-docfx-doclet/tree/main/third_party.

2) In general, to account for self-service clients, the plain mvn javadoc:aggregate command should also pass. This should be checked on Java 17, and possibly Java 11 as well. If we migrate the cloud RAD generation to use Java17, then I think we don't need to check for Java11 anymore, but that will be a separate project.

blakeli0 commented 10 months ago

It does not have to be a downstream check, we can add a Gradle check to verify the generated libraries here. In addition, after Hermetic build project is completed, poms will be generated as well, hence enables us to add a mvn javadoc:aggregate check in the CI. I'll add it as a nice-to-have task for hermetic build project. cc: @suztomo @JoeWang1127 @diegomarquezp

suztomo commented 10 months ago

If we migrate the cloud RAD generation to use Java17, then I think we don't need to check for Java11 anymore, but that will be a separate project.

Isn't that just updating this line in the Kokoro job config?

env_vars: {
  key: "TRAMPOLINE_IMAGE"
  value: "gcr.io/cloud-devrel-kokoro-resources/java11"
}
alicejli commented 10 months ago

If we migrate the cloud RAD generation to use Java17, then I think we don't need to check for Java11 anymore, but that will be a separate project.

Isn't that just updating this line in the Kokoro job config?

env_vars: {
  key: "TRAMPOLINE_IMAGE"
  value: "gcr.io/cloud-devrel-kokoro-resources/java11"
}

To implement yes - but the doclet needs to be tested first that it can run correctly with Java17. I vaguely recall this added some additional methods to the generated YAML files (which may be fine, I didn't investigate). I'll try and take a look this week; if it's a quick fix then we can implement for this release cycle.

cc:@burkedavison