Tâches récurrentes

Les Recurring Tasks vous permettent de planifier un workflow pour qu’il s’exécute automatiquement selon un planning répété. Au lieu de déclencher manuellement un run chaque matin pour un contrôle de qualité de code nocturne ou chaque lundi pour une mise à jour de dépendances, vous définissez une tâche récurrente une fois et CodeCourier la déclenche automatiquement à la fréquence configurée. Chaque déclenchement crée un workflow run standard avec la source scheduled, qui apparaît dans l’historique des runs de votre projet comme n’importe quel autre run.

Modèle de données des tâches récurrentes

Un enregistrement de tâche récurrente contient toutes les informations nécessaires pour planifier et configurer chaque run qu’il déclenche :

{
  title: string,                        // Human-readable name for the task
  description: string,                  // Optional longer description
  prompt: string,                       // The prompt sent to the workflow each firing
  frequency: "daily"                    // How often the task fires
            | "every_other_day"
            | "weekly"
            | "biweekly"
            | "monthly",
  targetWorkflowId: string,             // Workflow blueprint to execute
  projectId: string,                    // Owning project
  createdBy: string,                    // User who created the task
  isActive: boolean,                    // Whether the task is currently enabled
  timezone: string,                     // IANA timezone (e.g., "America/New_York")
  scheduledHour: number,               // Hour to fire (0-23, in the given timezone)
  scheduledMinute: number,             // Minute to fire (0-59)
  nextRunAt: number,                    // Unix timestamp of next scheduled execution
}

Options de fréquence

CodeCourier prend en charge cinq fréquences de récurrence :

• daily - Se déclenche une fois chaque jour calendaire à l’heure et la minute configurées. À utiliser pour les contrôles de qualité nocturnes, les runs de test quotidiens ou le scan continu de dépendances.
• every_other_day - Se déclenche tous les deux jours. Une cadence plus légère que quotidienne - utile pour les tâches importantes mais qui n’ont pas besoin de s’exécuter chaque jour.
• weekly - Se déclenche une fois par semaine le même jour et à la même heure que la création originale. À utiliser pour les mises à jour de dépendances hebdomadaires, les passes de refactoring hebdomadaires ou les rapports de couverture hebdomadaires.
• biweekly - Se déclenche toutes les deux semaines. Adapté aux tâches avec une cadence de sprint, comme les audits de sécurité ou les mises à jour de documentation alignées sur les cycles de développement.
• monthly - Se déclenche une fois par mois calendaire. Idéal pour l’automatisation peu fréquente et à fort impact, comme les mises à niveau majeures de dépendances ou les contrôles de conformité.

Créer une tâche récurrente

Les tâches récurrentes sont créées depuis la section des tâches récurrentes du projet, accessible à /p/[id]/recurring. Chaque tâche peut aussi être consultée et éditée individuellement à /p/[id]/recurring/[taskId].

Comment fonctionnent les runs planifiés

Lorsqu’une tâche récurrente se déclenche, le scheduler de CodeCourier crée un workflow run avec des métadonnées de planification supplémentaires :

{
  source: "scheduled",                  // Identifies the run as scheduler-originated
  workflowId: task.targetWorkflowId,
  prompt: task.prompt,
  scheduledFor: timestamp,              // When the task was scheduled to fire
  timezone: task.timezone,              // Timezone from the recurring task
  recurrencePattern: task.frequency,    // e.g., "daily", "weekly"
  recurringTaskId: task._id,            // Reference back to the recurring task
  // ... standard run configuration
}

Ces champs apparaissent dans la vue détaillée du run, reliant chaque exécution à la tâche récurrente qui l’a déclenchée. Le timestamp scheduledFor reflète l’heure de déclenchement prévue, qui peut différer légèrement de l’heure startedAt réelle en raison de la latence de la file du scheduler.

Intégration à la liste des runs

Les runs planifiés apparaissent dans la liste des Runs du projet avec :

• Un badge de source montrant scheduled (distinct de workflow, sprint ou sandbox).
• Le titre de la tâche récurrente dans le nom du run, rendant les runs planifiés faciles à identifier d’un coup d’œil.
• Un suivi de statut standard - les runs planifiés passent par le même cycle de vie pending → running → completed/failed que tous les autres runs.

Gérer les tâches récurrentes

Activer et désactiver

Chaque tâche récurrente a un toggle isActive. Désactiver une tâche suspend tous les déclenchements futurs sans supprimer la tâche. Le champ nextRunAt est effacé lorsqu’une tâche est désactivée. Réactiver la tâche recalcule nextRunAt à partir de l’heure actuelle en fonction de la fréquence et du planning.

Éditer une tâche récurrente

Tous les champs d’une tâche récurrente peuvent être édités depuis sa page de détail. Les changements prennent effet pour le prochain déclenchement - tout run actuellement en cours utilise la configuration de son déclenchement, pas les valeurs mises à jour. Éditer le planning (fréquence, timezone, heure ou minute) amène CodeCourier à recalculer nextRunAt immédiatement.

Vous pouvez changer :

• Le titre et la description.
• Le prompt - le prompt mis à jour est utilisé à partir du prochain déclenchement.
• Le workflow cible - remplacer par un pipeline différent pour les runs futurs.
• La fréquence, le timezone, l’heure et la minute.

Supprimer une tâche récurrente

Supprimer une tâche récurrente la retire définitivement et arrête tous les déclenchements futurs. Les runs qui ont été créés par la tâche restent dans l’historique des runs et ne sont pas affectés. Pour préserver la configuration de la tâche en vue d’une utilisation future potentielle, envisagez de la désactiver plutôt que de la supprimer.

Gestion des timezones

Les tâches récurrentes stockent un timezone IANA explicite afin que les plannings se comportent intuitivement quel que soit l’endroit où les membres d’équipe se trouvent ou le timezone serveur sur lequel CodeCourier s’exécute. Le timezone est appliqué à la fois au calcul initial de nextRunAt et à chaque calcul de récurrence suivant après le déclenchement d’une tâche.

Les transitions d’heure d’été sont gérées automatiquement. Une tâche configurée pour se déclencher à 09:00 America/New_York se déclenche à 9h00 heure de l’Est toute l’année, s’ajustant aux transitions EST/EDT sans intervention manuelle.

Consulter l’historique des runs d’une tâche

La page de détail de la tâche récurrente (/p/[id]/recurring/[taskId]) montre l’historique des runs de cette tâche spécifique - tous les runs avec un recurringTaskId correspondant. Cela vous donne une vue ciblée de la manière dont le workflow planifié a performé au fil du temps : combien de runs ont réussi, combien ont échoué, et tout pattern dans la durée d’exécution ou les scores de qualité.

Depuis chaque entrée de run dans l’historique de la tâche, vous pouvez naviguer vers la page de détail complète du run pour inspecter la sortie de sandbox, les verdicts d’étape, les URLs de PR et les scores de qualité.

Cas d’usage

• Contrôles de qualité de code nocturnes - Une tâche quotidienne exécute un workflow de qualité chaque nuit à 2h00, détectant les erreurs de type, les violations de lint et les échecs de test introduits pendant la journée.
• Mises à jour de dépendances hebdomadaires - Une tâche hebdomadaire se déclenche chaque lundi et exécute un workflow qui audite les dépendances npm, met à jour les paquets obsolètes et ouvre une PR avec les changements.
• Runs de test quotidiens - Une tâche quotidienne exécute un workflow qui compile le projet et exécute la suite de tests complète, rapportant les échecs via le système de notification de run.
• Audits de sécurité bihebdomadaires - Une tâche bihebdomadaire déclenche un workflow deep-dive qui scanne les vulnérabilités courantes dans les dépendances, la configuration et les patterns de code.
• Synchronisation mensuelle de documentation - Une tâche mensuelle exécute un workflow designer qui lit la codebase et met à jour la documentation de l’API pour refléter les changements du mois écoulé.
• Baseline de performance continue - Une tâche tous les deux jours exécute un workflow qui lance des benchmarks de performance et commite les résultats, construisant une baseline à long terme pour la détection de régressions.