Formatting

Disable formatting checks using -x formatting.

201

Trailing whitespace

Problematic code

Please mind the trailing whitespaces on every line in the code snippet

/tmp/testfile:
  file.managed:
    - source:/salt://lorem/ipsum/dolor

Correct code

/tmp/testfile:
  file.managed:
    - source:/salt://lorem/ipsum/dolor

Rationale

There should not be any trailing whitespace


202

Jinja statement should have spaces before and after: {% statement %}

Problematic code

{%-set example='bad'+%}

Correct code

{%- set example='good' +%}

Rationale

Jinja dictates that statements should always have spaces before and after {% statement %}

A control structure refers to all those things that control the flow of a program - conditionals (i.e. if/elif/else), for-loops, as well as things like macros and blocks. With the default syntax, control structures appear inside {% ... %} blocks.


203

Most files should not contain tabs

Problematic code

/tmp/testfile:
    file.managed:
    - source:/salt://lorem/ipsum/dolor

Correct code

/tmp/testfile:
  file.managed:
    - source:/salt://lorem/ipsum/dolor

Rationale

Tabs can cause unexpected display issues, use spaces


204

Lines should be no longer that 160 chars

Problematic code

/tmp/testfile:
  file.managed:
    - source: salt://lorem/ipsum/dolor/sit/amet/consectetur/adipiscing/elit/sed/do/eiusmod/tempor/incididunt/ut/labore/et/dolore/magna/aliqua/ut/enim/ad/minim/veniam

Correct code

/tmp/testfile:
  file.managed:
    - source: salt://state/file

Rationale

Long lines make code harder to read and code review more difficult


205

Use ".sls" as a Salt State file extension

Rationale

All files used by saltstack should have the .sls extension


206

Jinja variables should have spaces before and after {{ var_name }}

Problematic code

{{-variable+}}

Correct code

{{- variable +}}

Rationale

Jinja dictates that variables should always have spaces before and after {{ variable }}


207

File modes should always be encapsulated in quotation marks

Problematic code

testfile:
  file.managed:
    - name: /tmp/badfile
    - user: root
    - group: root
    - mode: 0700
    - file_mode: 0660
    - dir_mode: 0775

Correct code

testfile:
  file.managed:
    - name: /tmp/testfile
    - user: root
    - group: root
    - mode: '0700'

Rationale

As described in the saltstack documentation:

When using a mode that includes a leading zero you must wrap the value in single quotes. If the value is not wrapped in quotes it will be read by YAML as an integer and evaluated as an octal.

There's also an open issue for this


208

File modes should always contain a leading zero

Problematic code

testfile:
  file.managed:
    - name: /tmp/badfile
    - user: root
    - group: root
    - mode: 700
    - file_mode: '660'
    - dir_mode: '775'

Correct code

testfile:
  file.managed:
    - name: /tmp/testfile
    - user: root
    - group: root
    - mode: '0700'

Rationale

As described in the saltstack documentation:

When using a mode that includes a leading zero you must wrap the value in single quotes. If the value is not wrapped in quotes it will be read by YAML as an integer and evaluated as an octal.

There's also an open issue for this


209

Jinja comment should have spaces before and after: {# comment #}

Problematic code

{#-set example='bad'+#}

Correct code

{#- set example='good' +#}

Rationale

Jinja dictates comments always have spaces before and after {# comment #}.

To comment-out part of a line in a template, use the comment syntax which is by default set to {# ... #}. This is useful to comment out parts of the template for debugging or to add information for other template designers or yourself


210

Numbers that start with 0 should always be encapsulated in quotation marks

Problematic code

# Unquoted octal values with leading zero's.
testdirectory:
  file.recurse:
    - name: /tmp/directory
    - file_mode: 00
    - dir_mode: 0700

Correct code

testdirectory:
  file.recurse:
    - name: /tmp/directory
    - file_mode: 700
    - dir_mode: '0775'

Rationale

As described in the saltstack documentation:

When using a mode that includes a leading zero you must wrap the value in single quotes. If the value is not wrapped in quotes it will be read by YAML as an integer and evaluated as an octal.

There's also an open issue for this


211

pillar.get or grains.get should be formatted differently

Correct ways: * salt['pillar.get']('item') * pillar['item'] * pillar.get('item')

Incorrect ways:

  • pillar.get['item']

Problematic code

example_file:
  file.managed:
    - name: /tmp/bad.txt
    - contents: |
        {{ pillar.get['item'] }} # this line is broken
        {{ grains.get['saltversion'] }} # this line is broken

Correct code

example_file:
  file.managed:
    - name: /tmp/good.txt
    - contents: |
        {{ salt['pillar.get']('item') }}
        {{ pillar.get('item') }}
        {{ pillar['item'] }}
        {{ salt['grains.get']('saltversion') }}
        {{ grains.get('saltversion') }}
        {{ grains['saltversion'] }}

Rationale

211 catches a common mistake of wrongly calling grains and pillar data.


212

Most files should not contain irregular spaces

Problematic code

/tmp/testfile:
    file.managed:
      - content:u"\u000B""foobar"

Please excuse above example, it's tough to write a proper example of this. Take this error seriously though ;-)

Correct code

/tmp/testfile:
    file.managed:
      - content: "foobar"

Rationale

Irregular spaces can cause unexpected display issues, use spaces


213

SaltStack recommends using cmd.run together with onchanges, rather than cmd.wait

Problematic code

run_postinstall:
  cmd.wait:
    - name: /usr/local/bin/postinstall.sh
    - watch:
      - pkg: mycustompkg

Correct code

run_postinstall:
  cmd.run:
    - name: /usr/local/bin/postinstall.sh
    - onchanges:
      - pkg: mycustompkg

Rationale

SaltStack recommends using cmd.run together with onchanges in their documentation.


214

SLS file with a period in the name (besides the suffix period) can not be referenced

As described by the official SaltStack documentation:

The initial implementation of top.sls and Include declaration followed the python import model where a slash is represented as a period. This means that a SLS file with a period in the name ( besides the suffix period) can not be referenced. For example, webserver_1.0.sls is not referenceable because webserver_1.0 would refer to the directory/file webserver_1/0.sls

The same applies for any subdirectories, this is especially 'tricky' when git repos are created. Another command that typically can't render it's output is state.show_sls of a file in a path that contains a dot.