AlexisLefebvre.com - Mot-clé - tests2023-07-06T21:46:34+02:00Alexis Lefebvreurn:md5:27efdec687e5c5adcae3e56885c52e81DotclearConfigurer Drone pour Giteaurn:md5:147f40e5033d8bdf6def749136a330052018-10-08T00:15:00+02:002018-12-31T20:48:55+01:00Alexis LefebvrecicomposerdockergitPHPtests<p><a href="https://gitea.io/en-us/" hreflang="en" title="Gitea">Gitea</a> est un clone léger de GitHub et GitLab. Gitea n'intégre pas de système de <abbr title="Continuous Integration / Intégration Continue">CI</abbr> mais heureusement <a href="https://drone.io/" hreflang="en" title="Drone · Continuous Deliver">Drone.io</a> comble ce besoin.</p>
<p>Voici comment je l'ai configuré.</p> <p>J'avais déjà installé Gitea sur le port <code>3000</code> de mon serveur appelé <code>nas</code>, cette URL sert à configurer le paramètre <code>DRONE_GITEA_URL</code> ci-dessous.</p>
<h3>Sur le serveur</h3>
<p>J'ai installé <a href="http://docs.drone.io/installation/" hreflang="en" title="Installation Overview">Drone via Docker</a> sur le port <code>3001</code>, c'est pourquoi la partie <code>ports</code> contient <code>3001:8000</code> et est différente de la configuration officielle.</p>
<p>Fichier <code>docker-compose.yml</code> :</p>
<pre>
version: '2'
services:
drone-server:
image: drone/drone:0.8
ports:
- 3001:8000
- 9000
volumes:
- drone-server-data:/var/lib/drone/
restart: always
environment:
- DRONE_OPEN=true
- DRONE_HOST=${DRONE_HOST}
- DRONE_GITEA=true
- DRONE_GITEA_URL=http://nas:3000/
- DRONE_GITEA_SKIP_VERIFY=true
- DRONE_GITEA_GIT_USERNAME=${DRONE_GITEA_GIT_USERNAME}
- DRONE_GITEA_GIT_PASSWORD=${DRONE_GITEA_GIT_PASSWORD}
- DRONE_GITEA_PRIVATE_MODE=true
- DRONE_SECRET=${DRONE_SECRET}
- DRONE_ADMIN=alexis
drone-agent:
image: drone/agent:0.8
command: agent
restart: always
depends_on:
- drone-server
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- DRONE_SERVER=drone-server:9000
- DRONE_SECRET=${DRONE_SECRET}
volumes:
drone-server-data:
</pre>
<p>Fichier <code>.env</code> :</p>
<pre>
DRONE_SECRET=toto
DRONE_HOST=http://nas:3001
DRONE_GITEA_GIT_USERNAME=alexis
DRONE_GITEA_GIT_PASSWORD=plop
</pre>
<p>Puis lancer Drone :</p>
<pre>
docker-compose up -d
</pre>
<h3>Configuration</h3>
<p>Il faut ensuite se rendre sur l'URL de Drone, pour moi <code>http://nas:3001/</code> puis entrer son identifiant et mot de passe afin que Drone accède à Gitea. Enfin il faut importer les projets et activer le CI sur chaque projet.</p>
<h3>Dans le projet</h3>
<p>Fichier <code>.drone.yml</code> à placer dans le projet et à <em>commiter</em> :</p>
<pre>
pipeline:
install:
image: alexislefebvre/docker-images:7.2-alpine-composer
volumes:
- composer-cache:/root/.composer
commands:
- composer install --no-progress
environment:
- SYMFONY_ENV=test
phpunit:
image: alexislefebvre/docker-images:7.2-alpine-composer
commands:
- php vendor/bin/phpunit
environment:
- SYMFONY_ENV=test
</pre>
<p>J'utilise une image Docker <code><a href="https://github.com/alexislefebvre/docker-images/tree/master/7.2-alpine-composer" hreflang="en" title="docker-images/7.2-alpine-composer at master · alexislefebvre/docker-images">alexislefebvre/docker-images:7.2-alpine-composer</a></code> avec PHP 7.2 et Composer créée pour l'occasion.</p>
<p>Le volume <code>composer-cache</code> est partagé entre les <em>builds</em> ce qui permet à Composer de télécharger les fichiers une fois puis de les placer dans le cache pour ne plus avoir à les télécharger ensuite.</p>
<p>Pour que Drone puisse monter un volume, il faut <a href="https://docs.drone.io/administration/user/admins/" hreflang="en" title="User Admins">s'ajouter à la liste des administrateurs</a> puis marquer le dépôt comme <em>trusted</em> dans Drone.</p>
<h3>Résultat</h3>
<p>Quand tout fonctionne, on voit le résultat des tests à côté de chaque commit dans Gitea.</p>
<p>Et Drone montre les résultats des tests :</p>
<p><a href="https://blog.alexislefebvre.com/public/images/drone.png" title="drone.png"><img src="https://blog.alexislefebvre.com/public/images/.drone_m.png" alt="drone.png" style="display:table; margin:0 auto;" title="drone.png, oct. 2018" /></a></p>Accélérer les tests de Symfony en stockant le cache et les logs en mémoire et en utilisant SQLiteurn:md5:bb140e18f078e2eba097dfe2f9e26a392016-11-24T20:21:00+01:002017-07-23T23:14:10+02:00Alexis Lefebvrecronlinuxsymfonyteststutoriel<p>Lors du développement et du lancement des tests de Symfony, l'écriture et la lecture du cache peuvent prendre un temps important à cause des nombreux accès disques. Voici comment stocker ces fichiers dans la mémoire, bien plus rapide qu'un disque (y compris SSD) et comment utiliser une base de données <a href="https://fr.wikipedia.org/wiki/SQLite" hreflang="fr" title="SQLite — Wikipédia">SQLite</a> lors des tests.</p> <h3>Stocker les fichiers dans la mémoire</h3>
<p>Sous Linux, le dossier <code>/run/shm</code> est un <a href="https://fr.wikipedia.org/wiki/Tmpfs" hreflang="fr" title="tmpfs — Wikipédia">système de fichier temporaire</a>, créé dans la mémoire (RAM).</p>
<p>Créer les répertoires dans la mémoire :</p>
<pre>
mkdir -p /run/shm/projet/cache /run/shm/projet/logs
</pre>
<p>Se déplacer dans le répertoire du projet, puis dans <code>app/</code> avec Symfony 2 ou <code>var/</code> avec Symfony 3 :</p>
<pre>
cd projet/app/
</pre>
<p>Supprimer les dossiers <code>app</code> et <code>cache</code> :</p>
<pre>
rm -rf app/ cache/
</pre>
<p>Créer les liens symboliques afin que les répertoires <code>app</code> et <code>cache</code> pointent vers les dossiers créés au début :</p>
<pre>
ln -s /run/shm/projet/cache cache
ln -s /run/shm/projet/logs logs
</pre>
<p>Ajouter cette ligne dans le <code>crontab</code> afin de créer ces dossiers au démarrage de la machine :</p>
<pre>
@reboot mkdir -p /run/shm/projet/cache /run/shm/projet/logs && chmod 777 -R /run/shm/projet/
</pre>
<h3>Utiliser une base de données SQLite</h3>
<p>Comme cela est <a href="https://github.com/liip/LiipFunctionalTestBundle#tips-for-fixture-loading-tests" hreflang="en" title="liip/LiipFunctionalTestBundle: Some helper classes for writing functional tests in Symfony">décrit dans la documentation deLiipFunctionalTestBundle</a>, il est possible d'utiliser une base SQLite lors des tests :</p>
<pre>
# app/config/config_test.yml
doctrine:
dbal:
default_connection: default
connections:
default:
driver: pdo_sqlite
path: %kernel.cache_dir%/test.db
</pre>
<h3>Comparaison</h3>
<p>Afin de comparer l'impact de ces modifications sur les performances, j'ai lancé un scénario d'un test Behat avec les différents configurations.</p>
<p>Le cache a été <em>pré-chauffé</em> avant chaque test : <code>app/console cache:warmup --env=test</code></p>
<h4>Résultats</h4>
<pre>
+--------+---------------------+----------------------+
| X | cache sur le disque | cache dans /run/shm/ |
+--------+---------------------+----------------------+
| MySQL | 23,36 s | 22,22 s |
| SQLite | 10,90 s | 8,82 s |
+--------+---------------------+----------------------+
</pre>
<h3>Conclusion</h3>
<p>Comme le montrent les résultats ci-dessus, l'utilisation de la RAM et d'une base de données SQLite peuvent diviser par 3 le temps d'un test.</p>