Remove Support for Credential Helpers about lifecycle HOT 7 CLOSED

resolved by #259

from lifecycle.

I think the GCR credential helper is useful on knative+GKE so that you can avoid dealing with credentials when you're getting started.

I also think credential helper support is generally useful for supporting different authentication mechanisms on various registries.

from lifecycle.

I fear that it introduces a confusing interface on knative as the cnb build template behaves differently from other build templates and deviates from the knative docs.

Credentials are already easy for new knative build users with the ecr and gcr helper scripts in the knative templates repo.

We already support credHelpers if they are configured in the .docker/config.json if platform implementors want them.

from lifecycle.

We already support credHelpers if they are configured in the .docker/config.json if platform implementors want them.

The purpose of the cred helper support in the lifecycle is to make this easy when images are coming from different registries. The individual cred helpers don't work well together when you let them update .docker/config.json.

from lifecycle.

@matthewmcnew 's arguments make a lot of sense to me. If knative already has a suggested workflow and helper scripts that address this use case it's unnecessary and possibly confusing to maintain a separate implementation in lifecycle.

from lifecycle.

Lets chat about this via zoom. I'm not sure we want to optimize the lifecycle just for the knative case, and I'm not convinced that knative handles this well in the multi-registry case.

from lifecycle.

buildpacks/rfcs#48 should, when implemented, address this issue

from lifecycle.