paketo-buildpacks / libpak

An opinionated extension to the libcnb Cloud Native Buildpack Library
Apache License 2.0
15 stars 17 forks source link

Use BuildModuleMetadata rather than Buildpack specific structs #271

Closed BarDweller closed 1 year ago

BarDweller commented 1 year ago

Summary

NewConfigurationResolver was still requiring Buildpack when it's impl was agnostic re buildmodule type. Update signature to allow for BuildModuleMetadata to be passed (obtainable via NewBuildModuleMetadata(...))

NewDependencyResovler was requiring BuildContext, when its impl requried metadata/id, Update signature to allow for BuildModuleMetadata to be passed, with string id.

NewDependencyCache was requiring BuildContext, when its impl was agnostic Update signature to accept info used from context, to allow usage with Extension or Buildpack.

This PR also moves libpak 2.x up to the latest libcnb 2.x, which brings in the logging change for debugWriter. libpak.bard had a testcase checking if log.debugWriter returned nil when debugging was not enabled, which is no longer true. It is safer now for log.debugWriter to return an io.Discard based writer than nil, indirectly related to the change of libcnb.log.Logger from a struct (in release-1.x as poet.Logger) to an interface. In any case, the testcase in libpak was not testing libpak code, but was directly driving libcnb code, so it has been removed.

Use Cases

This enables config/dependency resolvers to be created from Extension metadata, and Buildpack metadata equally, by having the caller create the BuildModuleMetadata instance via NewBuildModuleMetadata before invoking NewConfigurationResolver/NewDependencyResolver

DependencyCache can be created using info from the BuildContext/GenerateContext. Test case updated appropriately

Checklist