Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alicejli opened this issue Jan 18, 2024 · 3 comments
Open

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

alicejli opened this issue Jan 18, 2024 · 3 comments
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: process A process-related concern. May include testing, release, or the like.

Comments

@alicejli
Copy link
Contributor

To help catch javadoc errors upstream, implement a downstream check on the generator similar to this one: googleapis/java-shared-config#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
Copy link
Collaborator

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

@blakeli0 blakeli0 added type: process A process-related concern. May include testing, release, or the like. priority: p2 Moderately-important priority. Fix may not be included in next release. labels Jan 18, 2024
@suztomo
Copy link
Member

suztomo commented Jan 23, 2024

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
Copy link
Contributor Author

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

@blakeli0 blakeli0 added priority: p3 Desirable enhancement or fix. May not be included in next release. and removed priority: p2 Moderately-important priority. Fix may not be included in next release. labels Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: process A process-related concern. May include testing, release, or the like.
Projects
None yet
Development

No branches or pull requests

3 participants