-
Notifications
You must be signed in to change notification settings - Fork 471
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
Keep BuildKit state in a volume #672
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But where is the volume created on create
?
I wonder if for backward compatibility we should remove volume by default. Or print a warning that volume is still there and data was not released. Maybe there is a good opt-in flag that is opposite of --rm
. Most of the time I think users want to remove volume. @thaJeztah
I guess we could revisit the deletion path once upgrade
command is added in the future. I guess then rm
always deletes volume(or at least by default). And upgrade
performs rm+create
without touching the volume.
Agree, just wanted to keep the same UX as other commands of the Docker CLI but maybe it's not legitimate in this case. |
da26577
to
c847455
Compare
Haven't looked closely at the changes, but be aware that
|
In our case it's not so yes that's confusing. I have changed the behavior to be backward compatible with an opt-in flag called |
Reason for that is that anonymous volumes are commonly used as temporary / ephemeral storage. |
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
c847455
to
258d12b
Compare
Retain BuildKit state inside a named volume if the container is removed for the
docker-container
driver.--volume
flag has also been added to therm
command to be able to force volume removal.Signed-off-by: CrazyMax crazy-max@users.noreply.github.com