Committing the VS Code Ansible settings with the repository

ansible - 2026-09-29

Sixth entry in the Ansible development environment series. Part 4 chose where VS Code runs and part 5 installed the tools. This part makes every developer's editor behave the same way on a given repository. The means is two small files committed next to the code: one for settings and one for recommended extensions. The settings configure the Red Hat Ansible extension (redhat.ansible), which adds syntax checking, ansible-lint, completion and module docs to VS Code.

Every setting below was checked against the extension's own manifest, the package.json in ansible/vscode-ansible as of 2026-09-29. The released extension was 26.8.2 at the time.

Where the files go

VS Code reads settings from several scopes, and "later scopes override earlier scopes": default, then user, then remote, then workspace, then workspace folder. A workspace is usually just the project folder, and its settings live in .vscode/settings.json, which VS Code picks up when the folder is opened. Committed to Git, they apply to everyone who opens the repository, and they win over each developer's personal settings.

A multi-root workspace, several folders opened together, keeps its settings in a *.code-workspace file instead. Dworjan's repositories use one, .code-workspace, because his Dev Spaces workspaces open through it. For a repository opened as a plain folder, .vscode/settings.json is the simpler choice.

`.vscode/settings.json`

{
  "ansible.validation.enabled": true,
  "ansible.validation.lint.enabled": true,
  "ansible.ansible.useFullyQualifiedCollectionNames": true,
  "ansible.executionEnvironment.enabled": true,
  "ansible.executionEnvironment.image": "registry.example.com/ansible/my-ee@sha256:c89caf41bc7dfc6aa701f1225b2177cfb711223693c89a3300d7ac8db2b3b897",
  "ansible.executionEnvironment.pull.policy": "missing",
  "files.insertFinalNewline": true,
  "files.trimFinalNewlines": true,
  "files.trimTrailingWhitespace": true
}

What each line does, and what the manifest says its default is:

Setting	Default	Why set it
`ansible.validation.enabled`	`true`	Already on. Stating it in the workspace overrides a developer who turned it off in their user settings
`ansible.validation.lint.enabled`	`true`	Same: keeps ansible-lint on. When off, only `ansible-playbook --syntax-check` runs
`ansible.ansible.useFullyQualifiedCollectionNames`	`true`	Same: completion inserts `ansible.builtin.copy` rather than `copy`
`ansible.executionEnvironment.enabled`	`false`	Runs the extension's ansible-lint and docs inside an execution environment (EE), the container image AAP (Red Hat Ansible Automation Platform) runs jobs in. Completion then knows exactly the collections production has
`ansible.executionEnvironment.image`	`ghcr.io/ansible/community-ansible-dev-tools:latest`	Must be set. Without it, "EE enabled" means the generic ADT image, not your EE. Use the digest part 3 pushed, not a tag
`ansible.executionEnvironment.pull.policy`	`missing`	`missing` pulls only when the image isn't present locally. With a digest that's exactly right: a new digest is a new image. With a `:latest` tag, `missing` never picks up updates. Other values: `always`, `never`, `tag`
`files.Newline`, `files.trimTrailingWhitespace`	off	VS Code core settings. Fixes, on save, the whitespace findings ansible-lint's YAML rules would otherwise report

Two settings from Dworjan's workspace file are left out on purpose: - "files.associations": {"*.yml": "ansible"} isn't needed and does harm. The extension already declares Ansible files by path: playbooks/*.yml, *playbook*.yml, roles/**/main.yml, tasks/, handlers/, defaults/, vars/, meta/, group_vars/, host_vars/, molecule/*/molecule.yml, plus site.yml, requirements.yml, galaxy.yml and execution-environment.yml. Mapping every *.yml would also lint .github/workflows/*.yml or a Compose file as Ansible. If a playbook sits outside those patterns, add that one path, such as "deploy.yml": "ansible". - ansible.python.interpreterPath ("/usr/bin/python3.12" in his file) depends on the machine. Its manifest scope is machine-overridable, meaning each machine is expected to set its own. Commit it only where the path is fixed, inside a Dev Container or Dev Spaces image.

`.vscode/extensions.json`

{
  "recommendations": ["redhat.ansible"]
}

On desktop VS Code this only suggests: per VS Code's docs, "VS Code prompts a user to install the recommended extensions" when the folder is opened. One entry is enough. The manifest makes redhat.vscode-yaml, ms-python.python and ms-python.vscode-python-envs dependencies (extensionDependencies), so installing redhat.ansible brings them. Add redhat.vscode-redhat-account only if the team uses Ansible Lightspeed, which signs in through it.

How each environment from part 4 picks them up

Desktop VS Code and Remote-SSH: .vscode/settings.json applies on opening the folder, and extensions.json produces the install prompt.
Dev Container: the settings file applies the same way. To install extensions without a prompt, list them in devcontainer.json under customizations.vscode.extensions, as the scaffold in part 4 does.
Dev Spaces / Eclipse Che: Dworjan's Dev Spaces guide relies on .vscode/extensions.json being installed automatically when a workspace starts, and on a .code-workspace file for the settings.

Once the EE is set, lint and completion come from the same image the playbook runs in under ansible-navigator, and in AAP.

Sources

The Ansible extension's manifest, package.json in ansible/vscode-ansible at commit 509d149 (2026-09-29): every setting name, default, scope and enum value above, the extensionDependencies, and the filenamePatterns for the ansible language. Released version from Open VSX: 26.8.2.
VS Code docs: settings (precedence, and .vscode for workspace settings) and workspace recommended extensions (the install prompt).
Alex Dworjan: Ansible VSCode Extension (2022), Dev Spaces with Execution Environments (2026), and his repository's .code-workspace and .vscode/extensions.json.

Created 2026-09-29T23:47:44+02:00 · Edit