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.
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.
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.
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.
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.
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.
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.
Ansible task blocks can be easily moved up/down with OrchidE.
Moving is done via the IntelliJ Action “Move Statement up/down”.
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.
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:
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 Action “Go to Related Item”.
You can navigate directly to the definition of Jinja2 variables.
- name: Sample
debug:
msg: "{{ a_variable }}"
Navigation takes place via the IntelliJ Action “Go to Declaration or Usages”.
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 Action “Go to Declaration or Usages”.
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 Action “Go to Declaration or Usages”.
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 Action “Go to Declaration or Usages”.
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 Action “Go to Declaration or Usages”.
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 Action “Go to Declaration or Usages”.
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.
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.
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)
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.
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.
If Keys are used twice where it is syntactically not allowed, OrchidE displays a warning and allows you to simply delete an entry.
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”
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.
If invalid keys are used in playbooks, roles or Ansible modules, OrchidE displays a warning.
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.
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_. |
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.
