2.0 KiB
| title |
|---|
| The standards file |
A standards file comprises a list of standards, and optionally some methods to check those standards.
Create a file called standards.py (this can import other modules)
{{< highlight Python "linenos=table" >}} from ansiblelater include Standard, Result
tasks_are_uniquely_named = Standard(dict( # ID's are optional but if you use ID's they have to be unique id="ANSIBLE0003", # Short description of the standard goal name="Tasks and handlers must be uniquely named within a single file", check=check_unique_named_task, version="0.1", types=["playbook", "task", "handler"], ))
standards = [ tasks_are_uniquely_named, role_must_contain_meta_main, ] {{< /highlight >}}
When you add new standards, you should increment the version of your standards. Your playbooks and roles should declare what version of standards you are using, otherwise ansible-later assumes you're using the latest. The declaration is done by adding standards version as first line in the file. e.g.
{{< highlight INI "linenos=table" >}}
Standards: 1.2
{{< /highlight >}}
To add standards that are advisory, don't set the version. These will cause a message to be displayed but won't constitute a failure.
When a standard version is higher than declared version, a message will be displayed 'WARN: Future standard' and won't constitute a failure.
An example standards file is available at ansiblelater/examples/standards.py
If you only want to check one or two standards quickly (perhaps you want
to review your entire code base for deprecated bare words), you can use the
-s flag with the name of your standard. You can pass -s multiple times.
{{< highlight Shell "linenos=table" >}} git ls-files | xargs ansible-later -s "bare words are deprecated for with_items" {{< /highlight >}}
You can see the name of the standards being checked for each different file by running
ansible-later with the -v option.