Periodically find and queue missing compiler compatibility checks

Ouverte
  • Quelque chose ne va pas ?
#804 9 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
22/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Domaine
backend

Piste de recherche

This is design work, so start by reading the linked #800, #801 and #803 to see what those changes already cover. The issue names no files: look for where the publish job queues compiler matrix jobs and where the existing job queue is written. Done means a design decision on the stateless sweep, the queue-insertion rule, and whether scheduling moves outside the publish job's success boundary, agreed with maintainers before any code is written.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

A package can finish publishing, but some of its compiler compatibility checks may never get queued. For example, the server might time out or restart while finding the checks to run. The package is available to users, but its list of supported compilers can remain incomplete indefinitely.

This happened with [email protected] in #800.

#801 makes follow-up scheduling faster and inserts jobs one at a time. That saves jobs already queued before an interruption, but it cannot recover checks it never reached. #803 improves solver performance, but faster solving alone does not repair missing checks.

So the basic problem remains: how do we detect and fix the unavoidable case where a compiler matrix job might not get queued for a published package? And how do we do it without introducing new state?

I think we can accomplish this with a regular, stateless sweep over the registry. The basic idea is to run a small repair command on a regular interval, for example through a systemd timer. Each run starts fresh and asks: Which published package versions still need compiler checks?

For each published package version and each supported compiler:

  1. If the package metadata already lists that exact compiler, skip it.
  2. If a matrix job already exists for that package version and compiler, skip it.
  3. Otherwise, try to find dependency versions that allow a build with that compiler.
  4. If a build plan is found, immediately insert a matrix job into the existing queue.
  5. If no plan is found, leave it alone and try again on a later sweep. A dependency may gain compiler support in the meantime.

The normal server executor still runs the compilation jobs and updates package metadata after successful compilation. The repair command does not compile packages or write compatibility metadata itself.

This survives interruptions itself. As a concrete example, suppose a sweep finds 100 missing checks and stops after queuing 40. The next sweep starts over, skips those 40 existing jobs, and finds the remaining checks. We do not need to remember where the previous sweep stopped.

This also finds old gaps, not just gaps caused by the latest publication or compiler release. It should examine all currently published versions, not only the newest version of each package.

The goal is eventual repair: as sweeps and compilation jobs complete, missing compatibility results are filled in wherever a build succeeds. A missing compiler entry is not proof that the package cannot compile with it, and a solved build plan is not proof of compatibility until compilation succeeds.

Side note: separating queueing from publication success

If publication finishes successfully, a later timeout while queuing compatibility checks currently makes the publish job fail. This is kind of misleading though; the compiler matrix is an eventually-correct best-effort thing, not a requirement for publishing. Compatibility scheduling should be outside the publication job's success/failure boundary and timeout. The periodic sweep can take responsibility for discovering that follow-up work.

The same principle applies to matrix jobs: once compilation succeeds and the compatibility metadata is successfully written/pushed, a later failure to schedule dependant checks should not turn that successful check into a failed job.

Langage dominant
PureScript
Étoiles
95
Forks
79
Merge moyen
16 h 13 min
PR mergées (30 j)
14

Préparer son environnement

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 purescript/registry-dev

Toutes les issues de purescript/registry-dev

Issues similaires

Plus d'issues Backend & API Design

Recevez les nouvelles issues par e-mail

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