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

Ouverte
#9,305 0 commentaires 1 réaction 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

@zahorniak y travaille déjà.

Depuis le 2/11/2026.

  • #9313 par @zahorniak — ouverte

Évaluation

Cette issue n'a pas encore été évaluée.

Description

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.

Langage dominant
Go
Étoiles
3.2k
Forks
832
Merge moyen
1 j 21 h
PR mergées (30 j)
77

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/devlake

Toutes les issues de apache/devlake

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.