Comments (9)
Shouldn’t this just be a launch layer with a .profile.d
that sets the value?
from spec.
There's a couple problems with that: the launch layer won't be available to subsequent builds (right?) and even so a bash script won't be parseable. I'm talking about this on behalf of others who need it (I don't actually need it myself) so I'm not the best one to go into detail. I'll let @hone bring it up at a sync.
from spec.
To me it seems like:
- If it needs to be available at launch every time, persistently, then it should be set in
<launch>/<layer>/profile.d
- If it needs to be available at build every time, persistently, then it should be written to
<launch>/<layer>.toml
from spec.
Ah so I was not planning on providing the launch layers from previous builds during a build (that's what the cache is for?). We should discussion.
from spec.
The launch layers are never available in subsequent builds — just the launch layer metadata TOML files.
from spec.
@hone and @jkutner Can you please write up your understanding and close out if your comfortable with our discussion?
from spec.
Given that the <launch>/<layer>.toml
files are provided for subsequent builds (as described in Phase #2: Analysis), and assuming that a given a platform defines previous builds/OCI images as persistent, then I think <launch>/<layer>.toml
satisfies the need for persistent metadata.
But is the <layer>.toml
meant to be persistent? Would/should a new version of the lifecycle invalidate it? If so, that would be problematic for this use case. The spec is unclear i think, when it says "Was created using the lifecycle". (if we want to be unclear i think that's ok).
Related to this, the spec states "The lifecycle MUST NOT download any filesystem layers from the previous OCI image". I found this surprising given that I would expect to get the <launch>/<layer>.toml
files from the previous image. Are we suggesting that the <launch>/<layer>.toml
files are stored outside of the image?
from spec.
But is the .toml meant to be persistent? Would/should a new version of the lifecycle invalidate it? If so, that would be problematic for this use case. The spec is unclear i think, when it says "Was created using the lifecycle". (if we want to be unclear i think that's ok).
The intent was for it to be guaranteed. We could clarify the spec to specify that the platform must always restore the metadata on a rebuild of the same image unless the developer or operator explicitly indicates otherwise.
Related to this, the spec states "The lifecycle MUST NOT download any filesystem layers from the previous OCI image". I found this surprising given that I would expect to get the /.toml files from the previous image. Are we suggesting that the /.toml files are stored outside of the image?
The <launch>/<layer>.toml
files are stored as JSON metadata on the config blob, which is a component of the OCI image that isn't a layer.
from spec.
Closing as this should be covered by #37 and #35. Feel free to re-open if I missed anything.
from spec.
Related Issues (20)
- How to mount my own maven setting.xml HOT 2
- [RFC #0105] Buildpack API changes for run image extension (Dockerfiles phase 3) HOT 1
- SBOM- Cosign spec HOT 5
- Is it possible for an inline buildpack to add [[requires]] and [requires.metadata] to the build plan? HOT 1
- SBOM score HOT 2
- Regarding ENTRYPOINT Launcher HOT 4
- Lifecycle specification HOT 3
- [RFC #0111] Support insecure registries HOT 1
- Build Image ABI Compatibility
- Making builpack image extensions feature non-experimental HOT 14
- [RFC 0125] Lifecycle parallel export HOT 1
- Launcher CNB_PLATFORM_API failed to get platform API version HOT 6
- Support buildpack.toml targets for Buildpack API 0.10 HOT 1
- Platform Spec is ambiguous about usage of `extender` HOT 10
- Support run image rebase based on semver tags HOT 6
- Remove or clarify `io.buildpacks.base.id` (it's currently unused)
- Specification for `CNB_STACK_ID` changed when it was deprecated in Platform API 0.12 HOT 1
- Add a way for Buildpacks to enable verbose output HOT 5
- Buildpack API inconsistency around naming/data-type of `targets.distros.version` field in `buildpack.toml`
- Add more data to report.toml
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.