Ability to contribute the layer and configure the startup even w/o the credentials binding

[saturnism]

In GCP runtimes do not need to have the credentials explicitly specified to use the debugger/profiler. Anyway to trigger this if user simply specified the module name and version?

[nebhale]

I don't believe that there's a hard requirement that credentials specifically be contributed, only that there's an indication (via a service binding) that you want to use the service. As long as the debugger and profiler libraries can find the credentials they expect from within the container (how might they do that if the user doesn't define the proper env-var or volume mount in a Deployment?) everything should work. In other words

/platform/bindings/my-service
└── type

should work (I think).

[saturnism]

In the compute environments of credentials are automatically retrieved from a well https endpoint rather than needing to read any credentials files or env var. However, we do need to specify the service name and version. So I suppose we still need to specify a build-time env var to enable this binding, but it only needs to know the service name and version.

[nebhale]

Actually it doesn't even need to know those since they're resolved at launch time, not build time. @ekcasey and I have been discussing this and we're going to remove the need for build time bindings from all buildpacks. Instead, you'll set an env-var at build time and optionally mount the binding at runtime.

[saturnism]

neat - but the value still needs a fully encoded credential content correct? is there a way to also simply set STACKDRIVER_DEBUGGER=true, and let the agent load the credential w/ its default mechanism, from a metadata server? (i.e., this mechanism does not require encoded credential content to be present in any env var / files)

[nebhale]

Yep, we'll add that as well.