npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

dockerlinter

v1.2.2

Published

Dockerfile linter

Downloads

2,246

Readme

Docker Linter

Dockerfile Linter (written in Node.js) buddy pipeline

Description

A Dockerfile linter that you can use to quickly check if your Dockerfile follows the best practices for building efficient Docker images. The tool uses ShellCheck analysis tool to lint code in RUN instructions. Some of the rules were inspired by Hadolint and Dockerfile reference documentation.

Installation

The linter requires Node.js to run:

npm install --global dockerlinter

Application

CLI

The linter can be used directly from the CLI:

dockerfilelinter -f <path to Dockerfile>
dockerfilelinter -f <path to Dockerfile> -s bash #default sh
dockerfilelinter -f <path to Dockerfile> -s none #disable shellcheck
dockerfilelinter -f <path to Dockerfile> -i ER0012,ER0015 #coma separated list of ignored rules
dockerfilelinter -f <path to Dockerfile> -e #return error code 1 for any error
dockerfilelinter -f <path to Dockerfile> -e warning #return error code 1 for errors with level 'warning' or higher(available levels: info, warning, error)

Docker

Docker allows you to run the linter on any type of platform. To mount the file, use the -v parameter:

docker build . -t imagename
docker run -v /tmp/files/dockerfile:/dockerfilelinter/dockerfile imagename linter -f dockerfile

Inline ignores

You can ignore rules for a specific instruction block in the Dockerfile by commenting it. The ignore comment must be applied above the instruction as # linter ignore=EF0003. The exceptions are ED and EL rules. Example:

# linter ignore=EF0003,EF0004
FROM node

YAML file with ignores

You can create YAML file "your dockerfile name".linter.yaml with list of ignored rules for specific Dockerfile or for all in folder dockerfilelinter.yaml. If you put file in the same folder where linting dockerfile is it will be auto-detected, but you can also use flag -y/--yaml to specify a path. Example:

ignored:
 - ER0012
 - ER0015

Rules

The list of rules implemented.

  • Rules with the E prefix come from dockerfilelinter. Implementation can be found in lib/lints.js.
  • Rules with the SC prefix come from ShellCheck. You can find their description in the tool's Wiki. For a more detailed description, use the Pages search tool.

Legend

ED - Error Directives EI - Error Instructions ER - Error RUN EC - Error COPY EU - Error USER EF - Error FROM EW - Error WORKDIR EE - Error EXPORT EL - Error Lines EA - Error ADD EJ - Error JSON

| Rules | Description | |:--------------------------|:------------------------------------------------------------------------------------------------------------------| | EL0001 | Invalid line | | ED0001 | All parser directives must be at the very top of a Dockerfile. | | ED0002 | Directive appears more then once. | | ED0003 | Directives should be lowercase. | | ED0004 | Parser directive will be treated as a comment. | | ED0005 | Missing value for directive. | | ER0001 | Set the SHELL option -o (-eo for Alpine image) pipefail before RUN with a pipe in. | | EU0001 | Last user should not be root. | | EI0001 | There can only be one instruction like (CMD, HEALTHCHECK, ENTRYPOINT). | | EI0002 | FROM may only be preceded by one or more ARG. | | EF0001 | Missing FROM. | | EC0001 | COPY --from cannot reference its own FROM alias. | | EC0002 | COPY --from should reference a previously defined FROM alias. | | EI0003 | MAINTAINER is deprecated, instead use LABEL. | | EJ0001 | You must use double-quotes (") in JSON array. | | EJ0002 | CMD and ENTRYPOINT should be written in JSON form. | | EJ0003 | SHELL must be written in JSON form. | | EF0002 | FROM aliases must be unique. | | EF0003 | Using latest is prone to errors if the image will ever update. | | EF0004 | Always tag the version of an image explicitly. | | ER0002 | Delete the apt-get lists after installing something. | | ER0003 | Use WORKDIR to switch to a directory. | | ER0004 | Do not use sudo, consider using gosu. | | ER0005 | Command (ssh, vim, shutdown, service, ps, free, top, kill, mount, ifconfig) does not make sense in a container. | | ER0006 | Using (apt-get upgrade, dist-upgrade, apk upgrade, apt install) is not recommended. | | EA0001 | Use curl or wget instead, and delete files when no longer needed. | | EC0003 | Use ADD for extracting archives into a image. | | ER0007 | Either use wget or curl, but not both. | | ER0008 | Use SHELL to change the default shell. | | ER0009 | Use the -y switch. | | ER0010 | Avoid additional packages by specifying --no-install-recommends. | | EA0002 | Use COPY instead of ADD for files and folders. | | EC0004 | COPY with more then 2 arguments requires the last argument to end with /. | | ER0011 | Use the --no-cache switch. | | ER0012 | Pin versions in apt get install. | | ER0013 | Pin versions in pip install. | | ER0014 | Pin versions in npm install. | | ER0015 | Pin versions in apk add. | | ER0016 | Pin versions in gem install. | | EI0004 | Don't use (ONBUILD,FROM,MAINTAINTER) in ONBUILD. | | EW0001 | Use absolute WORKDIR. | | EE0001 | Valid UNIX ports range from 0 to 65535. | | EI0005 | Instructions should be uppercase. |

Development

You can help us develop linter by suggesting new rules and reporting bugs.

Tests

To run unit tests, use the command below:

npm run test

Maintainer

Docker Linter was created and developed by Buddy, creators of delivery automation tools for web and software developers.

CI/CD

The linter was created to validate the Dockerfile syntax in Continuous Integration and Delivery processes and can be used in any CI/CE tool. Buddy natively supports the linter, allowing you to create a pipeline that will check the syntax, build the Docker image and push it to the registry in a few simple steps:

  1. First, define when and for what refs (branchs / tags / pull requests) should the pipeline execute:

Docker Linter

  1. Next, add the Lint Dockerfile action and select the Dockerfile to validate:

Docker Linter

  1. Last, add the Docker build action that will build the image and push it to the registry.

Docker Linter

  1. You can extend the pipeline to automate other processes in your workflow. For example, automatically update the image on your K8s cluster and notify the QA team in case something goes wrong:

Docker Linter