|
| 1 | +# Copilot Instructions for docker-diskmark |
| 2 | + |
| 3 | +## Project Overview |
| 4 | + |
| 5 | +Docker DiskMark is a fio-based disk benchmarking tool packaged as a minimal Docker container. It provides CrystalDiskMark-like functionality for Linux systems. |
| 6 | + |
| 7 | +## Project Structure |
| 8 | + |
| 9 | +``` |
| 10 | +diskmark.sh # Main entry point (~100 lines) |
| 11 | +lib/ |
| 12 | +├── args.sh # CLI argument parsing + help/version |
| 13 | +├── validate.sh # Input validation functions |
| 14 | +├── utils.sh # Utility functions (color, size conversion, cleanup) |
| 15 | +├── profiles.sh # Profile definitions (default, nvme, custom job) |
| 16 | +├── detect.sh # Drive/filesystem detection |
| 17 | +├── benchmark.sh # fio benchmark execution + warmup + result parsing |
| 18 | +├── output.sh # Output formatting (human/JSON/YAML/XML) |
| 19 | +└── update.sh # Update check functionality |
| 20 | +``` |
| 21 | + |
| 22 | +## Clean Code Principles |
| 23 | + |
| 24 | +Follow these clean code principles when contributing: |
| 25 | + |
| 26 | +### Single Responsibility |
| 27 | +- Each function should do one thing and do it well |
| 28 | +- Keep functions small and focused (ideally < 30 lines) |
| 29 | +- Separate concerns: parsing, validation, execution, output |
| 30 | + |
| 31 | +### Meaningful Names |
| 32 | +- Use descriptive function names: `validate_size_string` not `check` |
| 33 | +- Use consistent naming conventions (snake_case for functions/variables) |
| 34 | +- Prefix validation functions with `validate_` |
| 35 | +- Prefix parsing functions with `parse_` |
| 36 | + |
| 37 | +### DRY (Don't Repeat Yourself) |
| 38 | +- Extract common patterns into reusable functions |
| 39 | +- Use helper functions for repeated validation logic |
| 40 | +- Centralize error handling and output formatting |
| 41 | + |
| 42 | +### Comments and Documentation |
| 43 | +- Functions should be self-documenting through clear names |
| 44 | +- Add comments only when explaining "why", not "what" |
| 45 | +- Keep help text and documentation in sync with code |
| 46 | + |
| 47 | +### Error Handling |
| 48 | +- Fail fast with clear error messages |
| 49 | +- Validate inputs early before processing |
| 50 | +- Use consistent exit codes (0=success, 1=error) |
| 51 | + |
| 52 | +### Code Organization |
| 53 | +- Group related functions together |
| 54 | +- Order: constants → helpers → validators → core logic → main |
| 55 | +- Keep configuration separate from logic |
| 56 | + |
| 57 | +## Shell Script Best Practices |
| 58 | + |
| 59 | +- Use `set -e` to exit on errors |
| 60 | +- Quote variables: `"$VAR"` not `$VAR` |
| 61 | +- Use `[[` for conditionals (bash) |
| 62 | +- Prefer `local` variables in functions |
| 63 | +- Use meaningful return codes |
| 64 | +- Avoid global state when possible |
| 65 | + |
| 66 | +## Testing Guidelines |
| 67 | + |
| 68 | +- All features should have corresponding tests in `.github/workflows/tests.yml` |
| 69 | +- Test both valid and invalid inputs |
| 70 | +- Test CLI arguments in all formats: `--key value`, `--key=value`, `-k value` |
| 71 | +- Use dry-run mode for input validation tests |
| 72 | +- Use minimal sizes/runtimes for actual benchmark tests |
| 73 | + |
| 74 | +## Docker Best Practices |
| 75 | + |
| 76 | +- Keep the container minimal (scratch-based) |
| 77 | +- Only include necessary binaries |
| 78 | +- Use multi-stage builds |
| 79 | +- Set appropriate defaults via ENV |
| 80 | +- Run as non-root user (65534:65534) |
| 81 | + |
| 82 | +## Output Formats |
| 83 | + |
| 84 | +The tool supports multiple output formats: |
| 85 | +- Human-readable (default): colored, with emojis |
| 86 | +- JSON: structured, machine-readable |
| 87 | +- YAML: structured, human-friendly |
| 88 | +- XML: structured, enterprise-compatible |
| 89 | + |
| 90 | +When modifying output, ensure all formats are updated consistently. |
0 commit comments