All Projects → replicatedhq → Dockerfilelint

replicatedhq / Dockerfilelint

Licence: mit
An opinionated Dockerfile linter.

Programming Languages

javascript
184084 projects - #8 most used programming language

Projects that are alternatives of or similar to Dockerfilelint

Textidote
Spelling, grammar and style checking on LaTeX documents
Stars: ✭ 483 (-34.37%)
Mutual labels:  linter
Hadolint
Dockerfile linter, validate inline bash, written in Haskell
Stars: ✭ 6,284 (+753.8%)
Mutual labels:  linter
Xo
❤️ JavaScript/TypeScript linter (ESLint wrapper) with great defaults
Stars: ✭ 6,277 (+752.85%)
Mutual labels:  linter
Postcss Bem Linter
A BEM linter for postcss
Stars: ✭ 505 (-31.39%)
Mutual labels:  linter
Shellcheck
ShellCheck, a static analysis tool for shell scripts
Stars: ✭ 27,211 (+3597.15%)
Mutual labels:  linter
Devskim
DevSkim is a set of IDE plugins and rules that provide security "linting" capabilities.
Stars: ✭ 576 (-21.74%)
Mutual labels:  linter
Redbot
REDbot is lint for HTTP.
Stars: ✭ 475 (-35.46%)
Mutual labels:  linter
Interfacer
A linter that suggests interface types
Stars: ✭ 706 (-4.08%)
Mutual labels:  linter
Esprint
Fast eslint runner
Stars: ✭ 556 (-24.46%)
Mutual labels:  linter
Phplint
🐛 A tool that can speed up linting of php files by running several lint processes at once.
Stars: ✭ 646 (-12.23%)
Mutual labels:  linter
Oas Kit
Convert Swagger 2.0 definitions to OpenAPI 3.0 and resolve/validate/lint
Stars: ✭ 516 (-29.89%)
Mutual labels:  linter
Pep8speaks
A GitHub app to automatically review Python code style over Pull Requests
Stars: ✭ 546 (-25.82%)
Mutual labels:  linter
Scalafix
Refactoring and linting tool for Scala
Stars: ✭ 597 (-18.89%)
Mutual labels:  linter
Zally
A minimalistic, simple-to-use API linter
Stars: ✭ 499 (-32.2%)
Mutual labels:  linter
Pre Commit
A framework for managing and maintaining multi-language pre-commit hooks.
Stars: ✭ 7,024 (+854.35%)
Mutual labels:  linter
Graphql Schema Linter
Validate GraphQL schema definitions against a set of rules
Stars: ✭ 476 (-35.33%)
Mutual labels:  linter
Undercover
Actionable code coverage - detects untested code blocks in recent changes
Stars: ✭ 574 (-22.01%)
Mutual labels:  linter
Tslint
🚦 An extensible linter for the TypeScript language
Stars: ✭ 5,922 (+704.62%)
Mutual labels:  linter
Standard
🌟 JavaScript Style Guide, with linter & automatic code fixer
Stars: ✭ 26,433 (+3491.44%)
Mutual labels:  linter
Stylelint Processor Styled Components
Lint your styled components with stylelint!
Stars: ✭ 639 (-13.18%)
Mutual labels:  linter

Linter and validator for Dockerfile

Coverage Status Build Status

dockerfilelint is an node module that analyzes a Dockerfile and looks for common traps, mistakes and helps enforce best practices.

Installation

Global installation with npm package manager.

npm install -g dockerfilelint

Testing

Start unit tests with npm test, yarn run test, or docker-compose -f docker-compose.test.yml up

Running

From the command line:

./bin/dockerfilelint <path/to/Dockerfile>

Command Line options

Usage: dockerfilelint [files | content..] [options]

Options:
  -o, --output   Specify the format to use for output of linting results. Valid values
                 are `json` or `cli` (default).                               [string]
  -j, --json     Output linting results as JSON, equivalent to `-o json`.    [boolean]
  -v, --version  Show version number                                         [boolean]
  -h, --help     Show help                                                   [boolean]

Examples:
  dockerfilelint Dockerfile         Lint a Dockerfile in the current working
                                    directory

  dockerfilelint test/example/* -j  Lint all files in the test/example directory and
                                    output results in JSON

  dockerfilelint 'FROM latest'      Lint the contents given as a string on the
                                    command line

  dockerfilelint < Dockerfile       Lint the contents of Dockerfile via stdin

Configuring

You can configure the linter by creating a .dockerfilelintrc with the following syntax:

rules:
  uppercase_commands: off

The keys for the rules can be any file in the /lib/reference.js file. At this time, it's only possible to disable rules. They are all enabled by default.

The following rules are supported:

required_params
uppercase_commands
from_first
invalid_line
sudo_usage
apt-get_missing_param
apt-get_recommends
apt-get-upgrade
apt-get-dist-upgrade
apt-get-update_require_install
apkadd-missing_nocache_or_updaterm
apkadd-missing-virtual
invalid_port
invalid_command
expose_host_port
label_invalid
missing_tag
latest_tag
extra_args
missing_args
add_src_invalid
add_dest_invalid
invalid_workdir
invalid_format
apt-get_missing_rm
deprecated_in_1.13

From a Docker container

(Replace the pwd/Dockerfile with the path to your local Dockerfile)

docker run -v `pwd`/Dockerfile:/Dockerfile replicated/dockerfilelint /Dockerfile

Online

If you don't want to install this locally you can try it out on https://fromlatest.io.

Checks performed

FROM

  • [x] This should be the first command in the Dockerfile
  • [x] Base image should specify a tag
  • [x] Base image should not use latest tag
  • [x] Support FROM scratch without a tag
  • [x] Support the FROM <image>@<digest> syntax
  • [ ] Allow config to specify "allowed" base layers

MAINTAINER

  • [x] Should be followed by exactly 1 parameter (@ sign)

RUN

  • [x] sudo is not included in the command
  • [x] apt-get [install | upgrade | remove] should include a -y flag
  • [x] apt-get install commands should include a --no-install-recommends flag
  • [x] apt-get install commands should be paired with a rm -rf /var/lib/apt/lists/* in the same layer
  • [x] Avoid running apt-get upgrade or apt-get dist-upgrade
  • [x] Never run apt-get update without apt-get install on the same line
  • [x] apk add commands should include a --no-cache flag or be paired with an --update flag with rm -rf /var/cache/apk/* in the same layer
  • [x] apk add support for --virtual flag
  • [ ] handle best practices for yum operations and cleanup

CMD

  • [x] Only a single CMD layer is allowed
  • [ ] Better handling of escaped quotes
  • [ ] Detect exec format with expected variable substitution

LABEL

  • [x] Format should be key=value

EXPOSE

  • [x] Only the container port should be listed
  • [ ] All ports should be exposed in a single cache layer (line)
  • [ ] The same port number should not be exposed multiple times
  • [x] Exposed ports should be numeric and in the accepted range

ENV

  • [x] Format of ENV
  • [ ] Best practice of only using a single ENV line to reduce cache layer count

ADD

  • [x] Command should have at least 2 parameters
  • [x] Source command(s) cannot be absolute or relative paths that exist outside of the current build context
  • [x] Commands with wildcards or multiple sources require that destination is a directory, not a file
  • [ ] If an ADD command could be a COPY, then COPY is preferred
  • [ ] Using ADD to fetch remote files is discouraged because they cannot be removed from the layer

COPY

  • [ ] Implement checking (similar to ADD)
  • [ ] Do not COPY multiple files on a single command to best use cache

ENTRYPOINT

  • [ ] Support

VOLUME

  • [ ] Format
  • [ ] Any build steps after VOLUME is declare should not change VOLUME contents
  • [ ] If JSON format, double quotes are required

USER

  • [x] Should be followed by exactly 1 parameter

WORKDIR

  • [x] Validate that it has exactly 1 parameter
  • [x] WORKDIR can only expand variables previously set in ENV commands

ARG

  • [ ] Support
  • [ ] Prevent redefining the built in ARGs (proxy)

ONBUILD

  • [ ] Support

STOPSIGNAL

  • [ ] Validate input
  • [ ] Only present one time

HEALTHCHECK

  • [x] No additional parameters when only parameter is NONE
  • [x] Options before CMD are valid
  • [x] Options before CMD have additional arguments

Misc

  • [x] Only valid Dockerfile commands are present
  • [x] All commands should have at least 1 parameter
  • [x] Check that commands are written as upper case commands
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].