-
Notifications
You must be signed in to change notification settings - Fork 293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: Download a snapshot release of the lifecycle #1305
Comments
So, the suggestion is that you can create a builder with a lifecycle specified as an image tag? specified just like you can with Or is it, more simply, that you can create a builder with a uri to a custom lifecycle archive? Because that's already possible to today, via the |
@aemengo do you mind if I move this issue over to pack? It's been a while since I checked, but I believe that the Edit: this would avoid the need to compile or separately locate and download the lifecycle artifact for that SHA. |
@natalieparellano I don't mind. @cmoulliard To be clear, we're curious if the |
Yes ;-) |
The limitation of the current approach is that it is needed to re-build a new builder image if we would like to use, when we will do a build, lifecycle creator v1.0 or v1.1 or v1.0-SNAPSHOT or v1.0-rc1 .... We dont have this problem using |
I'm looking about something more to avoid to have to build a new builder image if I would like to use a different lifecycle creator |
@cmoulliard Ok, thank you for clarifying. So the suggestion is the builder can change the lifecycle in use (via a tag), at runtime? during the build? And this can happen independent of the pack CLI, it can happen on all platforms? say on Kubernetes? I think this might call for a spec change, perhaps an RFC. |
Do I miss a step. I built a new lifecycle and created a tgz file but process to create the
Steps
|
Ah, use |
No luck
|
For whatever reason the lifecycle.toml file is only created in the packaging step, so it will be part of I provided the incorrect command before, |
Ideally, at runtime, when by example we execute a build using a container, pod and where we would like to override the lifecycle pakaged within the image |
@cmoulliard |
This is not what I'm asking. What I would like is to be able to specify the version of the lifecycle to be used when a pod is doing a build.
That will certainly then need that a pre-step is added (= initContainer) to load the needed go binary before to launch the build ... |
Again, it's still not clear what you want. If you:
|
Thanks. That did the job :-)
WARNING: The message logged using the verbose mode by That should be improved as the only way now to figure out which version is packaged is to do:
|
uri is enough. Isue: uri do not work for the lifecycle property if we pass an image
--->
|
@cmoulliard Write RFC |
Hi @cmoulliard Checking this issue, I think the issue now is that you find a bug referencing an lifecycle image using the In that case, I can remove the |
Yes |
Closing as a duplicate of #2076 |
Description
When we would like to use a different lifecycle release from the list of the published releases - see: https://github.com/buildpacks/lifecycle/releases), then we can set the property
version
within the
builder.toml
file to include it within the builder image :Such a version will then generate a request to download the following artifact "
Downloading from https://github.com/buildpacks/lifecycle/releases/download/v0.12.0/lifecycle-v0.12.0+linux.x86-64.tgz
"How would it be possible to use a lifecycle version which is not yet released but where image has been created from the github commit id ?
Example for the commit: 919b8ad
I think that we should investigate to propose a solution as by example this is is something that we can do using
pack build
using this parameterpack build ... --lifecycle-image buildpacksio/lifecycle:919b8ad-linux-arm64
but not if we execute the lifecycle creator part of kubernetes podThe text was updated successfully, but these errors were encountered: