Linting automatically analyzes infrastructure code or configuration to detect nonstandard style, invalid constructs, and incorrect field names before execution or commit. It catches mistakes such as using ip instead of ip_address and can enforce security rules, including preventing secrets from entering version control. section 2.3.2
Apply linting as an early, repeatable check:
- Run linting before committing infrastructure code, alongside formatting checks for spacing and configuration structure. section 2.3.2
- Add version-control hooks or CI checks so contributors receive consistent validation rather than relying on manual review. section 2.3.2 section 5.1.3
- Centralize shared linting and formatting tests in a prototype module when multiple repositories must follow the same standards. section 5.1.3
- Extend rules to security, naming, resource limits, and other team standards; treat linting as an early check, not production protection by itself. section 2.3.2 section 6.2.3
Catching an invalid infrastructure field
A server configuration requires the field ip_address, but a contributor writes ip. Linting identifies the nonstandard field during development, before the infrastructure can fail at creation time. section 2.3.2
Figure 5.7 Creating a prototype module that contains all of the checks for module repositoryformat will help fix older repositories that do not conform to new standards.
A shared prototype module containing repository-format checks helps older and less frequently used modules conform to newly introduced linting standards. section 5.1.3
