Open natalieparellano opened 4 years ago
With the latest release of the lifecycle, we can just pull the latest release and that should work (with interoperability between different platform apis)
@natalieparellano Can I take this issue? Could you provide more info about how pack will exclusively use the Lifecycle API versions instead of the release versions?
Description
pack currently has knowledge of specific lifecycle versions:
To check compatibility: https://github.com/buildpacks/pack/blob/00912f739e275ee7c4d0a87ca3f1f040a46ebba0/build.go#L38-L40
To set the default lifecycle: https://github.com/buildpacks/pack/blob/00912f739e275ee7c4d0a87ca3f1f040a46ebba0/internal/builder/lifecycle.go#L18
pack acceptance tests currently exercise the latest released lifecycle and the latest patch of the previous minor: https://github.com/buildpacks/pack/blob/00912f739e275ee7c4d0a87ca3f1f040a46ebba0/acceptance/config/github_asset_fetcher.go#L198-L201
Proposed solution
pack should not know about specific lifecycle versions and should instead use lifecycle api versions when determining compatibility of various things.
When we download the lifecycle image (untrusted builder scenario), we should download the latest lifecycle that supports the api required by the builder.
Describe alternatives you've considered
Leave things the way they are.
Additional context
We might still need
DefaultLifecycleVersion
or maybe we want to always download the latest lifecycle that implements a given api (see #202)We could get rid of
prevLifecycleVersionSupportingImage
andminLifecycleVersionSupportingImage
by always attempting to download the image and failing only if the download fails.For
minLifecycleVersionSupportingCreator
, this was added because lifecycle versions 0.7.0-0.7.3 had a bug with the creator when run with-skip-restore
. Maybe it's okay to just let it fail. Those versions of the lifecycle are now pretty old.