You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: text/0000-prepare-operation.md
+83-72Lines changed: 83 additions & 72 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,7 @@
12
12
# Summary
13
13
[summary]: #summary
14
14
15
+
It is common for platform to execute common operations before executing the lifecycle. These sort of operations include, downloading buildpacks, making changes the the `order.toml`, cleaning up the workspace, and more. These operations are typically influenced by configuration. One of those common configuration inputs is the `project.toml` (aka Project Descriptor). This RFC, proposes a contractual interface for a Prepare operation that is executed before the Build operation. The benefits for doing so are it enables common functionality to be made portable. Additionally, it allows the project to provide guidance on what the expected behaviour is regarding input configuration such as the `project.toml`.
15
16
16
17
# Definitions
17
18
[definitions]: #definitions
@@ -63,12 +64,11 @@ Therefore the following changes have been made from the [latest schema][pd-02]:
63
64
64
65
### Version `io.buildpacks` namespace
65
66
66
-
Given that the project descriptor's `io.buildpacks` namespace is directly tied to the platform by the fact that it's the platform that needs to consume and parse it, it makes sense to unify the version of the schema with that of the platform API.
67
-
67
+
The `io.buildpacks` namespace schema should be able to change without changing the Project Descriptor spec. For this reason, the namespace should define a `schema-version`.
68
68
69
69
### Schema
70
70
71
-
See [Platform Spec changes](#Platform-Spec).
71
+
See [`io.buildpacks` Namespace Schema](#io-buildpacks-Namespace-Schema) section below.
72
72
73
73
#### Usages Examples
74
74
@@ -166,7 +166,6 @@ The default implementation COULD take care of applying the following configurati
166
166
- This is mitigated by providing [utilities](#Cloud-Native-Buildpacks-utilities) and the fact that the prepare phase is an independant and swappable.
167
167
2. Executing the Prepare operation may require an additional container to be spun up in some platforms; this would effectively increase the overall build process.
168
168
169
-
170
169
# Alternatives
171
170
[alternatives]: #alternatives
172
171
@@ -205,6 +204,8 @@ The idea of a buildpack that can apply configuration from `project.toml` has bee
205
204
- Should arbitrary properties be allowed in `io.buildpacks.defaults`?
206
205
- How does the Prepare operation make changes to non-filesystem options such as `tags`, `run-image`, etc?
207
206
- Ideally, the lifecycle would have a filesystem based interface that we can leverage. This would prevent the preparer from having it's own independant mechanism. A prior RFC for something similar has existed (see [Add Lifecycle Config File RFC][lifecycle-config-rfc]). It may be worth revisiting.
207
+
- Where do we define the `io.buildpacks` namespace if we want to keep it seperate from the Project Descriptor Spec?
208
+
- We've been wanting to restructure our spec repo to include other schemas, in JSON format, as well. Maybe this is an opportunity to rethink our repo structure.
0 commit comments