Mettre en cache, partager et déboguer des flux de travail

  • 8 minutes

Dans cette unité, vous allez apprendre à optimiser les performances, à transmettre des données entre les travaux et à résoudre les problèmes de flux de travail à l’aide de journaux et de jetons.

Pour implémenter ce processus, vous allez apprendre à :

  • Mettre en cache les dépendances pour accélérer les flux de travail.
  • Passer des données d’artefact d’un travail à un autre.
  • Activez la journalisation du débogage pour les flux de travail.
  • Accédez aux journaux de flux de travail à partir de l’interface utilisateur GitHub et de l’API REST.
  • Utilisez des jetons d’installation pour l’authentification GitHub App.

Mettre en cache les dépendances avec l’action de cache

Lorsque vous générez un flux de travail, vous devez souvent réutiliser les mêmes sorties ou télécharger les dépendances d’une exécution vers une autre. Au lieu de télécharger ces dépendances à chaque fois, vous pouvez les mettre en cache pour que votre workflow s’exécute plus rapidement et plus efficacement. La mise en cache des dépendances réduit le temps nécessaire pour exécuter certaines étapes dans un flux de travail, car les travaux sur les exécuteurs hébergés par GitHub commencent dans un environnement virtuel propre à chaque fois.

Pour mettre en cache les dépendances d’une tâche, utilisez l’action cache de GitHub. Cette action permet de récupérer un cache identifié par une clé unique que vous fournissez. Lorsque l’action trouve le cache, elle récupère les fichiers mis en cache dans le chemin que vous avez configuré. Pour utiliser l’action cache , vous devez définir quelques paramètres spécifiques :

Paramètre Descriptif Obligatoire
Key Fait référence à l’ID de clé créé lors de l’enregistrement et de la recherche d’un cache. Oui
Path Fait référence au chemin de fichier de l’exécuteur à mettre en cache ou à rechercher. Oui
Restore-keys Se compose d’autres clés existantes pour mettre en cache si la clé de cache souhaitée n’est pas trouvée. Non 
steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

Dans l’exemple précédent, path est défini sur ~/.npm et la key comprend le système d’exploitation de l’exécuteur ainsi que le hachage SHA-256 du fichier package-lock.json. Il est utile de préfixer la clé avec un ID (npm-cache dans cet exemple) lorsque vous utilisez les restore-keys de secours et que vous avez plusieurs caches.

Passer des données d’artefact d’une tâche à une autre

Comme pour l’idée de mettre en cache les dépendances au sein de votre flux de travail, vous pouvez transmettre des données entre des travaux à l’intérieur du même flux de travail. Vous pouvez transmettre les données en utilisant les actions upload-artifact et download-artifact. Les tâches qui dépendent des artefacts d’une tâche précédente doivent attendre que la tâche précédente se termine correctement avant de pouvoir s’exécuter. Cette approche est utile si vous avez une série de tâches qui doivent s’exécuter de façon séquentielle en fonction des artefacts qui ont été chargés à partir d’une tâche antérieure. Par exemple, job_2 exige job_1 en utilisant la syntaxe needs: job_1.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

Cet exemple comporte deux postes. job_1 écrit du texte dans le file.txt fichier. Ensuite, elle utilise l’action actions/upload-artifact@v2 pour charger cet artefact et stocker les données afin de les utiliser ultérieurement dans le workflow. job_2 nécessite que job_1 s’exécute à l’aide de la syntaxe needs: job_1. Ensuite, elle utilise l’action actions/download-artifact@v2 pour télécharger cet artefact puis imprimer le contenu de file.txt.

Activer la journalisation du débogage pour les étapes dans un workflow

Dans certains cas, les journaux de flux de travail par défaut ne fournissent pas suffisamment de détails pour diagnostiquer la raison pour laquelle une exécution, un travail ou une étape spécifique échoue. Dans ces scénarios, vous pouvez activer une journalisation de débogage plus détaillée pour deux options : exécutions et étapes. Activez cette journalisation de diagnostic en définissant deux secrets de référentiel qui nécessitent que l’accès admin au référentiel soit défini sur true.

  • Pour activer la journalisation des diagnostics d’exécution, définissez le secret ACTIONS_RUNNER_DEBUG sur la valeur true dans le référentiel qui contient le workflow.
  • Pour activer la journalisation des diagnostics d’étapes, définissez le secret ACTIONS_STEP_DEBUG sur la valeur true dans le référentiel qui contient le workflow.

Accéder aux journaux de flux de travail dans GitHub

Lorsque vous pensez à une automatisation réussie, vous souhaitez passer le moins de temps à examiner ce qui est automatisé afin de vous concentrer sur ce qui est pertinent. Mais parfois, les choses ne vont pas comme prévu, et vous devez examiner ce qui s’est passé. Ce processus de débogage peut être frustrant.

GitHub dispose d’une disposition claire et structurée pour vous aider à passer rapidement d’un travail à l’autre tout en conservant le contexte de l’étape de débogage actuelle.

Pour afficher les journaux d’activité d’un flux de travail exécutés dans GitHub :

  1. Dans votre référentiel, accédez à l’onglet Actions .
  2. Dans le volet gauche, sélectionnez le flux de travail.
  3. Dans la liste des exécutions de workflows, sélectionnez l’exécution.
  4. Sous Travaux, sélectionnez le travail.
  5. Consultez la sortie du journal.

Si vous avez plusieurs exécutions à l’intérieur d’un flux de travail, vous pouvez sélectionner le filtre d’état après avoir sélectionné votre flux de travail et le définir sur Échec pour afficher uniquement les exécutions ayant échoué dans ce flux de travail.

Accéder aux journaux de workflows à partir de l’API REST

Outre l’affichage des journaux via GitHub, vous pouvez utiliser l’API REST GitHub pour afficher les journaux des exécutions de flux de travail, réexécuter des flux de travail ou même annuler les exécutions de flux de travail. Pour afficher le journal d'exécution d'un flux de travail à l'aide de l'API, envoyez une GET demande au point de terminaison des journaux. N’oubliez pas que quiconque disposant d’un accès en lecture au référentiel peut utiliser ce point de terminaison. Si le référentiel est privé, vous devez utiliser un jeton d’accès avec l’étendue repo.

Par exemple, une GET demande d’affichage d’un journal d’exécution de flux de travail spécifique suit ce chemin d’accès :

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Identifier quand utiliser un jeton d’installation à partir d’une application GitHub

Lorsque votre application GitHub est installée sur un compte, vous pouvez l’authentifier en tant qu’installation d’application à l’aide des installation access token demandes d’API REST et GraphQL. Cette étape permet à l’application d’accéder aux ressources appartenant à l’installation, en supposant que l’application a reçu l’accès et les autorisations nécessaires au référentiel. Les demandes d’API REST ou GraphQL effectuées par une installation d’application sont attribuées à l’application.

Dans l’exemple suivant, vous remplacez INSTALLATION_ACCESS_TOKEN par le jeton d’accès d’installation :

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

Vous pouvez également utiliser un jeton d’accès d’installation afin de vous authentifier pour l’accès à Git basé sur HTTP. Votre application doit disposer de l’autorisation Contents du référentiel. Vous pouvez ensuite utiliser le jeton d’accès d’installation en tant que mot de passe HTTP.

Vous remplacez TOKEN dans l’exemple par le jeton d’accès de l’installation.

git clone https://x-access-token:TOKEN@github.com/owner/repo.git