Workflow¶
This page walks through the typical workflow of using algorilla on a project: scan, triage, fix or accept, repeat.
1. Scan your project¶
Point algorilla at your project root. It auto-detects the build system and source directories:
For a first run on a large codebase, start with warnings only:
Or focus on a single rule:
List available rules
Run algorilla --list-rules to see all built-in rules with their severity, category, and supported languages.
2. Read the output¶
Findings are grouped by file and sorted by severity (errors first, then warnings, then info). Each finding shows:
- The severity and rule ID
- The source location and a code snippet
- A description of what was detected
- A suggestion for how to fix it
- An evidence chain tracing the path to the bottleneck
- A fingerprint hash (the
# abcdef1234567890at the end) used for accepting findings
See Understanding Output for a detailed breakdown.
3. Triage: is this real?¶
Not every finding needs a fix. Look at:
- The evidence chain. Does the loop actually iterate over a large collection? A
contains()call on a 3-element list is harmless. - The execution context. Is this code on a hot path, or a one-time startup routine?
- The suggestion. Does it make sense for your codebase?
4. Fix, suppress, or accept¶
Fix it¶
Apply the suggestion, then re-run algorilla. The finding disappears:
Caching makes re-scans fast — only changed files are re-analyzed.
Suppress inline¶
If a finding is wrong for a specific line (e.g. the collection is known to be small), suppress it with a comment:
See Suppression for all options.
Accept it (ignore list)¶
If a finding is valid code that you've reviewed and decided is acceptable, accept it by fingerprint. Each finding shows a fingerprint hash in the output:
Accept one or more findings:
This adds the finding to .algorilla/ignore-list.json. On subsequent runs, accepted findings are hidden automatically. The ignore list is project-local and can be committed to version control.
The difference between suppress and accept:
| Inline suppress | Accept (ignore list) | |
|---|---|---|
| Where | Comment in source code | .algorilla/ignore-list.json |
| Scope | Specific line | Finding by content fingerprint |
| Survives line shifts | No (tied to line number) | Yes (content-based matching) |
| Visible in code | Yes | No |
Disable a rule entirely¶
If a rule consistently produces findings that aren't relevant to your project:
5. Ongoing use¶
Track progress¶
On a legacy codebase, save a baseline so you only see new findings going forward:
# on main branch:
algorilla --save-baseline .algorilla/baseline.json .
# on a feature branch:
algorilla --baseline .algorilla/baseline.json .
See Baseline Workflow for details.
CI integration¶
By default, algorilla fails the build (exit 1) when it finds warnings or errors. Use --fail-on to adjust:
# default: fail on warnings and errors
algorilla --format sarif -o results.sarif .
# lenient: fail only on errors (warnings are advisory)
algorilla --fail-on error --format sarif -o results.sarif .
# strict: fail even on info-level findings
algorilla --fail-on info --format sarif -o results.sarif .
See CI Integration for GitHub Actions and GitLab CI examples.
Quick reference¶
| Task | Command |
|---|---|
| Scan project | algorilla . |
| Warnings only | algorilla --severity warning . |
| Single rule | algorilla --rule nested-lookup . |
| List rules | algorilla --list-rules |
| Accept a finding | algorilla --accept <hash> . |
| Save baseline | algorilla --save-baseline .algorilla/baseline.json . |
| Compare to baseline | algorilla --baseline .algorilla/baseline.json . |
| CI (default: fail on warnings) | algorilla --format sarif -o results.sarif . |
| CI (fail on errors only) | algorilla --fail-on error --format sarif -o results.sarif . |