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
feat(scanning): enhance repository synchronization with rename detection and deletion
- Add automatic repository rename detection and updates when repositories are renamed in GitHub
- Add automatic repository deletion when repositories no longer exist in GitHub organization
- Add cascading deletion of related records (PolicyViolations and ActionLogs) before removing repositories
- Add comprehensive logging for repository operations (add, rename, remove) with detailed information
- Refactor SyncRepositoriesAsync to use dictionary lookups for improved performance
- Add unit tests for repository deletion and rename scenarios
- Update documentation to reflect repository synchronization capabilities
This ensures the database stays in sync with GitHub organization state without manual intervention.
Copy file name to clipboardExpand all lines: docs/hangfire-integration.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -125,6 +125,16 @@ The `ActionService` processes violations by:
125
125
126
126
This decouples the scanning process from the action-taking process. This is a robust design because even if the action-taking process fails, it can be retried independently from the scan itself, and the scan results are already safely stored in the database.
127
127
128
+
### Repository Synchronization During Scans
129
+
130
+
During each scan, the `ScanningService` automatically synchronizes the database with the current state of the GitHub organization:
131
+
132
+
-**New Repositories**: Detected and added to the database
-**Deleted Repositories**: Removed from database with cascading cleanup of related records
135
+
136
+
This ensures that the compliance dashboard always reflects the current state of your GitHub organization, even as repositories are added, renamed, or removed over time.
137
+
128
138
## Best Practices
129
139
130
140
-**Idempotent Jobs**: Whenever possible, design background jobs to be idempotent. This means that running the job multiple times with the same input will produce the same result. Hangfire has built-in retry mechanisms, so idempotent jobs are safer to run.
Copy file name to clipboardExpand all lines: docs/policy-evaluation.md
+24-6Lines changed: 24 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,12 +16,30 @@ The key components of the architecture are:
16
16
17
17
1. The `ScanningService` initiates a scan.
18
18
2. It retrieves the policy configuration from the `.github/config.yaml` file.
19
-
3. For each repository in the organization, it calls `IPolicyEvaluationService.EvaluateRepositoryAsync()`.
20
-
4. The `PolicyEvaluationService` uses dependency injection to get all registered `IPolicyEvaluator` implementations.
21
-
5. It matches the `type` of each policy in the configuration with the `PolicyType` property of the available evaluators.
22
-
6. When a match is found, it executes the `EvaluateAsync` method of that specific evaluator.
23
-
7. If the evaluator finds a violation, it returns a `PolicyViolation` object.
24
-
8. The `ScanningService` collects all violations and saves them to the database.
19
+
3. It synchronizes policies from the configuration file with the database (adds new policies if needed).
20
+
4. It synchronizes repositories between GitHub and the database:
21
+
- Adds new repositories that exist in GitHub but not in the database
22
+
- Updates repository names if repositories were renamed in GitHub
23
+
- Removes repositories that no longer exist in GitHub (with cascading deletion of related PolicyViolations and ActionLogs)
24
+
5. For each repository in the organization, it calls `IPolicyEvaluationService.EvaluateRepositoryAsync()`.
25
+
6. The `PolicyEvaluationService` uses dependency injection to get all registered `IPolicyEvaluator` implementations.
26
+
7. It matches the `type` of each policy in the configuration with the `PolicyType` property of the available evaluators.
27
+
8. When a match is found, it executes the `EvaluateAsync` method of that specific evaluator.
28
+
9. If the evaluator finds a violation, it returns a `PolicyViolation` object.
29
+
10. The `ScanningService` collects all violations and saves them to the database.
30
+
11. After the scan completes, it enqueues a background job to process automated actions for the violations found.
31
+
32
+
### Repository Synchronization
33
+
34
+
The `ScanningService` ensures that the database repository list stays synchronized with the GitHub organization:
35
+
36
+
-**New Repositories**: Automatically detected and added to the database with status "Pending"
37
+
-**Renamed Repositories**: Detection based on GitHub repository ID (which remains constant across renames). Repository names are automatically updated in the database.
38
+
-**Deleted Repositories**: Repositories that no longer exist in GitHub are removed from the database, along with their related records:
39
+
- Policy violations associated with the repository
40
+
- Action logs for actions taken on the repository
41
+
42
+
This synchronization happens automatically during each scan, ensuring the database always reflects the current state of the GitHub organization.
0 commit comments