-
Notifications
You must be signed in to change notification settings - Fork 0
pack rebase
- swaps out the base stack of a built image
#2
Comments
Option (2), and we shouldn't store the run image name/location in the image metadata (just the SHA). |
I'm good with option 2. Re: shouldn't store it there, we currently do, why shouldn't we? Example
|
The name encodes the location of the run image that was last used to rebase or rebuild the image. That info doesn't seem useful, and could be confusing (because rebase and rebuild both ignore it). I don't have a super strong opinion about it though. (Unrelated point: |
If you pull |
buildpacks/roadmap#2 Signed-off-by: Dave Goddard <[email protected]>
buildpacks/roadmap#2 Signed-off-by: Jacques Chester <[email protected]>
Nontice an issue in README Should be
|
Also running into issue when trying to rebase a remote image. Local flow works
|
@ssisil why
|
@ekcasey - |
To summarise the current bug @ekcasey . Scott says that local rebase works , but remote rebase had error |
* use mutate.Config() to properly update config for remote image [buildpacks/roadmap#2]
@ssisil Fixed. You can test it out with |
Scenario : rebase on local docker daemon
GIVEN I have an app image in my local docker daemon that has an outdated run image
WHEN I run
pack rebase <image-name:tag>
THEN an updated run image is pulled into the local docker daemon if it is not already available
AND the image-name:tag is rebased to point to the new run image
AND the following message will be displayed to the user
Scenario : rebase on remote registry
GIVEN I have an app image on a registry that has an outdated run image
WHEN I run
pack rebase <image-name:tag> --publish
THEN the image-name:tag is rebased to point to the new run image on the registry
AND the following message will be displayed to the user
The text was updated successfully, but these errors were encountered: