Utilisation de GitHub CI pour les projets Elixir

En octobre, Github lancé des actions qui vous permettent d'exécuter CI sans quitter la caisse dans laquelle ce code est stocké. C'est vraiment très pratique. Dès que quelqu'un envoie une demande de tirage , ou simplement télécharge de nouvelles modifications sur le serveur, ou quelque chose de spécial (une liste des événements auxquels les actions peuvent être attachées peut être trouvée dans la documentation officielle ), l'assemblage démarre. Les tâches récurrentes planifiées ( basées sur cron ) sont également prises en charge.

Vous pouvez créer des pipelines d'action appelés workflows . Et tout cela est beau et ressemble à un brillant avenir - à l'exception de la documentation.

Il m'a fallu plus d'une heure pour comprendre comment créer un conteneur avec des services tiers pour tester l'application. Voici ce que j'ai réussi à découvrir. Veuillez noter que la documentation officielle est franchement maladroite, incomplète et souvent simplement erronée.

L' action CI standard utilise des fichiers de configuration avec une syntaxe très similaire à celle utilisée par CircleCI . Ce n'est que le bon vieux YAML , qui vous permet de configurer le système d'exploitation cible, l'environnement, les commandes à exécuter, etc. Les actions elles-mêmes reçoivent des noms uniques , ce qui vous permet de vous référer à d'autres actions et de dépendre d'elles.

De plus, la configuration vous permet de spécifier des services . Les services doivent être exécutés quelque part dans le cloud et GH mappera les ports de conteneur aux ports exposés par ces services, selon la configuration. Cette partie est mal couverte dans la documentation officielle, et même ce qui est décrit contient des erreurs.

Voici un exemple de configuration de travail pour un projet Elixir qui nécessite des services RabbitMQ et Redis pour tester.

 name: Tests for My Project on: [push, pull_request] jobs: build: runs-on: ubuntu-latest container: image: elixir:1.9.1-slim services: rabbitmq: image: rabbitmq ports: - 5672:5672 env: RABBITMQ_USER: guest RABBITMQ_PASSWORD: guest RABBITMQ_VHOST: "/" redis: image: redis ports: - 6379:6379 steps: - uses: actions/checkout@v1 - name: Install Dependencies run: | MIX_ENV=ci mix local.rebar --force MIX_ENV=ci mix local.hex --force MIX_ENV=ci mix deps.get - name: Run All Tests run: | MIX_ENV=ci mix test env: RABBITMQ_HOST: rabbitmq RABBITMQ_PORT: ${{ job.services.rabbitmq.ports[5672] }} REDIS_HOST: redis REDIS_PORT: ${{ job.services.redis.ports[6379] }} 

Comme vous pouvez le voir, les tests s'exécuteront sur Ubuntu en utilisant Elixir v1.9.1. Les services sont décrits sous les services clés et commence ici une pure histoire de détective. Le port physique auquel le port de service sera lié est sélectionné au hasard par le moteur de conteneur au moment de l'exécution et stocké dans une variable de shell interne nommée job.services.rabbitmq.ports[5672] . rabbitmq est le nom du service, comme indiqué dans ce fichier dans la section services , et 5672 est le port source. La variable interne a la syntaxe $ {{foo}} et est passée à la variable d'environnement RABBITMQ_PORT (le dernier bloc de paramétrage, sous la clé env ). Dans RABBITMQ_HOST - vous devez mettre le nom du service, tout comme sous la clé des services . Maintenant, l'application peut lire les variables d'environnement comme d'habitude et les ports défileront correctement.

C'est ainsi que nous lirons ces variables d'environnement à partir de l'environnement (c'est une configuration pour Elixir , pour d'autres langages il y aura quelque chose de très similaire).

 import Config config :my_app, rabbitmq: [ host: System.get_env("RABBITMQ_HOST"), password: "guest", port: String.to_integer(System.get_env("RABBITMQ_PORT", "5672")), username: "guest", virtual_host: "/", x_message_ttl: "4000" ] 

Dans le fichier projet, je crée un environnement spécial :ci , pour distinguer la configuration des tests qui s'exécutent dans l'environnement local et des mêmes tests qui s'exécutent quelque part dans le cloud.

De plus, dans le pipeline CI , dialyzer le dialyzer sur mes sources. Puisqu'elle s'exécute dans le conteneur, la tâche prend un certain temps, car vous devez à chaque fois reconstruire les plts partir de zéro. C'est pourquoi je le fais une fois par jour en utilisant l'option de configuration de schedule .

 name: Dialyzer for My Project on: schedule: - cron: "0 1 * * *" jobs: build: runs-on: ubuntu-latest container: image: elixir:1.9.1-slim steps: - uses: actions/checkout@v1 - name: Install Dependencies run: | MIX_ENV=ci mix local.rebar --force MIX_ENV=ci mix local.hex --force MIX_ENV=ci mix deps.get - name: Run All Tests run: | MIX_ENV=ci mix code_quality 

ici code_quality est un alias de tâche déclaré dans mix.exs

 defp aliases do [ code_quality: ["format", "credo --strict", "dialyzer"] ] end 

Ici, en général, c'est tout ce dont nous avons besoin pour tester de manière satisfaisante un projet avec des dépendances externes dans le nouveau flux de travail Github .

Intégration continue réussie!