Adds platform path to build and detect context #134
Conversation
|
Could you explain how having |
| // validated against the checksum value provided on the Dependency and will | ||
| // error if there are inconsistencies in the fetched result. | ||
| func (s Service) Deliver(dependency Dependency, cnbPath, layerPath, platformPath string) error { | ||
| dependencyMappingURI, err := s.mappingResolver.FindDependencyMapping(dependency.SHA256, filepath.Join(platformPath, "bindings")) |
There was a problem hiding this comment.
I didn't realize that the platform path could be anything other than /platform, but I need see in the spec that that's just a default value. Random question - at what point could the platform path be set?
There was a problem hiding this comment.
Arguably a platform that isn't pack or kpack could set a different filepath as the Platform path when it invokes the lifecycle and then hardcoding this like we have wouldn't work.
The CNB spec includes a few extensions that expose information to buildpacks via the Platform path. Having access to that path in a buildpack would be useful for those buildpacks to integrate with those extensions if they needed to. |
ryanmoran
force-pushed
the
platform-path
branch
from
3c5eb62
to
b17b4b8
Compare
Could you point me to an example in the spec, please? |
|
The Bindings Extension spec is a good example of this: https://github.com/buildpacks/spec/blob/main/extensions/bindings.md. |
- moves types referenced in build and detect contexts into their own files to make it a bit easier to find them when navigating the repo - adds new postal.Service.Deliver method that allows the user to pass in a platform path location. The existing postal.Service.Install method reuses Deliver with a hardcoded platform path of /platform and is marked as deprecated
ryanmoran
force-pushed
the
platform-path
branch
from
b17b4b8
to
17afdab
Compare
Summary
The location of the platform metadata is given to the build and detect processes when they are invoked. This location includes details about user-provided environment variables and other platform extensions that we might want buildpack authors to take advantage of. This addition includes that filesystem location as a parameter on both
DetectContextandBuildContext.In the process of including this new context, I found that the platform location was hardcoded in the existing
postal.Service.Installimplementation. I've included a newpostal.Service.Delivermethod that allows for the platform path to be given as an argument. The existingInstallmethod will reuse theDelivermethod with a hardcoded platform path to maintain backwards compatibility. TheInstallmethod has also been marked as deprecated.Additionally, as I was including a new type that spans both
DetectandBuild, it made sense for that type to live in its own file. Once I did that, I thought maybe all the types that aren't directly used in the immediateDetectorBuildfunctions ought to have their own files to make them a bit easier to find. So, this also includes a bunch of new files that contain those types that have been moved out ofdetect.goandbuild.gointo their own files.Checklist