Expose declared VOLUME / default container data path in CLI
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 52/100
Direzione di ricerca
Inizia individuando il percorso di output o ispezione della Docker CLI che riporta i metadati dell’immagine, quindi confrontalo con la dichiarazione Dockerfile VOLUME e l’output JSON di docker inspect menzionati qui. Il lavoro è completato quando le immagini che dichiarano VOLUME espongono chiaramente il percorso dati predefinito del container nella CLI, mentre le immagini senza VOLUME non producono alcun output aggiuntivo.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
Overall, my recent experience with Docker has been really positive.
Compared to manually copying projects, managing plugins, and configuring environments, Docker feels refreshingly simple—spin up with one command, clean up with another.
It’s certainly much more comfortable than traditional deployment, though there are still a few rough edges that feel unnecessarily awkward.
The Dockerfile already declares VOLUME, and the official docs mention the default data directory.
Yet, figuring out which directory the container actually expectsstill requires parsing docker inspectJSON output or digging through documentation—this isn’t very elegant.
Most mature software (nginx, mysql, redis, even systemd) follows a simple rule:
‘Here’s the default. Use it, or override it if you want.’
Docker does the opposite: it hints that a default exists, but refuses to show it clearly.
What I’m asking for is very simple:
Image has a VOLUME→ tell me
No VOLUME→ quietly skip
This is probably about three lines of Go code in the CLI. 😏
If a default exists, the CLI should expose it as a first‑class citizen—not force users to play detective.”
- Lingua principale
- Go
- Stelle
- 6.1k
- Fork
- 2.2k
- Merge medio
- 1g 10h
- PR unite (30g)
- 47
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di docker/cli
-
kind/bug status/0-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
kind/bug status/0-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
-
kind/feature status/0-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
kind/bug status/0-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
Issue simili
-
textual definition
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
geneontology/go-ontology#32653 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
-
needs design
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100