Archives de
Étiquette : CI

Utiliser les GitHub Actions pour PHP

Utiliser les GitHub Actions pour PHP

GitHub a publié les GitHub actions afin de mettre en place du CI/CD directement sur leur plateforme.

Nous allons les utiliser pour lancer les tests et PHPStan.

Afin de pourvoir tester en local et pas seulement sir GitHub nous utiliserons ACT. Une fois installé, utiliser les commandes :

  • act.exe -l afin de lister vos actions
  • act.exe afin d’exécuter vos actions
La liste des actions
L’exécution d’une action

Pour avoir une actions il faut créer un fichier sous .github/workflows/. Afin de ne pas avoir à tout faire nous allons utiliser l’action setup-php-action.

Voici le fichier que nous allons utiliser.

name: "CI"

# Triggers the workflow on push or pull request events
on: [push, pull_request]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
            php-version: '7.4'
            tools: phpstan, composer

      - name: Validate composer.json and composer.lock
        run: composer validate

      - name: Get composer cache directory
        id: composercache
        run: echo "::set-output name=dir::$(composer config cache-files-dir)"

      - name: Cache dependencies
        uses: actions/cache@v2
        with:
          path: ${{ steps.composercache.outputs.dir }}
          key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
          restore-keys: ${{ runner.os }}-composer-

      - name: Install dependencies
        run: composer install --prefer-dist

      - name: Setup problem matchers for PHPUnit
        run: echo "::add-matcher::${{ runner.tool_cache }}/phpunit.json"

      - name: Run PHPStan
        run: phpstan analyse src --level max

      - name: "Run tests"
        env:
          sfdc_username: ${{ secrets.SFDC_USERNAME }}
          sfdc_password: ${{ secrets.SFDC_PASSWORD }}
          sfdc_client_secret: ${{ secrets.SFDC_CLIENT_SECRET }}
          sfdc_client_id: ${{ secrets.SFDC_CLIENT_ID }}
        run: |
          cp .env.example .env
          vendor/bin/phpunit --coverage-clover=coverage.xml
  • A la ligne 4 nous demandons a lancer l’action sur les push et les pull request.
  • Ligne 11 et 12 nous fessons un checkout de notre code.
  • Ligne 14 et 14 nous utilisons l’action « Setup PHP » avec PHP 7.4 et composer, ligne 18 et 19.
  • Ensuite nous installons nos dépendances.
  • Puis ligne 39 nous ajoutons un matcher PHPUnit afin d’avoir les informations dans la GUI.
  • Ligne 42 nous exécutons PHPStan.
  • Ligne 45 a 49, nous utilisons des secret en tant que variable d’environnements, puis ligne 52 nous exécutons nos tests.

Afin d’ajouter des secrets, directions l’onglet Settings puis la section Secrets, il vous restera à cliquer sur New Secret.

Pour plus d’informations, direction la section Secret de la doc.

Ci-dessous d’autre image des actions:

Actions en cours
Affichage lors d’un échec
Détails de l’échec.
Historique des actions

Pour plus d’informations, regardez la documentations des GitHub Actions.

Flutter et GitLabCI

Flutter et GitLabCI

Si vous souhaitez utiliser GitLabCI pour vos projet Flutter, voici la base du fichier .gitlab-ci.yml qu’il vous faudras:

Il faut commencer par spécifier une image docker a utiliser:

image: openjdk:8-jdk
Code language: YAML (yaml)

Nous déclarons ensuite des variables afin de pouvoir mettre a jour plus facilement:

variables: ANDROID_COMPILE_SDK: "28" ANDROID_BUILD_TOOLS: "28.0.2" ANDROID_SDK_TOOLS: "4333796" FLUTTER_VERSION: "https://storage.googleapis.com/flutter_infra/releases/stable/linux/flutter_linux_v1.12.13+hotfix.5-stable.tar.xz"
Code language: YAML (yaml)

Nous enchainons avec la description du test, les installtion de flutter, android sdk et autres

test: before_script: - apt-get -qq update --yes - apt-get -qq install --yes wget tar unzip lib32stdc++6 lib32z1 lcov - wget --quiet --output-document=android-sdk.zip https://dl.google.com/android/repository/sdk-tools-linux-${ANDROID_SDK_TOOLS}.zip - unzip -q -d android-sdk-linux android-sdk.zip - mkdir /root/.android - touch /root/.android/repositories.cfg - echo y | android-sdk-linux/tools/bin/sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}" >/dev/null - echo y | android-sdk-linux/tools/bin/sdkmanager "platform-tools" >/dev/null - echo y | android-sdk-linux/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS}" >/dev/null - export ANDROID_HOME=$PWD/android-sdk-linux - export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/ - export CI='true' # temporarily disable checking for EPIPE error and use yes to accept all licenses - set +o pipefail - yes | android-sdk-linux/tools/bin/sdkmanager --licenses - set -o pipefail # flutter sdk setup - wget --quiet --output-document=flutter-sdk.tar.xz $FLUTTER_VERSION - tar -xf flutter-sdk.tar.xz - export PATH=$PATH:$PWD/flutter/bin - echo flutter.sdk=$PWD/flutter > android/local.properties - flutter packages get
Code language: YAML (yaml)

Puis la partit test en elle même et la creation d’un artefact contenant les resultat de la couverture de code:

script: - flutter test --coverage - genhtml coverage/lcov.info --output=coverage artifacts: paths: - coverage/ expire_in: 5 days
Code language: YAML (yaml)

Pour finir la partit publication de la couverture des tests dans les GitLab Pages:

pages: stage: .post script: - mkdir public - rm -Rf public/* - mv README.md public/README.md - mv -v coverage/* public/ artifacts: paths: - public only: - master
Code language: YAML (yaml)

Ce qui nous donne au final:

image: openjdk:8-jdk variables: ANDROID_COMPILE_SDK: "28" ANDROID_BUILD_TOOLS: "28.0.2" ANDROID_SDK_TOOLS: "4333796" FLUTTER_VERSION: "https://storage.googleapis.com/flutter_infra/releases/stable/linux/flutter_linux_v1.12.13+hotfix.5-stable.tar.xz" test: before_script: - apt-get -qq update --yes - apt-get -qq install --yes wget tar unzip lib32stdc++6 lib32z1 lcov - wget --quiet --output-document=android-sdk.zip https://dl.google.com/android/repository/sdk-tools-linux-${ANDROID_SDK_TOOLS}.zip - unzip -q -d android-sdk-linux android-sdk.zip - mkdir /root/.android - touch /root/.android/repositories.cfg - echo y | android-sdk-linux/tools/bin/sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}" >/dev/null - echo y | android-sdk-linux/tools/bin/sdkmanager "platform-tools" >/dev/null - echo y | android-sdk-linux/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS}" >/dev/null - export ANDROID_HOME=$PWD/android-sdk-linux - export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/ - export CI='true' # temporarily disable checking for EPIPE error and use yes to accept all licenses - set +o pipefail - yes | android-sdk-linux/tools/bin/sdkmanager --licenses - set -o pipefail # flutter sdk setup - wget --quiet --output-document=flutter-sdk.tar.xz $FLUTTER_VERSION - tar -xf flutter-sdk.tar.xz - export PATH=$PATH:$PWD/flutter/bin - echo flutter.sdk=$PWD/flutter > android/local.properties - flutter packages get script: - flutter test --coverage - genhtml coverage/lcov.info --output=coverage artifacts: paths: - coverage/ expire_in: 5 days pages: stage: .post script: - mkdir public - rm -Rf public/* - mv README.md public/README.md - mv -v coverage/* public/ artifacts: paths: - public only: - master
Code language: YAML (yaml)

Un dépot git est disponible: https://gitlab.com/dayo/testgitlabciflutter/ et la couverture de code https://dayo.gitlab.io/testgitlabciflutter/

Rails 4 et MongoDB part 3 : Travis

Rails 4 et MongoDB part 3 : Travis

Tout d’abord, qu’est-ce que Travis-CI ?

Travis-CI est un serveur d’intégration continue gratuit pour les projects open source.

Il est utilisé par beaucoup de projet afin de vérifier que les pull request n’introduise pas de bug et qu’il n’y a pas de régression lors de modifications.

Afin de l’utiliser il faut suivre les étapes suivantes:

  • Se connecter sur travis-ci.org avec son compte GitHub
  • Activer les dépôts que l’on souhaites tester
  • Ajouter un fichier .travis.yml a la racine de notre projet

Le fichier .travis.yml contient les informations dont Travis-CI a besoin afin de lancer les tests de votre dépôt.

Dans le cas de notre projet RoR avec MongoDB, il nous faut spécifier :

  • le langague
  • la version de interpréteur Ruby
  • notre base de données
  • l’environnement et la commende pour lancer les tests

Au final notre fichier .travis.yml sera le suivant :

language: ruby
rvm:
  -  2.0.0

services:
  - mongodb

script:
  - RAILS_ENV=test
  - bundle exec rake cucumber

Une fois se fichier disponible sur GitHub, Travis-CI va automatiquement lancer les tests a chaque commit.

Pour le dépôt du projet GitHub utilisé pour mes articles, la page Travis-CI est la suivante : https://travis-ci.org/dayofr/rails_tuto

On peux y voir le dernier test, la sortie de la console ainsi que l’historique des builds :

travis

Il est possible de rajouter un badge fin d’indiquer l’état actuel des tests du projet, généralement dans le fichier README à la racine du dépôt.