Analiza un Dockerfile antes de que llegue a revisión.

Diecisiete reglas, de DF001 a DF017, y cada una es un error que aun así compila: una imagen base sin tag o con :latest, un COPY --from que nombra una etapa que todavía no existe, ADD donde corresponde COPY, una descarga remota sin verificar, un WORKDIR relativo, un apt-get update abandonado en su propia capa, una caché de paquetes que se queda dentro de la imagen, un secreto escrito en el historial de la imagen por ENV o ARG, una etapa final que corre como root, cd en lugar de WORKDIR, curl canalizado a una shell, un segundo CMD que gana en silencio, una forma exec JSON que no es JSON válido, sudo en un paso de build, MAINTAINER, y un COPY . que destruye la caché de la instalación de dependencias. Cada regla tiene su propia subsección en esta página con un fragmento de antes y después.

No, y no pretende serlo. hadolint es un binario que instalas, y combina sus propias reglas con todo lo que ShellCheck dice sobre la shell dentro de tus líneas RUN — excelente en CI y la respuesta correcta cuando puedes imponer un toolchain. Esto cubre el caso que hadolint no cubre: un Dockerfile que quieres revisar ahora mismo, desde el navegador, en una máquina donde no puedes instalar nada, sin enviar el archivo a un servidor. Diecisiete reglas en lugar de una cola larga, cada una con su corrección, y más abajo una lista explícita de lo que se niega a señalar.

No. El parser y las diecisiete reglas son JavaScript ejecutándose en tu pestaña — no hay servidor, ni llamada a una API, ni registro, así que se suben 0 bytes. Aquí importa más que en la mayoría de las herramientas: los Dockerfiles llevan nombres de host de registries internos, índices de paquetes privados, argumentos de build y, de vez en cuando, una credencial que alguien no debería haber commiteado.

Porque cada RUN es una capa aparte con su propia entrada de caché. Cuando después editas solo la línea de instalación, Docker reutiliza la capa de update ya cacheada — que puede tener semanas o meses — y ejecuta la instalación contra ese índice de paquetes obsoleto. El resultado es o una versión que no esperabas o un 404 de un paquete que ya fue reemplazado. Unirlos en un solo RUN hace que el índice y la instalación compartan entrada de caché, así que nunca pueden contradecirse.

Nada, hasta que el publicador hace push. :latest es un puntero móvil, y un FROM sin tag significa :latest, así que la imagen base que usó tu build el mes pasado y la que usa esta noche pueden ser versiones mayores distintas sin que tú hayas cambiado nada — y nada en el archivo registra cuál probaste de verdad. Fija un tag que hayas probado. Si necesitas rebuilds idénticos byte a byte, añade también el digest (@sha256:…). Este linter pide un tag y nunca exige un digest: esa decisión es tuya.

Porque Docker no lo rechaza: silenciosamente hace otra cosa. La forma exec solo se usa cuando el argumento parsea como JSON, y JSON exige comillas dobles. Con comillas simples todo cae de vuelta a la forma shell, así que Docker ejecuta /bin/sh -c "['nginx']" y los corchetes y las comillas pasan a formar parte del comando. Nada avisa en tiempo de build; el contenedor simplemente no arranca, o arranca una shell que no es el proceso que querías como PID 1.

No directamente, y lo dice en lugar de adivinar. Un .dockerignore es un archivo separado, así que un linter que solo lee el Dockerfile no puede saber si node_modules, .git y tus artefactos de build están entrando en el contexto de build. Lo que sí puede hacer es detectar el patrón que encarece la falta de un .dockerignore — un COPY . antes de la instalación de dependencias, que es DF017 — y poner el consejo del .dockerignore en el texto de corrección de esa regla.

Ambos se consideraron y se descartaron a propósito. EXPOSE es documentación: por sí solo no publica nada, así que su ausencia no rompe nada y uno de más no cuesta nada. HEALTHCHECK lo ignora por completo Kubernetes, que es donde estas imágenes acaban corriendo, así que señalarlo entrenaría a este público a ignorar el linter. La lista completa de lo que se queda en silencio, con el motivo de cada punto, está en el panel «Lo que deliberadamente no señala» sobre las FAQ.

Hasta 200.000 caracteres — unas cuatro mil líneas de texto denso, dos órdenes de magnitud por encima de cualquier Dockerfile real. Por encima de eso se niega con un mensaje en lugar de congelar tu pestaña, porque una entrada así es un log de build o un archivo empaquetado, no un Dockerfile. Los hallazgos también tienen tope, 20 por regla y 200 en total, y el panel indica el tope y la cifra real siempre que alguno se aplica.