GitLab 中 100+ 个项目的混合代码搜索

GitLab混合仓库搜索：API与深度配置扫描

随着GitLab中项目数量的增长，在代码、YAML、JSON和.env文件中搜索特定字符串变得具有挑战性。标准UI和API搜索对代码快速有效，但会遗漏配置文件。解决方案是使用python-gitlab的混合Python脚本：API搜索用于代码，递归遍历用于配置。在100多个项目中的搜索时间缩短至几分钟。

替代方案分析

在开发之前，我们评估了现有方法。没有一种方法能在不妥协的情况下完全覆盖任务。

| 方法 | 优点 | 缺点 |

|--------|-------|--------|

| GitLab UI | 启动快速 | 对于100多个项目需手动操作，对配置支持弱 |

| 本地grep/ripgrep | 完全控制 | 克隆所有仓库需数小时 |

| GitLab API搜索 | 可远程使用 | 遗漏YAML/JSON/env文件 |

| Sourcegraph | 强大的索引功能 | 需要部署基础设施 |

混合爬虫被证明是最优方案：利用API优势，并添加遍历以弥补弱点，无需外部依赖。

按文件类型搜索的差异

GitLab可靠地索引代码和文档，但配置文件通常不在搜索范围内。

• 代码（.py、.js、.go、.ts）：API搜索——索引完全覆盖。
• 文档（.md、.txt）：API搜索——速度和准确性足够。
• 配置（.yml、.yaml、.json、.env）：深度搜索——递归树 + 内容获取。
• 二进制文件：排除以节省资源。

逻辑：将任务委托给工具处理强类型文件，手动处理弱类型文件。

脚本架构

脚本遵循流水线：

• 获取组及子组中的项目列表。
• 过滤掉已归档和不活跃的项目。
• 并行处理：API搜索 + 深度搜索。
• 聚合结果。
• 生成报告。

GitLab组 → projects.list() → 过滤活跃项目
↓
并行：API搜索（代码）+ 深度搜索（配置）
↓
合并 → 详细报告 + 摘要 + 错误

搜索仅限于主分支以获取当前配置。扩展到所有分支是可能的，但会增加时间。

关键组件实现

获取项目

group = gl.groups.get(GROUP_ID)
all_projects = group.projects.list(include_subgroups=True, all=True)

按状态archived=false和last_activity过滤。

代码的API搜索

def api_search(gl, project_id, search_terms):
    results = {term: [] for term in search_terms}
    for term in search_terms:
        blobs = gl.search('blobs', term, project_id=project_id)
        for blob in blobs:
            file_path = blob.get('path', '')
            file_ext = os.path.splitext(file_path)[1].lower()
            if file_ext in CODE_EXTENSIONS or file_ext == '':
                results[term].append({
                    'path': file_path,
                    'url': blob.get('web_url', '#'),
                    'found_by': 'API'
                })
    return results

按代码扩展名处理blobs。

配置的深度搜索

def deep_search_configs(gl, project_id, search_terms):
    results = {term: [] for term in search_terms}
    project = gl.projects.get(project_id)
    files = project.repository_tree(recursive=True, ref='master')
    for file in files:
        if file['type'] != 'blob':
            continue
        ext = os.path.splitext(file['name'])[1].lower()
        if ext not in CONFIG_EXTENSIONS:
            continue
        content = project.files.get(file_path=file['path'], ref='master').decode()
        content_lower = content.lower()
        for term in search_terms:
            if term.lower() in content_lower:
                results[term].append({
                    'path': file['path'],
                    'found_by': 'Deep'
                })
    return results

递归树，获取内容，字符串搜索。

处理的并行化

使用3个工作线程的ThreadPoolExecutor加速100多个项目的处理：

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {executor.submit(process_one_project, gl, p): p for p in active_projects}
    for future in as_completed(futures):
        result = future.result()
        results_list.append(result)

在IO密集型任务中，将时间从数小时减少到几分钟，无GIL问题。

报告格式

详细报告：项目、路径、术语、行号、搜索方法。

示例：

项目：service-a
路径：backend/service-a
'SERVICE_EXAMPLE'：2次出现
  - deploy/prod/values.yml:42 [深度]
    第42行：SERVICE_EXAMPLE: "{{ .Values.secrets.apiKey }}"

摘要：项目数量、出现次数、API与深度搜索对比。

速度因素

• 排除不必要的文件/项目。
• API用于80%的情况（代码）。
• 并行处理。
• 专注于主分支。

局限性

• 仅限主分支。
• 无正则表达式支持。
• 无去重功能。
• 控制台输出。

关键要点

• 混合方法最小化了GitLab搜索在配置方面的弱点。
• 3线程并行对于API速率限制是最优的。
• 项目过滤将负载减少30–50%。
• 深度搜索对YAML/JSON/env文件准确。
• 适用于无需基础设施的一次性检查。

— Editorial Team