Réutiliser les résultats des tâches
Mettez en cache les sorties JSON lorsqu’une tâche peut réutiliser un résultat pour les mêmes entrées.
Mettre une tâche en cache
Section intitulée « Mettre une tâche en cache »Ajoutez une politique de cache si une tâche peut réutiliser le même résultat JSON pour les mêmes entrées. Indiquez un stockage, une version et une clé qui identifie les entrées dont dépend le résultat.
La seconde exécution restaure le premier résultat : execution reste à 1 et cacheHit vaut true.
Choisir la clé
Section intitulée « Choisir la clé »L’empreinte combine le nom du workflow, la clé de la tâche, version et la valeur JSON renvoyée par key(ctx). Mettez-y tout ce qui peut changer la réponse.
Référence API : TaskCacheOptions et TaskCacheEntry.
repositoryFingerprint() calcule l’empreinte de HEAD, de l’index, des modifications non commitées et des fichiers non suivis non ignorés, hors .outpost/ : une modification locale change donc la clé. Une clé qui lève une erreur ou n’est pas du JSON sans perte fait échouer la tâche.
Comprendre un résultat trouvé en cache
Section intitulée « Comprendre un résultat trouvé en cache »| Lors d’un hit | Résultat |
|---|---|
| Valeur de la tâche | Restaurée et transmise aux tâches dépendantes |
TaskRecord.cacheHit | true |
| Tentatives, usage, budget de tentatives | Rien d’enregistré ni de consommé |
| Fichiers, commits, branches, état de la sandbox, artefacts, appels | Non rejoués |
Mettez en cache les tâches dont la valeur est le produit : relectures, classifications, résumés, analyses.
Choisir une tâche qui accepte un cache
Section intitulée « Choisir une tâche qui accepte un cache »Le résultat doit être du JSON sans perte ou undefined ; sinon, la tâche échoue après son exécution, sans nouvelle tentative.
Référence API : TaskCacheOptions, TaskOptions et QueuedTaskOptions.
Faire expirer ou renouveler les entrées
Section intitulée « Faire expirer ou renouveler les entrées »Référence API : TaskCacheOptions.
Suivre les événements du cache
Section intitulée « Suivre les événements du cache »Affichez les événements du cache depuis l’observateur du workflow pour suivre les résultats trouvés, les absences et les erreurs de stockage. Un échec du cache n’empêche pas la tâche de s’exécuter ou de terminer.
Référence API : TaskCacheOutcome.
Le cache ne décide jamais du résultat : après une lecture failed, la tâche s’exécute ; après une écriture failed, elle se termine normalement.
Protéger et purger les entrées
Section intitulée « Protéger et purger les entrées »Les entrées restent sous task-cache/ dans le transport jusqu’à ce que vous les supprimiez. Ajoutez le périmètre task-cache à une politique de rétention pour purger celles plus anciennes que minAgeMs.
- Les exécutions concurrentes de même empreinte s’exécutent toutes ; la première entrée écrite est conservée.
- Une tâche déjà terminée dans un checkpoint en est restaurée sans lire le cache.
- Les entrées ne sont pas invalidées quand votre code ou votre agent change : changez
version. createTaskCacheStoren’enregistre pas les entrées de plus de 16 Mio (maxBytes) ; l’écriture signalefailed.- Ne mettez pas en cache une
defineArtifactTasklue par une tâche suivante : un hit dans une nouvelle exécution restaure une référence à l’exécution précédente, etreadArtifact()échoue avec « Artifact dependency producer mismatch ».
API : TaskCacheOptions · createTaskCacheStore · repositoryFingerprint · TaskCacheEntry · WorkflowEvent.