ansible-lint runnimg modes

Current

• online
• offline

Future - running modes

• realtime # vs extension mode, really fast

• quick # from the CLI

• full # for CI

• galaxy? # is this seperate?

• vscode extension can set certain flags to achive realtime mode

• the CLI would default to quick mode

• and the GHA can set flag for full

Features affected

current

• running ansible-galaxy install commands … – controled by offline mode
• refresh schemas, controlled by offline mode
• mocking dependencies based on config - always happening - hardcoded to on
• running in isolation (collection/roles) - currently hardcoded to "on"
• version check - controled by offline mode, also disabled if installed from rpm
• installing current collection using galaxy editable
• strict mode: treat warnings as errors (off default)

future

• future telemetry reporting feature
• future saas features

We might want to avoid adding one option for each of these, as it would explode the testing complexity.

# config
# 
flags:
  isolated: true
  # should be false for CI mode
  #
  editable: true # unless CI is detected / limited to a recognized role/collection
  install-requirements: true
      # by default, look in a ./collections directory
      # if a rqwuirements file is found in ./collections
      # install the collections in ./collections
      # this feature will install collecitons and roles
      # but not their python or system package dependancies
      # this should be documented, and suggest an EE for a full dep build
  update-schemas: true
  version-check: true  # not for rpms
  # reserved for future
  telemetry: false # true for github-action
  saas: false # or wisdom?
  
  e/E
  --feature=!telemetry,-editable
  

./collection

Question: If running ansible-lint in a directory that appears to be a collection, how do we ensure that collection can be used by ansible-core? Do we symlink the current working directory directories into a collections/ansible-collections/directory/name/namespace and inject the current working directory into the ansible-core collection path for the user?

• Should we install the collections deps into the same collection tree is asked?

Developer machine

• Out of the box without any additional configuration, I want

  • ansible-lint to use my current development environment
  • respect my currently installed collections based on what ansible-core reports
  • use the version of ansible-core available along side ansible-lint
  • automatically refresh/update schemas
  • ansible-lint to report newer versions available

• I want to be able to opt into telemetry

• I want the option for ansible-lint to install collections in the current environment based on the presense of a project directory requirements.yml file within a playbook adjacent collection directory

• I want the option to disable automatic schema updates

• I want the option to disable newer version checking

• I want the ability to disable errors thrown by "plugin not found"

  • this may be done by mocking, monkeypatching/ignoring ansible-core

• I want ansible-lint to recognise I am developing a collection and symlink my workspace contents into a {workspace}/collections/ansible-collections/directory/name/namespace so ansible-lint paths are "clickable" <= this is probably the default behaviour of the extension using the "editable" mode

• I do not want ansible-lint to try and build a collection if project folder is determined to be a collection

GHA action (CI/CD)

• Telemetry enabled by default, but option to disabled it (otherwise they will fork it to disable it)
• Schema update enabled by default
• We do not want to install current collection as editable!
• If ansible-lint detects that the CWD is a collection, then it should by default try to build the collection, this should include linting of all test and playbook directories (and eventually the examples contained within the plugin's plython files)

AAS

• Provide deprecation warnings
• Don't build a collection
• Don't fail on missing plugins or attempt to install anything

Wisdom

• Don't fail on missing plugins or attempt to install anything
• Provide quality measure as an integer
• Don't build a collection
• Clean/reformat the code