[gcp-auth-extension]: Try resolving GCP_PROJECT from Google credentials if not provided

[gustavovnicius]

Description:

Enhancement - Try resolving GOOGLE_CLOUD_PROJECT value using google-cloud-sdk.

Having a mandatory GOOCLE_CLOUD_PROJECT configuration is unnecessary, given the extension already depends on ADC context existing. It can try to infer the project from it.
Still mandatory to have a project id, but this gives more flexibility in the usage of the extension.

Existing Issue(s):
#2102

Testing:

Refactored the project id resolver logic into a separate method, including the more comprehensive ServiceOptions resolver. Tested the method for both the current strategy and falling back to ServiceOptions, also added a missing test for not being able to find the option and throwing an exception.

Documentation:

GOOGLE_CLOUD_PROJECT configuration was moved into the optional config section, with a note that even though it's optional, the extension needs it either provided or being able to infer it.

Outstanding items:

N/A

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: gustavovnicius / name: Gustavo Bastos (3e3c17b)

[otelbot-java-contrib]

❌ The result from spotlessApply could not be committed to the PR branch, see logs: https://github.com/open-telemetry/opentelemetry-java-contrib/actions/runs/16990756319.

[otelbot-java-contrib]

❌ The result from spotlessApply could not be committed to the PR branch, see logs: https://github.com/open-telemetry/opentelemetry-java-contrib/actions/runs/16990824329.

[gustavovnicius]

Any outstanding blocker about this one?

[trask]

cc @psx95 @jsuereth

[psx95]

Any outstanding blocker about this one?

Thanks for the PR @gustavovnicius! My only concern here is to take on the additional google-cloud-core dependency. My reasons behind this are -

• google-cloud-core is a huge dependency and pulls in additional transitive dependency for an artifact that is supposed to be light-weight and currently only has a single dependency.
• I think this problem should be solved at the google-auth-library-java level seeing as other language implementations for this library have already solved this issue (e.g. Python, Golang).

I am engaging internally with the folks maintaining the auth library to see if this request can be resolved at the Java auth library level.

[gustavovnicius]

Thanks for the thoughtful feedback, @psx95 totally agree that we should be cautious with new dependencies.

I did a quick dependency analysis to verify the real impact of adding google-cloud-core.
The entire resolved dependency set it introduces is:

com.google.api.grpc:proto-google-common-protos:2.61.3  
com.google.api.grpc:proto-google-iam-v1:1.56.3  
com.google.api:api-common:2.53.3  
com.google.api:gax:2.70.3  
com.google.auth:google-auth-library-oauth2-http:1.39.1  
com.google.protobuf:protobuf-java-util:4.32.1  
com.google.protobuf:protobuf-java:4.32.1  
org.threeten:threetenbp:1.7.0

That’s ~8 small, standard Google client libraries already present in most GCP integrations, not a large footprint (roughly < 1 MB of total JARs), there's a big overlap with transient dependencies of google-auth-library-java.

I agree it would be ideal if google-auth-library-java natively provided this piece, and I’m all for following up upstream. But in the meantime, this dependency to me seems like a low-impact one.
Happy to adjust if the maintainers of google-auth-library-java do end up incorporating this functionality directly.

Another thought is regarding downstream adoption: Without it, the extension in some situations is virtually useless, as the sheer amount of changes and effort to adopt it across the board, far outweighs the extension.

[psx95]

@gustavovnicius, while the number of JARs being pulled is only 8, most of them are not being used (the auth library being the exception) and while the combined size of them is 1MB which might look small, it is extremely huge when you compare it to the size of this artifact's JAR itself which is roughly ~10KB.

FWIW, I do agree that this is a fair ask and there is already a draft PR to expose the Project ID from the Auth Library.

I think we should follow the progress of this draft PR and make changes in this extension once the feature is available.

[gustavovnicius]

New version has been adopted and project id is attempted to be resolved based on credentials. @psx95

[psx95]

Thanks for the PR!
Left a couple of suggestions that might be helpful.

[gustavovnicius]

Hey folks, anything left to do on this one? I'll gladly change it. If there's nothing left I'd really appreciate it if we could get it merged

[gustavovnicius]

@psx95 ?

[psx95]

Hi @gustavovnicius,
Apologies for the delay on this, and thank you for the changes, they look good to me now, just suggested a few changes in the test, mostly about adding a few edge cases and updating the documentation there.

We should be good to merge after this 👍🏻
Thanks again for your contribution and patience!

[gustavovnicius]

I believe I covered all your comments @psx95

[psx95]

LGTM!

Thank you for the contribution and your patience! 👍🏻