Expose declared VOLUME / default container data path in CLI
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 52/100
Línea de trabajo
Comienza localizando la ruta de salida o inspección de Docker CLI que informa de los metadatos de la imagen y compárala después con la declaración Dockerfile VOLUME y la salida JSON de docker inspect mencionadas aquí. Se considera terminado cuando las imágenes que declaran VOLUME muestran claramente la ruta de datos predeterminada del contenedor en la CLI, mientras que las imágenes sin VOLUME no producen ninguna salida adicional.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.”
- Lenguaje dominante
- Go
- Estrellas
- 6.1k
- Forks
- 2.2k
- Merge medio
- 1 d 17 h
- PR fusionados (30 d)
- 28
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de docker/cli
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 92/100
Los mantenedores suelen responder en 1 día
-
kind/bug status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
kind/bug status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
docker/cli#7176 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
docker/cli#7005 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
kind/feature status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
docker/cli#6919 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de docker/cli
Issues similares
-
type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
bug good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
repowise-dev/repowise#2966 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
blinklabs-io/dingo#4937 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
getkin/kin-openapi#1284 ·
Los mantenedores suelen responder en 1 día
-
[software-development-practices:nist-ssdf] github/gh-aw-threat-detection repository guidanceAbiertosoftware-development-practices software-development-practices:nist-ssdf
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
githubnext/gh-aw-cao#15860 ·
Los mantenedores suelen responder en 1 día