Skip to content

feat: add confirmation label when volume spec changes#13808

Open
qianlongzt wants to merge 1 commit into
docker:mainfrom
qianlongzt:feat-volume-recreate-label
Open

feat: add confirmation label when volume spec changes#13808
qianlongzt wants to merge 1 commit into
docker:mainfrom
qianlongzt:feat-volume-recreate-label

Conversation

@qianlongzt
Copy link
Copy Markdown

What I did

Add support for label: com.docker.compose.volume.recreate-when-spec-updated

This allows automatic handling of volume recreation when specs change, improving compatibility with CD workflows by avoiding interactive prompts.

Related issue

closes: #13807

(not mandatory) A picture of a cute animal, if possible in relation to what you did

@qianlongzt qianlongzt requested a review from a team as a code owner May 22, 2026 15:35
@qianlongzt qianlongzt requested review from glours and ndeloof May 22, 2026 15:35
@qianlongzt qianlongzt marked this pull request as draft May 22, 2026 15:36
@qianlongzt qianlongzt force-pushed the feat-volume-recreate-label branch from 7eb9d7d to 76c9cda Compare May 22, 2026 15:37
close: docker#13807
Signed-off-by: qianlongzt <18493471+qianlongzt@users.noreply.github.com>
@Quantum0uasar
Copy link
Copy Markdown

This is a useful feature for CD pipeline automation — the interactive volume recreation prompt is a common friction point in CI/CD environments. A few thoughts on the implementation:

Label naming convention

com.docker.compose.volume.recreate-when-spec-updated follows the existing Docker label namespace convention well. However, consider whether a shorter, more ergonomic alias like com.docker.compose.recreate=on-spec-change would be easier to remember. Looking at the existing Compose label space, verbose names are the norm, so the proposed name is consistent.

Scope: volumes only, or also other resources?

The same "recreate on spec change" problem applies to networks (e.g., network subnet changes) and potentially configs/secrets. While it's fine to scope this PR to volumes only, it would be worth noting in the PR description whether this label pattern is intended to be extensible to other resource types in the future, or if it's intentionally volume-specific.

Safety consideration: data loss risk

Reproducing a named volume destroys existing data. The label effectively silences a prompt that exists specifically to prevent accidental data loss. The implementation should clearly document this in:

  1. The label's inline comment in the code
  2. The Compose spec documentation (reference docs for labels)
  3. Potentially a warning logged to stderr even when the label is set (e.g., WARN: Volume 'mydata' is being recreated due to spec change (label: com.docker.compose.volume.recreate-when-spec-updated)) so operators have an audit trail

CI workflow example

A concrete usage example in the PR description would help reviewers understand the target use case:

volumes:
  my_data:
    labels:
      com.docker.compose.volume.recreate-when-spec-updated: "true"

This makes it immediately clear whether the label value matters (boolean string) or just the presence of the label key is sufficient.

Good feature for automation-first workflows. The main thing I'd want to see before merge is explicit data-loss documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support optional auto-confirm for volume recreation in CD workflows

2 participants