Features

Code Assistant

  • Syntax and error highlighting with separate highlighting for Ansible modules, roles and blocks
  • Code Completion
    • of Ansible variables in Jinja templates
    • of Ansible modules and module arguments (from over 10000 Ansible Galaxy modules, configurable)
    • on Ansible Keywords (optionally with values)
    • of Ansible plugin filters
    • from a selection of the most common Ansible facts
    • of role names for role and roles keyword
    • of tags already used for the keyword tags
    • of delegate_to: localhost
    • of file names in import*/include_tasks Keywords
    • of host/group names for the keyword hosts
    • of file name for the src module argument of the template module
    • of variables in when/changed_when/failed_when keywords
    • of variables defined by the set_fact module
    • of variables (module results) defined by the keyword register
  • Different modes for code completion for Ansible modules
    • Completion of full qualified collection names
    • Complete only the module name
    • Show completion of FQCN and module name
    • Show only suggestions for collections listed in the collections keyword
  • Auto-closing of Jinja2 template brackets
  • Auto-quoting from Jinja2 templates to Key
  • Highlighting of deprecated modules
  • Configurable code folding with Ansible context-based summarization
  • Configurable Inlay Hints from Jinja2 variables
  • Moving complete Ansible tasks in your order
  • Copy & paste with automatic correction of indentation
  • Creation of Ansible roles, playbooks and groups/host variable folder file structures
  • Suggestions for missing folders when creating folders in roles
  • Context-based display of editor tab names instead of file names
  • Excluding/commenting lines with keyboard shortcuts

Syntax and error highlighting

Customized syntax and error highlighting for Ansible scripts makes capturing and reading Ansible code easier and more intuitive.

This is ensured by the extra highlighting for Ansible modules, blocks and rescue/always, and Jinja2 templates with separate highlighting settings.

Code completion

OrchidE’s code completion support for Ansible scripts covers everything from the standard Ansible element to individual attributes of a module. A broad spectrum for the efficient creation of Ansible code.

A selection of Ansible facts allows you to complete the most common facts.

When using register variables, completions based on the results can be used on the basis of the Ansible documentation.

Verschiedene Modi für Ansible Modul Completion

The suggestions for code completion made by OrchidE modules can be configured extensively. This concentrates the number of proposals on the essentials.

You can specify which Ansible collections should be taken into account.

Furthermore, the suggestions can contain the module name, or the full qualified collection name, or only the module name if the namespace is specified in the collections keyword of the role or playbook.

Together with the inspection “Recognition of non-unique module,” OrchidE can be used to dispense with the full qualified collection name of modules to generate Ansible scripts that are easier to read.

Auto-quoting/auto-closing of Jinja2 template curly braces

When entering curly brackets for Jinja2 templates, the closing bracket is automatically added after inserting the space character.

If the Jinja2 template must be in quotation marks, e.g. directly after a key, these are added automatically.

OrchidE prevents the automatic addition of the closing bracket after the first curly bracket.

Highlighting of deprecated modules

If Ansible modules are used that are deprecated, a warning is displayed in the editor.

If the module has been replaced by another one, this is indicated in the warning.

Ansible Code-Folding

When Ansible constructs are collapsed, OrchidE’s code folding shows a context-based summary so that you can roughly recognize the content.

What is used for code folding can be set as required. This means that deeply nested structures, e.g., tasks, can simply be folded in/out without having to fold in/out modules and arguments separately.

Inlay hints for Ansible variables

OrchidE displays Inlays for Jinja2 variables. This allows the values or the value list of the variable to be displayed directly in the Jinja2 template.

As a variant, the display can also be shown as a tooltip via a mouse over action.

Moving Ansible tasks

Ansible task blocks can be easily moved up/down with OrchidE.

Moving is done via the IntelliJ ActionMove Statement up/down”.

Copy & Paste with indentation

Within the IntelliJ project, OrchidE can paste copied Ansible code such as tasks, modules, module arguments, and variables to match the code location.

The code snippet is indented according to the current code position.

Navigation and search

  • Search and navigate to roles
  • Search and navigate to playbooks
  • Search and navigate to definitions of Ansible variables
  • Search and navigate to inventory groups
  • Navigation to associated Ansible playbooks/roles/variables in an Ansible file
  • Navigation / Go to definition of
    • Jinja2 variables (incl. variables defined by set_fact, register),
    • roles from playbooks,
    • imported / included files,
    • inventory entries from the Hosts keyword
    • referenced template files (template -> src argument)
    • referenced options in argument_spec files
    • referenced variables in when* keywords

Search and navigation to Ansible elements

IntelliJ’s SearchEverywhere dialog can be used to search for roles, playbooks, definition of variables and inventory, and the entries found can be opened directly in an editor.

The search is carried out:

  • for roles, playbooks in tab Class
  • for inventory entries in tab Inventory
  • for variable in tab Symbols

Search and navigation are carried out via the IntelliJ Action Search Anywhere.

In each Ansible file (playbook, tasks, variables and inventory files), you can navigate to the corresponding files.

OrchidE shows in the current context of the file which playbooks, roles, inventory groups and group/host variables are involved and offers the possibility to navigate directly to the files.

Navigation takes place via the IntelliJ ActionGo to Related Item”.

Go to the definition of Jinja2 variables

You can navigate directly to the definition of Jinja2 variables.

- name: Sample
  debug:
    msg: "{{ a_variable }}"

Navigation takes place via the IntelliJ ActionGo to Declaration or Usages”.

Go to the definition of roles

You can navigate directly to referenced roles in playbooks.

  roles:
    - a_role
    - role: a_role
  tasks:
    - include_role:
        name: a_role

Navigation takes place via the IntelliJ ActionGo to Declaration or Usages”.

Go to the definition of imported files

You can navigate directly to referenced playbook or task files of the modules import_playbook, import_tasks, include_tasks.

The navigation supports the Ansible search paths: current folder, relative paths, tasks folder.

Navigation takes place via the IntelliJ ActionGo to Declaration or Usages”.

Go to the definition of hosts entries

In playbooks, you can navigate directly from the host and group details in the hosts keyword to the inventory.

- hosts: servers, intern.example.com

Navigation takes place via the IntelliJ ActionGo to Declaration or Usages”.

Go to the definition of template files

You can navigate directly to referenced source template files of the template module.

The navigation supports the Ansible search paths: current folder, templates folder, relative paths, roles folder, playbook folder.

Navigation takes place via the IntelliJ ActionGo to Declaration or Usages”.

Go to the definition of variables (Argument_Spec)

In inventory variable files, you can navigate to the definition (Argument_Spec description) in the role.

To use the navigation, the variable must be provided with an OrchidE Role Annotation.

#@role::config-role
#Variable with argument_spec definition in role
os_user:
  name: "ansible"
  group: "users"

Navigation takes place via the IntelliJ ActionGo to Declaration or Usages”.

Go to the definition of variables (when* keywords)

In expressions of the keywords when, changed_when and failed_when you can navigate to the variables used.

Navigation takes place via the IntelliJ ActionGo to Declaration or Usages”.

Ansible Vault

  • Encrypt/decrypt Ansible Vaults on-the-fly when opening in the editor
  • Encrypts changed Ansible Vault files on-the-fly when saving (incl. support for IntelliJ’s auto-save)
  • Creation of Ansible Vaults from variable files
  • Decryption of Ansible Vaults
  • Changing passwords of Ansible Vaults
  • Changing Vault IDs of Ansible Vaults
  • Encryption of individual variables with Ansible Vault
  • Decryption of individual variables with Ansible Vault

Support for Ansible Vaults

An Ansible Vault can be created directly in the editor from an Ansible variable file.

The Vault ID can be set freely.

For existing Ansible Vault files, the Vault ID and password can be changed as required.

Note: Once an Ansible Vault has been created, it always remains encrypted in the file. Decryption only takes place in the editor’s memory. Each time the Ansible Vault is saved, the editor content is encrypted on-the-fly.

Support for encryption of individual variables

An Ansible Vault can be created directly in the editor from a variable in the Ansible code.

Ansible Vaults inserted in Ansible code can be easily decrypted via the context menu in the editor.

Note: Encrypting and decrypting variables are final. A decrypted variable is also stored in the saved file as plain text.

Quick Documentation

  • Shows a popup with documentation for an Ansible keyword via mouse-over or keyboard shortcut
  • Shows a popup with documentation for an Ansible module via mouse-over or keyboard shortcut
  • Alternative display of the documentation in the tool window
  • Display of comments and the argument spec description value for Jinja2 variables

Display of Ansible documentation

For Ansible code such as modules, module arguments, and keywords, the corresponding documentation can be displayed directly in the editor via popup or Tool Windows.

This documentation can also be displayed during code completion.

Note: An OrchidE-Ansible definition package must be configured to display the documentation. (Languages & Frameworks | OrchidE | Extension)

Display of documentation from argument spec description

In inventory variable files, the documentation/description from the argument_spec file for variables can be displayed if it is a role variable.

Note: The variable must be provided with the OrchidE Role annotation for the corresponding description to be found. If the variable is not directly annotated, an annotation is searched for in the previous lines.

Inspections

  • Recognition of non-unique Ansible module names
  • Detection of duplicate variable declarations and keywords
  • Detection of missing files for import/include modules
  • Recognition of undefined Jinja2 variables
  • Recognition of unknown playbook, task, roles and block keywords
  • Recognition of unknown module arguments
  • Detection when a keyword value has an incorrect type
  • Detection when a module argument value has an incorrect type
  • Reference to role annotation in variable files for code completion of argument_spec variables

Recognition of non-unique module names

If the namespace / collection name is omitted for Ansible modules, OrchidE displays a warning if the module name is not unique, i.e., can occur in several collections.

Recognition takes the collections keyword into account. If collections is defined, only collections listed there are checked.

Detection of duplicate variables and keywords

If Keys are used twice where it is syntactically not allowed, OrchidE displays a warning and allows you to simply delete an entry.

Detection of missing import files

If referenced files are not found, OrchidE displays a warning. The detection is available for import_tasks, include_tasks, template src-argument, import_playbook and vars_files.

OrchidE provides a quick way to create the file. Any Ansible’s search path is supported, depending on the context in the editor; any of the following locations are possible: current folder, template folder, relative paths, role folder, playbook folder.

The warning can be hidden with the annotation “#noinspection MissingFileReference”

Recognition of undefined variables

If there is no definition of referenced Jinja2 template variables, OrchidE displays a warning.

The search for variables is carried out globally in all variable files in the IntelliJ project. For lists of hashes, all list entries must contain all sub keys. Otherwise, a warning will also be displayed.

Variables set with register or set_fact are only taken into account in the correct context.

Ansible’s keywords such as item and variables with default filters are not checked.

The warning can be hidden with the annotation “#noinspection UndefinedVariable.”

Ignoring variables with password or apikey in the name can be activated in the settings.

Recognition of unknown keys

If invalid keys are used in playbooks, roles or Ansible modules, OrchidE displays a warning.

Detection of incorrect value types

If the value of Ansible keywords or module arguments are of the wrong type, OrchidE displays a warning.

Intentions

  • Creation of files that are referenced with import/include modules
  • Creation of groups/hosts variables based on Jinja2 template variables
  • Creation of variables in roles (vars/defaults) based on Jinja2 template variables

Creation of files (import/include)

If an import/include file does not exist, the file can simply be created via this intention.

If the value for the file name contains Jinja variables that can be resolved, such files can also be created with the intention.

Various values are stored in the OrchidE Definition Package for the Ansible fact variables ansible_distribution, ansible_os_family, ansible_system, ansible_distribution_major_version and ansible_pgk_mgr, so that files with these variables can also be created easily and in several variants.

Creation of Jinja2 variables

The intention creates variables from Jinja2 template variables. There are three intentions to create the variable:

  • as a host or group variable in the inventory,
  • as a role variable in defaults or,
  • as a role variable in vars.

Ansible Galaxy collections

  • Supports over 10000 modules from Ansible Galaxy Collections for Code Completion and Quick Documentation
  • Expandable with additional Ansible Galaxy Collections
  • Prefabricated packages for Ansible releases

Ansible Galaxy collection support

OrchidE supports code completion, syntax and error highlighting and the display of documentation in the editor based on the Ansible Collections documentation.

For this purpose, the OrchidE Builder can be used to create an OrchidE definition package from a set of Ansible Collections and integrate it into OrchidE.

For various Ansible versions, there are ready packages on GitHub for download.

In addition, there is a regular download of the current Ansible collections from Ansible Galaxy with over 10,000 Ansible modules, which contains all collections of the current Ansible version and the most downloaded collections.

The package is configured in _Languages & Frameworks OrchidE Extension_.

Structured View

  • Ansible focused project tree for a better overview of the Ansible project

Ansible project tree view

The Ansible Project Tree View is an alternative, compact view of the Ansible files in an IntelliJ project and thus presents the structure of Ansible inventories and roles more clearly.

Jinja2 templates

  • Ansible focused support for Jinja2 templates of properties, xml, json, yml and plain-text files
    • Code completion of Ansible variables
    • Breadcrumb from Jinja2 template structures (if, for)
    • Error highlight for missing Close Jinja2 structures (if, for, set)
    • Warnings if Ansible variables are not defined

Support Jinja2 templates

For supported file formats, there are Jinja2 Template Code Completion for Ansible Jinja2 Template Variables and the Inspection “Undefined Variable”.

The recognition of Jinja2 templates is based on the original file extension + .j2.