Export CloudMetadata?

[simolus3]

I'm trying to access other Google Cloud Services in Cloud Run, so I need to know my project id at runtime. For now I'm just getting it via an environment variable, but since this package can already look it up from the metadata server I wonder if CloudMetadata.projectId() could be exported?

[kevmoo]

Interesting idea! We can look into it!

[kevmoo]

You can also use

https://pub.dev/packages/googleapis_auth see

https://pub.dev/documentation/googleapis_auth/latest/googleapis_auth.auth_io/obtainAccessCredentialsViaMetadataServer.html
https://pub.dev/documentation/googleapis_auth/latest/googleapis_auth.auth_io/clientViaMetadataServer.html

Makes things SUPER easy!

[simolus3]

Thank you! I was already using obtainAccessCredentialsViaMetadataServer, seems like I overlooked clientViaMetadataServer.

Do you know if there's a way to extract the project id from the client? I still need to know the id to construct, for instance, a Storage from package:gcloud.

[subfuzion]

@simolus3 We were just discussing / brainstorming approaches to making functions projects cloud project-aware last week, actually, and make it easy to wire up and consume other GC services from the function. Multiple ways to skin the cat, I think, but I've been looking at this from the perspective of having some kind of project config (potentially checking for a gcloud config) at build time to configure the deployment while the framework makes it dead simple to get what's needed for function app from the environment (whether accessed as library calls or supplied via a context argument).

[simolus3]

This is a bit more than I asked for here, but I had a rather simple idea on how to provide cloud services without much effort: Maybe this package can integrate with package:gcloud and invoke functions in a service scope that provides all the high-level services and an authenticated client for those that are auto-generated.
For me, this includes using a metadata server in the managed runtime and respecting the GOOGLE_APPLICATION_CREDENTIALS environment variable for local testing, as described in the Cloud Run docs on testing.

I think that this would be a pretty neat developer experience where everything "just works" and I don't have to manually pass some context variable around. I'm happy to work on a PR if you think this is a direction worth exploring.

[subfuzion]

@simolus3 The service scope idea is pretty neat. You're always welcome to prototype ideas and contribute to the project, but I know that @kevmoo has been putting a lot of thought into this, so I'd want for him to weigh in on implementation first (this is a light week for us and he's enjoying some family time). But having your input on the desired developer experience as we all put our heads together on this really helps. Thanks!

[subfuzion]

Also, since I think my comment wasn't quite so clear, let me clarify that regardless of the metadata that can be consumed from the environment at runtime for use by your function, you still have to specify what cloud project you want to deploy into -- this is where the function project configuration that I'm talking about comes in.

Currently, we require that you install and configure gcloud (see the repo docs). I'm thinking that we could probably hide this step from users, while still respecting the gcloud configuration, if there is one.

[subfuzion]

@simolus3 I'm prototyping a mini-CLI to make working with a Dart Functions Framework project easy. Imagine a deploy command that accepts a --project ID argument, but if not supplied, also checks the active gcloud configuration and possibly a hypothetical project-local configuration, like this:

.function.yaml

project: demo-project
region: us-central1
runtime: gcf  # or cloudrun