# 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