lifecycle
lifecycle copied to clipboard
Lifecycle Prepare Phase
Overview
This is a proposal for a Lifecycle prepare
phase
Goals
- Parity with Pack: A Lifecycle Prepare phase should make it easier for Platform Implementers to achieve parity with features of Pack. Today, features like project.toml are only supported by Pack, and a new platform would need to write it’s own parser.
Specifications
A new Lifecycle phase and associated binary should be available to Platform Implementers, and should be executed by Pack.
Milestones
- RFC - The new phase must be proposed as an RFC, and must describe concerns beyond Inline Buildpacks. The RFC should justify the existence of the new phase
- Specification - After the RFC is approved, the required specification changes will need to be made to the Platform Spec.
- Implementation - Finally, the specification must be implemented in the Lifecycle.
- Update Pack - The Pack CLI should be updated such that it invokes the new Lifecycle phase.
Prior Art
- An early version of RFC-0075 included a Prepare Phase.
Hi, I would like to work on this project! Do you have any tips or starting points for a newcomer? Thanks in advance
Hi @shatoboar - apologies for the slow reply. I am sure @jkutner will have more to add, but here are some thoughts that come to mind for now:
- In addition to RFC-0075 mentioned above, it might be helpful to look at the RFC for project descriptor: https://github.com/buildpacks/rfcs/blob/main/text/0019-project-descriptor.md to get a sense of what the project descriptor is trying to enable
- Since we are trying to achieve parity with pack, it might be helpful to look at the pack code that parses project descriptor: https://github.com/buildpacks/pack/blob/f6b78274f8f6aa5c659db509a14230f1d1610abc/internal/commands/build.go#L66 could be a good place to start
- As the first milestone in the project is to submit an RFC for the prepare phase, you might consider reviewing the RFC template: https://github.com/buildpacks/rfcs/blob/main/0000-template.md to begin thinking what might go there (we would definitely help you iterate on the proposal!)
Let us know how that sounds. We're happy to provide any further guidance as needed. For more real-time support, you could also reach out in Slack: https://slack.buildpacks.io/
Hi, I am using pack-cli and buildpacks on my daily development projects. This feature is sounds very good to me. I would like to work on this issue, I will read your tips. Is there any channel on slack or should i send direct message you ?
Is there any way to specify buildpacks like pack build ... -b bp1 -b bp2
till now?
Hi @uqix you can currently specify buildpacks in project.toml: https://github.com/buildpacks/spec/blob/main/extensions/project-descriptor.md#buildbuildpacks which is supported by pack.
With respect to the lifecycle "prepare" phase and how that might interact with project.toml - lately there has been much discussion within the project about this topic, with various competing and/or complementary RFCs. I believe @jromero has a forthcoming RFC that will try to tie various ideas together. In the meantime, here are the ones that are out there:
- https://github.com/buildpacks/rfcs/pull/189 - pack.toml RFC
- https://github.com/buildpacks/rfcs/pull/191 - buildpacks config RFC
- https://github.com/buildpacks/rfcs/pull/182 - project.toml converter RFC
Is there any way to specify buildpacks like
pack build ... -b bp1 -b bp2
till now?
If I'm not mistaken, providing buildpacks to the lifecycle would take the form of providing an order.toml
which is already part of the API.
RE: project.toml
Latest rendition of a proposal (still very much WIP) is here: https://hackmd.io/4LGBHOZAQ6GMOTeDf2U3_w#Platform-Configuration
@jromero thanks, problem solved by order.toml
.
FYI, we use this order.toml
to build frontend image with yarn and nginx:
[[order]]
[[order.group]]
id = "paketo-buildpacks/nodejs"
version = "0.12.0"
[[order.group]]
id = "paketo-buildpacks/nginx"
version = "0.5.2"
Blocking this on https://github.com/buildpacks/rfcs/pull/202