Skip and Enforce Checks

To help you achieve compliance and quality across your organization, Spotter allows you to centrally control which Ansible checks to skip and which to always enforce across all your automation workflows.

That means you can apply rules for all users from a single point of configuration or decide to skip some rules you find redundant. For example, if Spotter finds a potential risk, which you assess and accept, you can decide to skip it from now on, and it won’t keep ‘bothering’ you about it. With Spotter, you’re always in control. See DEMO or read blog .

When skipping or enforcing checks, you can supply the below three parameters to effortlessly tailor your desired level of check control to bypass or reinforce specific checks or sub-checks for a targeted Fully Qualified Collection Name (FQCN):

event: the event code of the check result (e.g., W2600);

subevent_code: check subcode (e.g., B324);

FQCN: fully qualified collection name (e.g.,

Check refinements are possible on three levels:

Organization Level

Establish the basic rules and apply checks across the whole organization. Any checks enforced at this level can’t be ignored when scanning, and any checks that are skipped at the organization level will take precedence over the enforced ones.

Sample of an org-config.json file:

 "skip_checks": [
     "event": "W003",
     "fqcn": "ansible.builtin.uri"
    "enforce_checks": [
      "event": "E005",
      "fqcn": "community.crypto.x509_certificate"

You use the config set command to upload it and config clear to clear it.

$ spotter config set org-config.json Copied!

$ spotter config clear Copied!

Interested in the current settings for a specific organization? Simply use the config get command to see the current setup:

$ spotter config get Copied!

Alternatively, you can manage skipping and enforcing checks within the Spotter app.

Scan Level

Fine-tune your scans to meet specific requirements. Checks enforced on scan level cannot be skipped on task level and checks skipped on scan level will override enforced checks on scan level.

On this level, you can skip checks primarily through a configuration file. Whether it’s your project’s personalized .spotter.json, .spotter.yml, or .spotter.yaml file, or a configuration file conveniently provided via the optional --config CLI argument, you’re in control.

Example of spotter.yml config file:

    - event: W003
      fqcn: ansible.builtin.uri
    - event: E601
      fqcn: community.crypto.x509_certificate
    - event: E005
    - event: E903

It is also possible to effortlessly skip or enforce checks using optional arguments tailored to your needs. Envision seamlessly excluding any checks tied to Ansible module deprecations and redirections or enforce all checks that are related to the use of with_items. This becomes reality through our --skip-checks and --enforce-checks optional arguments, allowing you to specify the exact checks to skip or enforce by their designated IDs (e.g., E1300).

$ spotter scan --skip-checks E1300,E1301,H1302 playbook.yml Copied!

$ spotter scan --enforce-checks W1100,E1101 playbook.yml Copied!

You can also skip or enforce checks for specific Fully Qualified Class Names (FQCNs) or even individual check subcodes by using the pattern: event[fqcn=<fqcn>, subevent_code=<subevent_code>] .

$ spotter scan --skip-checks H1900[fqcn=sensu.sensu_go.user],W003 playbook.yml Copied!

Task Level

Refine checks at the task level to suit individual tasks and scenarios. While you can’t enforce checks on this level, you have the freedom to skip them as needed. You can exercise control within the Ansible content itself. You can use the “noqa” (NO Quality Assurance) YAML comments at the end of any line within your Ansible task using the pattern: # noqa: event[fqcn=<fqcn>, subevent_code=<subevent_code>] , offering unrivaled precision and flexibility.

Example of skipping checks on task level:

- name: Sample playbook with comments
   hosts: localhost
     - name: Get tpayload from the API # noqa: W003, E903
         method: GET
         user: "username1"       &nbcommunity.crypto.x509_certificate: # noqa: E601[fqcn=community.crypto.x509_certificate]
       path: "{{ config_path certificates/server.crt"
       privatekey_path: "{{ config_path }}/certificates/server.key"
   &nbsnbsp;  provider: assertonly