You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: DRY_RUN_MODE.md
+38-72Lines changed: 38 additions & 72 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,32 @@ The Pysonar scanner supports a **dry-run mode** that helps you troubleshoot conf
7
7
- Validating configuration properties
8
8
- Debugging analysis failures related to configuration
9
9
10
+
## Use Cases
11
+
12
+
### 1. Validating Configuration Before First Analysis
13
+
14
+
Use dry-run mode to verify your configuration is correct before running a full analysis. This is especially useful when setting up new projects or making configuration changes:
This validates all configuration sources (pyproject.toml, environment variables, CLI arguments) and checks that coverage report paths are valid before submitting any analysis. This also helps ensure that environment variables, CLI arguments, and configuration files are being read correctly.
31
+
32
+
### 2. Troubleshooting Failed Analysis
33
+
34
+
If an analysis fails, use dry-run mode to quickly identify configuration issues without waiting for a full analysis. This is especially useful for catching problems with configuration files, environment variables, or required properties before attempting a full analysis.
35
+
10
36
## Enabling Dry Run Mode
11
37
12
38
To run the scanner in dry-run mode, add the `--dry-run` flag:
@@ -79,101 +105,44 @@ DRY RUN MODE - Validation Results
79
105
80
106
## Coverage Report Validation
81
107
82
-
The scanner validates coverage reports by checking:
108
+
The scanner performs basic validation of coverage reports by checking:
83
109
84
110
1.**File existence** - Verifies that the file exists at the specified path
85
111
2.**File readability** - Ensures the file is readable and accessible
86
-
3.**File format** - Validates that coverage reports are in valid Cobertura XML format
112
+
3.**XML format** - Validates that the file can be parsed as valid XML
87
113
4.**Root element** - Checks that XML root element is `<coverage>` (expected Cobertura format)
88
114
115
+
Note: This is a basic sanity check and does not perform full schema validation of the Cobertura format.
116
+
89
117
### Example: Coverage Report Validation Output
90
118
91
119
Successful validation:
92
120
93
121
```
94
122
Coverage Report Paths: coverage.xml
95
123
96
-
✓ Coverage report is valid Cobertura XML: coverage.xml
124
+
✓ Coverage report check passed: coverage.xml
97
125
```
98
126
99
127
Missing file error:
100
128
101
129
```
102
130
✗ Configuration validation FAILED with the following issues:
103
-
• Coverage report not found: coverage.xml (resolved to /project/coverage.xml)
131
+
✗ Coverage report not found: coverage.xml (resolved to /project/coverage.xml)
104
132
```
105
133
106
134
Invalid format error:
107
135
108
136
```
109
137
✗ Configuration validation FAILED with the following issues:
110
-
• Coverage report is not valid XML (Cobertura format): coverage.xml
111
-
Parse error: XML not well-formed (invalid token)
138
+
✗ Coverage report is not valid XML (Cobertura format): coverage.xml (Parse error: XML not well-formed (invalid token))
112
139
```
113
140
114
141
## Exit Codes
115
142
116
143
-**0**: Configuration validation passed, no errors found
117
144
-**1**: Configuration validation failed, errors were found
118
145
119
-
## Use Cases
120
-
121
-
### 1. Validating Coverage Report Paths
122
-
123
-
Before running a full analysis, verify that coverage reports are correctly configured:
0 commit comments