|
| 1 | +# Linting and Code Quality |
| 2 | + |
| 3 | +This document describes the linting and code quality checks used in the Algo VPN project. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +The project uses multiple linters to ensure code quality across different file types: |
| 8 | +- **Ansible** playbooks and roles |
| 9 | +- **Python** library modules and tests |
| 10 | +- **Shell** scripts |
| 11 | +- **YAML** configuration files |
| 12 | + |
| 13 | +## Linters in Use |
| 14 | + |
| 15 | +### 1. Ansible Linting |
| 16 | +- **Tool**: `ansible-lint` |
| 17 | +- **Config**: `.ansible-lint` |
| 18 | +- **Checks**: Best practices, security issues, deprecated syntax |
| 19 | +- **Key Rules**: |
| 20 | + - `no-log-password`: Ensure passwords aren't logged |
| 21 | + - `no-same-owner`: File ownership should be explicit |
| 22 | + - `partial-become`: Avoid unnecessary privilege escalation |
| 23 | + |
| 24 | +### 2. Python Linting |
| 25 | +- **Tools**: |
| 26 | + - `ruff` - Fast Python linter (replaces flake8, isort, etc.) |
| 27 | + - `black` - Code formatter |
| 28 | + - `mypy` - Type checker |
| 29 | + - `bandit` - Security linter |
| 30 | +- **Config**: `pyproject.toml` |
| 31 | +- **Style**: 120 character line length, Python 3.10+ |
| 32 | + |
| 33 | +### 3. Shell Script Linting |
| 34 | +- **Tool**: `shellcheck` |
| 35 | +- **Checks**: All `.sh` files in the repository |
| 36 | +- **Catches**: Common shell scripting errors and pitfalls |
| 37 | + |
| 38 | +### 4. YAML Linting |
| 39 | +- **Tool**: `yamllint` |
| 40 | +- **Config**: `.yamllint` |
| 41 | +- **Rules**: Extended from default with custom line length |
| 42 | + |
| 43 | +### 5. Security Scanning |
| 44 | +- **Tools**: |
| 45 | + - `bandit` - Python security issues |
| 46 | + - `safety` - Known vulnerabilities in dependencies |
| 47 | + - `zizmor` - GitHub Actions security (run separately) |
| 48 | + |
| 49 | +## CI/CD Integration |
| 50 | + |
| 51 | +### Main Workflow (`main.yml`) |
| 52 | +- **syntax-check**: Validates Ansible playbook syntax |
| 53 | +- **basic-tests**: Runs unit tests including validation tests |
| 54 | + |
| 55 | +### Lint Workflow (`lint.yml`) |
| 56 | +Separate workflow with parallel jobs: |
| 57 | +- **ansible-lint**: Ansible best practices |
| 58 | +- **yaml-lint**: YAML formatting |
| 59 | +- **python-lint**: Python code quality |
| 60 | +- **shellcheck**: Shell script validation |
| 61 | +- **security-checks**: Security scanning |
| 62 | + |
| 63 | +## Running Linters Locally |
| 64 | + |
| 65 | +```bash |
| 66 | +# Ansible |
| 67 | +ansible-lint -v *.yml roles/{local,cloud-*}/*/*.yml |
| 68 | + |
| 69 | +# Python |
| 70 | +ruff check . |
| 71 | +black --check . |
| 72 | +mypy library/ |
| 73 | + |
| 74 | +# Shell |
| 75 | +find . -name "*.sh" -exec shellcheck {} \; |
| 76 | + |
| 77 | +# YAML |
| 78 | +yamllint . |
| 79 | + |
| 80 | +# Security |
| 81 | +bandit -r library/ |
| 82 | +safety check |
| 83 | +``` |
| 84 | + |
| 85 | +## Current Status |
| 86 | + |
| 87 | +Most linters are configured to warn rather than fail (`|| true`) to allow gradual adoption. As code quality improves, these should be changed to hard failures. |
| 88 | + |
| 89 | +### Known Issues to Address: |
| 90 | +1. Python library modules need formatting updates |
| 91 | +2. Some Ansible tasks missing `changed_when` conditions |
| 92 | +3. YAML files have inconsistent indentation |
| 93 | +4. Shell scripts could use more error handling |
| 94 | + |
| 95 | +## Contributing |
| 96 | + |
| 97 | +When adding new code: |
| 98 | +1. Run relevant linters before committing |
| 99 | +2. Fix any errors (not just warnings) |
| 100 | +3. Add linting exceptions only with good justification |
| 101 | +4. Update linter configs if adding new file types |
0 commit comments