Aller au contenu principal

Limite de débit de l’API GitHub : s’appuyer sur le toolcache, fournir un jeton

Certaines actions appellent api.github.com pendant leur exécution. setup-go, setup-node et setup-python lui demandent la liste des versions disponibles chaque fois que la version que vous avez indiquée n’est pas déjà présente sur le runner. setup-java fait de même, mais seulement pour les distributions dont la liste de versions est hébergée sur GitHub, comme le Microsoft Build of OpenJDK ; Temurin provient d’Adoptium. setup-dotnet installe .NET depuis le flux de Microsoft et n’est pas concerné. D’autres actions lisent des releases ou des fichiers dans des dépôts GitHub.

GitHub autorise 60 requêtes non authentifiées par heure et par adresse IP. Les runners hébergés partagent leurs adresses IP sortantes, si bien que d’autres jobs consomment le même quota que les vôtres. Une fois celui-ci épuisé, l’étape échoue :

Error: API rate limit exceeded for 80.158.x.x. (But here's the good news:
Authenticated requests get a higher rate limit. Check out the documentation
for more details.)

Deux modifications évitent ce problème. Appliquez la première dans chaque workflow, et la seconde à toute action qui doit encore contacter GitHub.

1. Indiquer une version major.minor pour que le toolcache réponde

Les runners hébergés embarquent des versions précises de Node.js, Go, Python, Java et .NET dans leur cache d’outils, le toolcache : la liste figure dans ce que contient l’image du runner. Une action setup-* qui y trouve la version l’utilise directement et ne fait aucun appel à GitHub.

Elle ne la trouve que si vous demandez une plage que le toolcache peut satisfaire. Une version de correctif complète (1.27.2) le rate dès que l’image du runner passe à 1.27.3 ; l’action demande alors sa liste de versions à api.github.com et télécharge depuis GitHub :

# Misses the toolcache when the image has a newer patch, then calls api.github.com
- uses: actions/setup-go@v5
  with:
    go-version: '1.27.2'

# Resolves from the toolcache: no GitHub call
- uses: actions/setup-go@v5
  with:
    go-version: '1.27'

Il en va de même pour node-version: '24', python-version: '3.13' et les autres entrées des actions setup-*. Ne définissez pas check-latest (sa valeur par défaut est false) : avec check-latest: true, l’action demande à GitHub la version la plus récente à chaque exécution, même quand le toolcache en contient une.

Un fichier go.mod, .nvmrc ou .python-version lu via go-version-file et les entrées similaires indique généralement une version exacte et rate donc le toolcache de la même manière. Indiquez plutôt la version major.minor dans le workflow.

2. Fournir un jeton GitHub.com aux actions qui appellent GitHub

Les requêtes authentifiées ont droit à 5 000 par heure, décomptées sur votre jeton et non sur l’adresse IP partagée. Créez un jeton sur GitHub.com et transmettez-le à l’action :

  1. Sur GitHub.com, créez un fine-grained personal access token (jeton d’accès personnel à granularité fine) avec l’accès Public repositories (read-only) et aucune autre permission. Il n’a besoin que de lire des données publiques.
  2. Dans fremforge, enregistrez-le comme secret de dépôt ou d’organisation, par exemple GH_DOTCOM_TOKEN.
  3. Transmettez-le à l’entrée token de l’action :
- uses: actions/setup-node@v4
  with:
    node-version: '24'
    token: ${{ secrets.GH_DOTCOM_TOKEN }}

setup-go et setup-python acceptent la même entrée token. setup-java aussi, mais elle n’y sert que pour les distributions mentionnées plus haut. setup-dotnet n’a pas d’entrée token et n’en a pas besoin. Les autres actions qui appellent GitHub acceptent généralement token ou github-token ; consultez la documentation de l’action.

secrets.GITHUB_TOKEN ne fonctionne pas ici

Sur fremforge, secrets.GITHUB_TOKEN (et github.token) est le jeton Forgejo du job. Il s’authentifie auprès de fremforge, pas auprès de github.com : le transmettre à une action qui appelle api.github.com ne change donc rien, la requête reste comptée comme non authentifiée. Utilisez un jeton créé sur GitHub.com, comme décrit ci-dessus.

Ce que fremforge fait, et ne fait pas

  • L’image du runner embarque dans son toolcache les versions de Node.js, Go, Python, Java et .NET listées sur la page de l’image du runner. Un workflow qui demande l’une d’elles comme à l’étape 1 n’a jamais besoin de GitHub pour elle. Une version absente de cette liste est téléchargée, et pour setup-go, setup-node et setup-python cela commence par un appel à api.github.com.
  • Les actions elles-mêmes (uses: actions/setup-go@v5 et similaires) sont récupérées depuis les miroirs de fremforge, pas depuis GitHub : la résolution d’une action n’est donc jamais décomptée de la limite de GitHub. Voir Compatibilité Marketplace.
  • fremforge n’ajoute pas d’adresses IP sortantes pour répartir la limite par IP de GitHub. Les deux modifications ci-dessus rendent cela inutile, et elles fonctionnent quelle que soit l’adresse IP.
Checkouts rapides