This extension has been deprecated in favor of Ansible extension published by Red Hat.
For more details please see this discussion.
Let me know in the comments if this extension has helped you ;)
- Uninstall this extension
- Reload VS Code (from Command Palette or using button visible in the Extensions pane next to this extension)
- Install the extension published by Red Hat
- Adjust extension configuration:
- The default setting for Ansible: Use Fully Qualified Collection Names
changed to
true
. If you haven't set it explicitly tofalse
and you'd like to retain the old behavior, you'll need to set it tofalse
.NOTE: Official recommendation (in Ansible documentation) is to use FQCNs.
- The following settings are no longer available in the User scope, you
will need to move them to one of the other scopes:
- Ansible: Path
- Ansible Lint: Path
- Python: Activation Script
- Python: Interpreter Path
- The default setting for Ansible: Use Fully Qualified Collection Names
changed to
- Adjust
files.associations
if some of your YAML files get incorrectly associated with Ansible. And vice versa — some of the Ansible content may end up being automatically picked up by another YAML extension, in which case you will be surprised by seeing unexpected highlighting in those documents.
This extension adds language support for Ansible to VS Code.
Ansible keywords, module names and module options, as well as
standard YAML elements are recognized and highlighted distinctly. Jinja
expressions are supported too, also those in Ansible conditionals (when
,
failed_when
, changed_when
, check_mode
), which are not placed in double
curly braces.
The screenshots and animations presented in this README have been taken using the One Dark Pro theme. The default VS Code theme will not show the syntax elements as distinctly, unless customized. Virtually any theme other than default will do better.
While you type, the syntax of your Ansible scripts is verified and any feedback is provided instantaneously.
On opening and saving a document, ansible-lint
is executed in the background
and any findings are presented as errors. You might find it useful that
rules/tags added to warn_list
(see Ansible Lint Documentation)
are shown as warnings instead.
If you also install
yamllint
,ansible-lint
will detect it and incorporate into the linting process. Any findings reported byyamllint
will be exposed in VSCode as errors/warnings.
The extension tries to detect whether the cursor is on a play, block or task etc. and provides suggestions accordingly. There are also a few other rules that improve user experience:
- the
name
property is always suggested first - on module options, the required properties are shown first, and aliases are shown last, otherwise ordering from the documentation is preserved
- FQCNs (fully qualified collection names) are inserted only when necessary;
collections configured with the
collections
keyword are honored. This behavior can be disabled in extension settings.
When writing a Jinja expression, you only need to type "{{
, and it will be
mirrored behind the cursor (including the space). You can also select the whole
expression and press space
to put spaces on both sides of the expression.
Documentation is available on hover for Ansible keywords, modules and module
options. The extension works on the same principle as ansible-doc
, providing
the documentation straight from the Python implementation of the modules.
You may also open the implementation of any module using the standard Go to
Definition operation, for instance, by clicking on the module name while
holding ctrl
/cmd
.
- Ansible 2.9+
- Ansible Lint (required, unless you disable linter support)
- yamllint (optional)
For Windows users, this extension works perfectly well with extensions such as
Remote - WSL
and Remote - Containers
.
If you have any other extension providing language support for Ansible, you might need to uninstall it first.
This extension supports multi-root workspaces, and as such, can be configured on any level (User, Remote, Workspace and/or Folder).
ansible.ansible.path
: Path to theansible
executable.ansible.ansible.useFullyQualifiedCollectionNames
: Toggles use of fully qualified collection names (FQCN) when inserting a module name. Disabling it will only use FQCNs when necessary, that is when the collection isn't configured for the task.ansible.ansibleLint.enabled
: Enables/disables use ofansible-lint
.ansible.ansibleLint.path
: Path to theansible-lint
executable.ansible.ansibleLint.arguments
: Optional command line arguments to be appended toansible-lint
invocation. Seeansible-lint
documentation.ansible.python.interpreterPath
: Path to thepython
/python3
executable. This setting may be used to make the extension work withansible
andansible-lint
installations in a Python virtual environment.ansible.python.activationScript
: Path to a customactivate
script, which will be used instead of the setting above to run in a Python virtual environment.
- The shorthand syntax for module options (key=value pairs) is not supported.
- Only Jinja expressions inside Ansible YAML files are supported. In order to have syntax highlighting of Jinja template files, you'll need to install other extension.
- Jinja blocks (inside Ansible YAML files) are not supported yet.