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
This repository integrates **CodeRabbit** as an automated AI-powered code review (CR) agent.
4
+
5
+
CodeRabbit analyzes every pull request and provides structured, context-aware feedback directly on the PR, helping improve overall code quality, maintainability, and consistency across the project.
6
+
7
+
---
8
+
9
+
## 🎯 Purpose
10
+
11
+
The goal of using CodeRabbit in this project is to serve as a **first-line automated code reviewer** that assists both contributors and maintainers by:
12
+
13
+
- Summarizing the intent and scope of each pull request
14
+
- Highlighting potential bugs, edge cases, and logical issues
15
+
- Suggesting improvements related to code quality, readability, and best practices
16
+
- Identifying maintainability, performance, and security concerns early
17
+
18
+
CodeRabbit complements human reviewers and our internal CR agents. It is not intended to replace manual reviews, but to strengthen and accelerate them.
19
+
20
+
---
21
+
22
+
## ⚙️ How It Works
23
+
24
+
CodeRabbit is automatically triggered via **GitHub Actions** on every:
25
+
26
+
- Newly opened pull request
27
+
- Updated pull request (new commits)
28
+
- Reopened pull request
29
+
30
+
Once triggered, CodeRabbit:
31
+
32
+
1. Analyzes the code changes in the context of the repository
33
+
2. Posts a high-level summary explaining what the PR introduces
34
+
3. Adds inline review comments on relevant lines in the diff
35
+
4. Provides actionable suggestions to improve code quality and structure
36
+
37
+
All feedback appears directly inside the pull request conversation and diff view.
38
+
39
+
---
40
+
41
+
## 🧠 Role in the Application
42
+
43
+
Within this project’s agentic AI system, CodeRabbit operates as a **general-purpose CR agent**, focusing on:
44
+
45
+
- Broad software engineering best practices
46
+
- Cross-file change awareness
47
+
- Early issue detection
48
+
- Developer-oriented feedback
49
+
50
+
It works alongside our internal AI CR assistant, which focuses on project-specific logic, architectural reasoning, and workflow validation. Together, they form a multi-agent automated code review pipeline.
51
+
52
+
---
53
+
54
+
## 🧩 Benefits
55
+
56
+
- Faster review cycles
57
+
- Higher baseline code quality
58
+
- Reduced reviewer fatigue
59
+
- More consistent feedback across pull requests
60
+
- Early detection of issues before human review
61
+
62
+
---
63
+
64
+
## 🔁 Continuous Improvement
65
+
66
+
CodeRabbit continuously adapts through interaction in pull requests and repository-level configuration, allowing its reviews to better align over time with the project’s conventions and expectations.
This folder contains all CI/automation scripts and workflows for GitHub Actions.
4
+
5
+
## Overview
6
+
7
+
Workflows are configured to run automated tasks using GitHub Actions. For complex operations, we use dedicated scripts (in `.github/scripts/`) that are invoked from the workflow files.
8
+
9
+
## Available Workflows
10
+
11
+
-**backup-dbs.yaml** - Automated database backups for MongoDB and Qdrant (backups are being uploaded to internal gitlab and have no retention at the moment)
12
+
-**verify-agent-deps.yaml** - Dependency verification for agents
13
+
14
+
15
+
16
+
## Prerequisites
17
+
18
+
1. GitHub must be able to access the target cluster **OR** you must have a self-hosted runner that can access both GitHub and the cluster (see [Creating a Runner](#creating-a-runner) below)
19
+
2. GitHub Environments must be configured with the appropriate variables and secrets for each cluster (e.g., `PRE-PRODUCTION`, `PRODUCTION`)
20
+
21
+
### Important Notes
22
+
23
+
- Since every deployment is a bit different. the existing workflows won't necessarily work out of the box for deployment different from the one currently in use. Users wanting to deploy UnifAI in their own clusters should be aware of the infra and networking to either fit the workflow to their needs or create a new workflow that fits it.
24
+
- When using runners, the `runs-on` field refers to **labels**, not runner names. Ensure matching labels exist before running workflows.
25
+
- Environment-specific variables (like `QDRANT_URL`, `MONGO_URI`, `API_URL`) must be configured in GitHub repository settings under **Environments**.
26
+
27
+
## GitHub Environments Setup
28
+
29
+
The workflows use GitHub Environments to manage cluster-specific configurations:
30
+
31
+
1. Go to **Settings** → **Environments** in your repository
32
+
2. Create environments matching your cluster names (e.g., `PRE-PRODUCTION`, `PRODUCTION`)
33
+
3. Add environment-specific variables:
34
+
-`API_URL` - Kubernetes API server URL
35
+
-`MONGO_URI` - MongoDB connection string
36
+
-`QDRANT_URL` - Qdrant cluster URL
37
+
4. Add environment-specific secrets:
38
+
-`ACCESS_TOKEN` - Kubernetes access token
39
+
- Other sensitive credentials as needed
40
+
41
+
## Database Backup Details
42
+
43
+
### MongoDB Backup
44
+
45
+
MongoDB backups are performed using `mongodump`, which is straightforward:
-`--uri` - Connection string to the MongoDB instance to backup
53
+
-`--out` - Target directory for the backup (creates a new folder)
54
+
-`--db` (optional) - Specific database name (default: all databases)
55
+
56
+
### Qdrant Backup
57
+
58
+
Qdrant backups require creating snapshots via the API or UI. The workflow uses a Python script (`.github/scripts/qdrant_backup.py`) to:
59
+
1. Connect to the Qdrant cluster
60
+
2. Create snapshots for all collections
61
+
3. Download the snapshots locally
62
+
4. Upload them to the backup repository
63
+
64
+
For more details, see the [Qdrant documentation](https://qdrant.tech/documentation/database-tutorials/create-snapshot/).
65
+
66
+
## Running Workflows Manually
67
+
68
+
### Prerequisites
69
+
70
+
1. The workflow must have the `workflow_dispatch` trigger enabled
71
+
2. GitHub CLI must be installed and authenticated
72
+
3. The workflow file must exist in the `main` branch (workflows in feature branches cannot be manually triggered)
73
+
74
+
### Example Command
75
+
76
+
```bash
77
+
gh workflow run backup-dbs.yaml \
78
+
-f target_cluster=PRE-PRODUCTION \
79
+
-f target_branch=GENIE-1071/backup_dbs \
80
+
-f target_namespace=tag-ai--pipeline
81
+
```
82
+
83
+
**Parameters:**
84
+
-`-f target_cluster` - The cluster environment to backup (must match a configured GitHub Environment)
85
+
-`-f target_branch` - The branch to checkout for the workflow
86
+
-`-f target_namespace` - The Kubernetes namespace to backup
87
+
88
+
## Appendix
89
+
90
+
### Creating a Runner
91
+
92
+
To create a new self-hosted runner:
93
+
94
+
1. Go to your repository's **Settings** tab
95
+
2. In the left sidebar, select **Actions** → **Runners**
96
+
3. Click **New self-hosted runner**
97
+
4. Follow the setup instructions (the authentication tokens are unique to your repository)
98
+
99
+
For more details, see the [GitHub documentation on self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners).
100
+
101
+
102
+
### Connecting to gitlab
103
+
104
+
Since the GitHub runners can't reach gitlab we ha to use a VM running on CNV.
105
+
To make gitlab "accessible" to this runner, we need to set a deploy token at the target repo (go to repository > deploy keys and set the VM public key as the deploy key). This allows the VM perform actions on the target repo without needing to specify credentials.
106
+
107
+
### UnifAI team infra structure
108
+
109
+
In the case if the Unifai team the lab structure is a bit "special" the code resides in a public GitHub repo whereas all the deployment resources reside inside the company intra-net. to overcome this we have a self-hosted runner with access to both domains so the code is downloaded from github (for example in order to run a workflow) and then all actions are being run against the intra resources.
0 commit comments