Résumé

  • GitHub arrondit à la minute supérieure la durée de chaque job. Additionner d’abord toutes les secondes puis appliquer un seul arrondi sous-estime l’effet du découpage.
  • Six jobs complets de dix secondes représentent six minutes calculées, contre une pour un job de soixante secondes. Au tarif actuel du runner Linux standard à deux cœurs x64, cela consomme respectivement 0,036 et 0,006 dollar de valeur de calcul.

Une facture peut contenir six minutes là où les machines n’ont exécuté, au total, que soixante secondes. GitHub Actions y arrive sans ajouter une seconde au chronomètre : il suffit d’avoir six jobs de dix secondes, chacun avec son propre arrondi.

La grille officielle des runners arrondit les minutes et fractions de minute vers le haut, job par job. La frontière dessinée dans le workflow devient donc aussi une frontière de prix. Les petits travaux voyagent chacun dans un emballage d’une minute.

Le même temps, un autre nombre d’unités

Fixons un dépôt privé et un runner Linux standard à deux cœurs x64. Son prix actuel est de 0,006 dollar par minute. Supposons six jobs dont la durée complète mesurée est exactement dix secondes chacun : six fois une minute après arrondi, soit 0,036 dollar. Un seul job complet de soixante secondes consomme une minute, soit 0,006 dollar.

L’écart brut est de 0,03 dollar pour soixante secondes cumulées dans les deux cas. C’est une comparaison conditionnelle utilisant la règle publiée et des durées supposées. Regrouper un travail réel peut modifier sa préparation, son nettoyage, ses dépendances et sa durée finale. Six commandes de dix secondes ne prouvent pas que six jobs complets ont duré dix secondes.

Cette précision compte pour l’acheteur : il faut partir du temps du job tel qu’il est mesuré. Le relevé de durée d’exécution permet d’observer durée et minutes facturables. Le type de runner, le tarif applicable et le relevé financier complètent ensuite l’explication.

Certaines secondes valent une minute

Un job de 61 secondes monte à deux minutes. À soixante secondes, il reste à une. Une seconde gagnée sur cette frontière divise la quantité calculée par deux. Passer de onze à dix secondes laisse au contraire une minute dans les deux cas.

Le prix fait des marches. Le gain de vitesse et le gain financier ne suivent donc pas une proportion constante. Une petite amélioration près d’une frontière peut peser davantage sur le calcul qu’une grande amélioration d’un job déjà court. Classer les optimisations uniquement par secondes économisées peut classer leur intérêt commercial à l’envers.

Il existe aussi l’attente du développeur. Plusieurs jobs en parallèle peuvent fournir le résultat plus tôt, tout en consommant davantage de temps cumulé de runners. L’arrondi individuel ajoute encore une autre mesure. Temps jusqu’au résultat, somme des durées et minutes calculées sont trois colonnes, avec trois usages.

La valeur incluse est dépensée avant le supplément

La documentation actuelle de facturation exprime en argent l’enveloppe de calcul comprise dans le forfait. Les usages éligibles de runners, ainsi que le calcul et la mémoire des environnements isolés du cloud, peuvent consommer la même enveloppe. Aucun type éligible n’a priorité. La valeur se renouvelle au début du cycle ; une fois consommée, l’usage supplémentaire est facturé.

Les 0,036 dollar du scénario peuvent donc d’abord diminuer ce solde. Ils deviennent une dépense additionnelle après son épuisement. Avant cela, ils occupent une valeur qui aurait pu servir ailleurs. L’absence de supplément immédiat ne rend pas cette réserve indifférente au découpage.

Les runners standard hébergés par GitHub restent gratuits dans les dépôts publics, indépendamment de l’enveloppe. Les grands runners y sont payants. La comparaison chiffrée porte sur le dépôt privé et le runner fixés au départ. Mélanger ces catégories ferait perdre le sens des nombres avant même le premier arrondi.

Une frontière peut mériter son prix

La présentation d’Actions distingue workflows, jobs et étapes. Les étapes d’un job utilisent le même runner ; chaque job possède son environnement d’exécution. Sans dépendances, les jobs tournent en parallèle par défaut. Les fonctions actuelles permettent également certaines étapes simultanées au sein d’un job : davantage de jobs n’est pas la seule manière d’obtenir du parallélisme.

Tester plusieurs systèmes, séparer des environnements et obtenir une réponse tôt peuvent justifier des jobs distincts. Réunir des étapes permet aussi de partager des données dans un même environnement. Supprimer un test ou réunir des tâches qui exigent des niveaux de confiance et des permissions séparés changerait le produit acheté, pour gagner un arrondi.

Pour établir une économie réelle, il faut les durées effectives, les runners, l’équivalence des résultats, l’attente, les relances et l’usage du solde inclus. Le payeur est déjà connu : le propriétaire du dépôt, plutôt que la personne qui déclenche le workflow. Celui qui découpe le travail choisit ainsi des unités d’achat pour un autre budget. Six petits jobs peuvent être une excellente organisation. Les six minutes doivent expliquer ce qu’elles apportent.