[Refactor][CircleCI] Make extractJobs and extractWorkflows incremental with NewStatefulApiExtractor

オープン
#9,305 コメント 0 件 リアクション 1 件 担当者 1 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@zahorniak がすでに取り組んでいます。

2026年11月2日 から。

  • #9313 @zahorniak による — オープン

評価

この issue はまだ評価されていません。

説明

What and why to refactor

The CircleCI extractors extractJobs and extractWorkflows use the old api.NewApiExtractor. This extractor reads all rows of the raw table on every run, also on incremental runs. The GitHub, GitLab, Jira and YouTrack plugins already use api.NewStatefulApiExtractor, which reads only the raw rows added since the last successful run.

So the time for each run grows with the size of the raw table, not with the new CI activity. In our instance:

_raw_circleci_api_jobs about 9.3M rows (10.3 GB)
New raw rows per night about 166k (almost all from the problem in #9304)
extractJobs speed about 490 rows/s with default MySQL settings
extractJobs time per run about 4.5 hours for one project, every night

The job extraction writes one row per commit. It uses almost no CPU on the DevLake or MySQL side; the disk sync on each commit sets the speed.

Environment: DevLake v1.0.3-beta14 (the code is the same on main at 351d86738), MySQL 8.4, CircleCI Cloud, nightly incremental blueprint.

Describe the solution you'd like

Change ExtractJobs (backend/plugins/circleci/tasks/job_extractor.go) and ExtractWorkflows (backend/plugins/circleci/tasks/workflow_extractor.go) to api.NewStatefulApiExtractor, the same way as other plugins (for example backend/plugins/github/tasks/pr_extractor.go).

  • On an incremental run, the extractor reads only raw rows with created_at >= since.
  • On a full sync, or when the configuration changes, it reads all raw rows, as it does now.
  • Duplicate raw rows for the same job are safe: the tool-layer key is (connection_id, workflow_id, id) for jobs and (connection_id, id) for workflows, so a newer row replaces the older one.
  • Add or update the e2e tests for the two extractors.

With #9304 fixed and this change, extractJobs in our instance would read about 20k rows per night, not 9.3M.

I can start work on a PR for this if the DevLake maintainers approve this approach.

Related issues

  • #9304: the "unfinished details" collectors collect the same jobs again without a limit.
  • #8907, #8956: earlier fixes in the same collectors.

Additional context

A one-time cleanup of the duplicate raw rows is not part of this change. After both fixes, a full sync removes the old raw rows.

主要言語
Go
スター
3.2k
フォーク
832
平均マージ
1日 21時間
マージ済み PR(30日)
77

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/devlake のほかの issue

apache/devlake の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。