Ingénieur en informatique de formation et de métier, j’administre ce serveur et son domaine et privilégie l'utilisation de logiciels libres au quotidien. Je construis progressivement mon "cloud" personnel service après service pour conserver un certain contrôle sur mes données numériques.
Un projet récent sur lequel je travaille dispose d’une branche, qui, lorsque celle-ci reçoit des modifications, déclenche un événement dans notre système de déploiement continue, afin de déployer le contenu de la branche sur notre environnement de développement. Avec l’augmentation des effectifs de développeurs sur le projet, et pour essayer de garder un environnement de développement le plus à jour possible et faciliter le test des nouvelles fonctionnalités ou des corrections, je me suis penché sur la question de la fusion automatique de branches avec les Github Actions.
Voici un exemple de configuration fonctionnelle:
name: auto-merge
on:
workflow_dispatch:
schedule:
# * is a special character in YAML so you have to quote this string
- cron: '0 7 * * 1-5'
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: master
fetch-depth: 0
- name: Merge on dev-env
run: |
git config user.name github-actions
git config user.email github-actions@github.com
git config --global pull.ff only
git checkout dev-env
git pull
git merge master
git push
Dans cet exemple, tous les jours du lundi au vendredi à 7h, la branche master sera fusionnée dans la branche dev-env et poussée dans le dépôt distant, déclenchant ainsi le processus de déploiement automatisé.
Dans un script automatique, dont le but est de mettre à jour le code local d’un dépôt git avec celui du dépôt distant, sans prendre en compte ni même conserver les éventuelles modifications locales, l’enchaînement de commande git est le suivant:
git fetch git reset --hard HEAD git merge '@{u}'
Avec '@{u}', un raccourci pointant vers la branche upstream de la branche courante.
Récemment, j’ai été confronté à une erreur de droit sur l’une des étapes d’un script bash. Sans possibilité d’agir sur le contexte d’exécution du script, celui-ci utilise l’instruction sudo pour chaque opération. L’une des étapes utilise sed et un opérateur de redirection, afin de modifier un paramètre du fichier fournissant les variables d’environnement, seulement, le sudo associé à sed ne permet pas de procéder à l’écriture du fichier temporaire .env-tmp.
sudo sed 's/API_ENABLED=false/API_ENABLED=true/g' .env > .env-tmp
sudo mv .env-tmp .env
La solution, pourtant simple, consiste en l’utilisation de l’option -i, pour effectuer le changement voulu.
sudo sed -i 's/API_ENABLED=false/API_ENABLED=true/g' .env
Je m’étonne que nous ne l’ayons pas vu au moment de l’écriture du script.
Quelques lignes ce soir, pour signaler que le problème de certificat expiré présent sur Unicoda depuis une quinzaine de jours est maintenant résolu. Lors de la dernière migration du site pour son retour vers OVH, j’avais malheureusement omis de noter la date d’expiration du certificat, pour vérifier que le renouvellement automatique fonctionnait bien.
Et bien, cela n’a pas manqué, les certificats n’ont pas été renouvelé automatiquement, et je n’ai constaté le problème qu’aujourd’hui. C’est une nouvelle preuve du manque de surveillance qui s’illustre ici. Le besoin s’oriente donc, vers un ou des outils de surveillance des performances du serveur, des logs et du bon chargement de la page, ou plus simplement des dates de validité des certificats.
Après maintenant plus d’un an en télétravail, et pouvant compter mes jours de présences en agence sur les doigts de mes deux mains (sans avoir à recourir à un changement de base de numération), et à l’heure de l’explosion des communications en visioconférence, ou au minimum en audioconférence, se pose la question de la webcam. Si mon ordinateur professionnel en possède une intégrée, ce n’est en revanche pas le cas de mon ordinateur fixe. Au détour dans mon agrégateur de flux RSS, j’ai vu passer un article évoquant Raspberry Pi et webcam. Trouvant l’idée intrigante: contourner l’utilisation première d’un Pi pour en faire une webcam, je me suis donc lancé dans la réalisation de ce petit projet.
Composants
Côté composants, rien de bien compliqué:
Un Raspberry Pi zéro W.
Un module image HQ.
Un objectif.
Une carte microSD.
Un câble USB.
Installation
Pour l’installation, que du classique dans le monde du Raspberry Pi. Il suffit de récupérer l’image système dans la partie release du projet showmewebcam sur GitHub, puis de l’écrire sur une carte micro SD avec son logiciel habituel, pour ma part, dd. Il ne reste plus qu’à connecter le module au Pi, insérer la carte et connecter le câble USB en utilisant le port USB de données du Pi (et pas celui d’alimentation, celui situé au milieu du Pi donc), puis à connecter le tout à un ordinateur.
Boîtier
Du côté du boîtier, j’ai trouvé ce modèle 3D plutôt esthétique, que j’ai imprimé en PETG noir. Après impression, petite déception, car l’assemblage nécessite des vis format M2 et/ou M2.5. Mon stock de M3 n’étant d’aucune utilité, j’étais bon pour quelques semaines supplémentaires d’attente pour recevoir quelques modèles de vis compatibles de longueurs variées. Ce qui nous donne au final le panachage suivant :
Pi: 3x M2x5.
Camera/Pi: 2x M2x8 and 1x M2x6.
Case: 4x M2.5×14.
Mise en place
Pour installer la caméra, j’ai modélisé un modèle 3D relativement simple permettant de connecter d’autres pièces provenant d’un modèle de bras articulé. Cela fait l’affaire, même si à l’usage, j’aurais dû mettre plus d’espace au niveau du connecteur. Ce sera pour la version 2.
Les modèles qui composent mon ensemble sont donc les suivants :
Autre mésaventure, après avoir assemblé le boîtier et visser la camera sur le support, j’ai constaté qu’à quelques millimètres près, je ne pouvais plus connecter la caméra, même en utilisant un câble coudé. J’ai donc fait l’acquisition d’un adaptateur 1/4 femelle vers 1/4 mâle pour rehausser la caméra de quelques centimètres.
Résultat
Le résultat est plutôt satisfaisant. La qualité d’image plutôt bonne, même si celle-ci est limitée à du 720p, la limite se situant à priori du côté du traitement des codecs sur le Pi pour espérer voir arriver du 1080p. Évoquons maintenant le sujet qui fâche (un peu) : la latence. La caméra est réactive, mais je crois détecter un léger décalage entre l’image et le son. Il faudrait effectuer le même test avec un Pi 4 à la place du Pi zéro, pour vérifier si la limite provient de la puissance de la plateforme, ou est propre au code utilisé. Raison pour laquelle il ne serait pas inutile de toujours avoir un Pi inutilisé en plus en réserve.
Bref, un projet intéressant à base de Raspberry Pi et qui permet de se familiariser avec les modules caméra du Raspberry Pi.
