Jean-Yves Gastaud blog

Faire tourner GitLab CI sur Cloudflare Workers & Containers : un exécuteur GitLab Runner maison

Tue, 11 Aug 2026 10:00:00 +0200

Les runners GitLab CI tournent traditionnellement sur des VMs ou des pods Kubernetes qu’il faut dimensionner, garder chauds, et payer même quand ils ne font rien.

Et si on déportait l’exécution des jobs sur une plateforme serverless comme Cloudflare, avec un container provisionné à la demande, à la seconde, pour chaque job ?

C’est la question que j’ai voulu creuser avec gitlab-runner-cloudflare : un exécuteur GitLab Runner qui exécute les jobs CI sur Cloudflare Workers + Containers.

Pourquoi ce projet

GitLab Runner expose un Custom Executor : une interface très simple (config / prepare / run / cleanup), volontairement agnostique du transport et de l’infrastructure sous-jacente. Il n’y a ni notion de Docker, ni de SSH imposée : c’est à l’exécuteur de décider comment et où le job tourne.

Cette généricité m’a donné envie de tester une hypothèse : est-ce que cette interface est suffisamment ouverte pour qu’on puisse la brancher sur une plateforme serverless comme Cloudflare Workers et Cloudflare Containers, plutôt que sur les habituels VMs, Docker ou Kubernetes ?

L’intérêt, s’il se confirme, serait un modèle de coût très différent : plus de fleet de runners à garder chaude en permanence, un container provisionné (et facturé) à la demande pour chaque job, à l’échelle de l’edge Cloudflare.

C’est un projet de type POC/R&D : l’objectif n’était pas de livrer un produit fini, mais de valider la faisabilité, documenter les choix via des ADR, et pousser les points durs (build d’images sans Docker-in-Docker, images de job dynamiques, arm64…) jusqu’à avoir une réponse concrète plutôt qu’une intuition.

Comment ça s’articule

GitLab Runner (sur n'importe quel host)
  │  Custom Executor contract (config/prepare/run/cleanup)
  ▼
executor/   binaire Go : gitlab-cf-executor
  │  HTTP
  ▼
worker/     Worker Cloudflare (control plane)
  │  1 Durable Object + 1 Container par job
  ▼
container/  Alpine + agent Kaniko (exécute le script du job,
            build les images sans daemon Docker)

executor/ est le binaire que GitLab Runner invoque directement. Il parle en HTTP à un worker/ déployé, avec un mode de repli 100% local (sans compte Cloudflare) pour développer et tester sans dépendance externe.
worker/ est le control plane : il provisionne un Container (via une Durable Object) par job, et relaie prepare/run/cleanup à un petit agent CGI packagé dans l’image du container.

Objectifs atteints

La question de faisabilité a une réponse : oui, un Custom Executor GitLab Runner peut piloter des jobs CI sur Cloudflare Workers + Containers, validé sur un déploiement Cloudflare réel (pas seulement en local avec wrangler dev).
Build d’images sans Docker-in-Docker : Cloudflare Containers n’autorise pas le mode privilégié, ce qui élimine Docker-in-Docker, Buildah et BuildKit (les trois ont besoin de unshare(CLONE_NEWUSER)). Le spike dind-validation a confirmé que Kaniko s’en sort sans privilèges particuliers, et c’est lui qui a été retenu.
Logs en streaming : la sortie d’un job est diffusée en direct (et non plus bufferisée puis renvoyée d’un coup), avec un endpoint dédié pour récupérer le code de sortie une fois le flux terminé — contrainte imposée par le fait que les headers CGI doivent précéder le corps de la réponse.
Images de job dynamiques : plutôt qu’une image container figée et unique, prepare.cgi télécharge et déballe (via skopeo/umoci) l’image image: demandée par n’importe quel job, et run.cgi exécute le script du job chrooté dans cette image — voir ADR-0004.
git clone qui fonctionne même sur une image sans git : get_sources s’exécute hors du chroot, dans le sandbox qui, lui, embarque git, en symlinkant /builds//cache vers le rootfs de l’image du job — le même principe que les helpers dédiés des exécuteurs Docker/Kubernetes de GitLab Runner.
Support de services:, cache: et artifacts: : détaillé juste en dessous.
Tests et CI : 41 tests unitaires Go côté executor/, tests unitaires Vitest côté worker/, et un test E2E qui exécute un vrai build Kaniko via un wrangler dev local. Le tout est automatisé dans .gitlab-ci.yml (tests sur chaque changement pertinent, déploiement manuel sur main).
Documentation : 5 ADR qui tracent les décisions d’architecture (plateforme d’exécution, support multi-architecture, compatibilité fleeting/docker_autoscaler, images de job dynamiques, services/cache/artifacts), 2 spikes qui documentent les validations techniques, et des README par composant.
Control plane authentifié : l’API HTTP du Worker était jusqu’ici ouverte à quiconque connaissait son URL *.workers.dev — un jeton partagé en Authorization: Bearer est désormais requis sur chaque route, voir plus bas.

`services:`, `cache:`, `artifacts:` : comment ça marche concrètement

GitLab expose les services: d’un job au Custom Executor via une seule variable, CUSTOM_ENV_CI_JOB_SERVICES — un tableau JSON, à charge de l’exécuteur de démarrer/stopper les services lui-même. Rien de plus n’est fourni : pas de réseau Docker, pas d’API à implémenter, juste cette information.

# .gitlab-ci.yml
cf-executor:demo-services:
  services:
    - name: redis:7-alpine
      alias: redis
  script:
    - for i in $(seq 1 10); do nc -z redis 6379 && break; sleep 1; done
    - nc -z redis 6379 && echo "OK" || exit 1

Puisque chaque job tourne déjà dans une seule instance de Cloudflare Container (un seul namespace réseau), un service n’a pas besoin d’isolation container : il suffit de le démarrer comme un process en arrière-plan, chrooté dans son propre rootfs (dépaqueté avec skopeo/umoci, comme l’image du job), et de le rendre joignable par son alias. start-service.sh s’appuie sur setsid pour détacher le process de la requête CGI qui l’a lancé, et sur le config.json (runtime-spec OCI) qu’umoci produit pour retrouver l’ENTRYPOINT/CMD de l’image sans avoir à les redéclarer :

# extrait simplifié de start-service.sh
ROOTFS_DIR=$(pull-image.sh "$IMAGE" "$BUNDLE_DIR")
jq -r '.process.args[]' "$BUNDLE_DIR/config.json" > "$ARGV_FILE"   # ENTRYPOINT+CMD déjà résolus par umoci
setsid "$LAUNCH_SCRIPT" "$ENV_FILE" "$ARGV_FILE" "$ROOTFS_DIR" >"$LOG_FILE" 2>&1 &
echo $! > "$PID_FILE"

Pour cache:/artifacts:, le constat était différent : restore_cache/download_artifacts/archive_cache/upload_artifacts sont des scripts générés par GitLab Runner comme n’importe quelle autre étape, mais leur documentation officielle est explicite — ils appellent directement le binaire gitlab-runner lui-même, qui n’a aucune raison de se trouver dans l’image (dynamique) du job. La correction reprend le principe déjà en place pour get_sources/git : élargir la liste des étapes qui s’exécutent hors chroot, dans le sandbox qui embarque ce binaire :

# run.cgi
case "$stage" in
  get_sources|restore_cache|download_artifacts|archive_cache|archive_cache_on_failure|upload_artifacts_on_success|upload_artifacts_on_failure)
    unchrooted_stage=1 ;;
  *)
    unchrooted_stage=0 ;;
esac

docker:dind en tant que service reste explicitement non supporté, pour la même raison qu’en tant qu’image de job (mode privilégié requis) — voir ADR-0005 pour le détail complet.

Ce que le déploiement réel a révélé

Le POC a une règle simple : rien n’est considéré acquis avant d’avoir tourné sur un vrai déploiement Cloudflare, pas seulement en local ou sous wrangler dev. En ajoutant le support des services:, cette règle a payé trois fois — trois bugs invisibles en local, qui ne se sont révélés qu’en poussant worker:deploy pour de vrai et en faisant tourner les jobs de démo à travers le runner enregistré.

1. /etc/hosts est monté en lecture seule sur un vrai Cloudflare Container. La première implémentation ajoutait alias 127.0.0.1 directement dans /etc/hosts — ça fonctionne parfaitement dans un test Docker local (où /etc/hosts est un fichier bind-monté classique, inscriptible), et échoue en production :

$ echo "1.2.3.4 foo" >> /etc/hosts
/tmp/run-script.sh: line 1: can't create /etc/hosts: Read-only file system

$ cat /proc/mounts | grep -E "hosts|resolv"
overlay /etc/hosts       overlay ro,relatime,... 0 0
overlay /etc/resolv.conf overlay rw,relatime,... 0 0

Cloudflare y monte /etc/hosts comme un overlay dédié, distinct du reste de /etc — mais /etc/resolv.conf, lui, reste inscriptible. La résolution des alias passe donc maintenant par un dnsmasq local, démarré au premier service déclaré, qui répond pour les alias connus et relaie le reste vers les vrais résolveurs DNS capturés avant que resolv.conf ne soit réécrit :

# setsid dnsmasq --no-daemon --addn-hosts=/tmp/service-hosts --server=<upstream1> --server=<upstream2>
echo "nameserver 127.0.0.1" > /etc/resolv.conf

2. Un prepare_exec qui échoue est rejoué jusqu’à 3 fois par GitLab Runner, sur la même instance de container. Un service déjà démarré par une tentative précédente (parce qu’un autre service du même job avait échoué) restait actif et occupait déjà son port :

185:M ... # Warning: Could not create server TCP listening socket *:6379: bind: Address in use
185:M ... # Failed listening on port 6379 (tcp), aborting.

Un faux négatif qui accusait l’image du service plutôt que le vrai coupable. Chaque service voit maintenant son PID tracé dans un fichier dédié, et toute instance précédente est tuée avant d’en démarrer une nouvelle :

if [ -f "$PID_FILE" ] && kill -0 "$(cat "$PID_FILE")" 2>/dev/null; then
  kill "$(cat "$PID_FILE")" 2>/dev/null || true
  sleep 1
fi

3. La version du binaire gitlab-runner embarqué doit suivre celle du runner enregistré, pas une version au hasard. archive_cache invoque gitlab-runner cache-archiver avec des flags qui varient d’une version à l’autre ; un décalage de version (17.9 embarqué vs 19.2 enregistré, dans mon cas) fait échouer l’appel sur un flag inconnu :

Incorrect Usage: flag provided but not defined: -alternate-file
FATAL: flag provided but not defined: -alternate-file

Silencieusement, en plus : GitLab Runner traite les échecs de cache comme non bloquants et affiche quand même le job en succès. Un job vert peut donc cacher un cache qui ne s’est jamais réellement créé — c’est en lisant le log de l’étape archive_cache, pas le statut global du job, que le problème est apparu.

Ces trois points illustrent bien la limite du wrangler dev local évoquée plus bas : il ressemble à Cloudflare, mais ce n’en est pas un.

Sécuriser l’API du control plane

Le Worker était déployé sur le sous-domaine public *.workers.dev, sans route ni domaine personnalisé — et son API HTTP (/jobs/:jobId/{prepare,run,cleanup}) n’avait strictement aucune authentification. N’importe qui tombant sur l’URL pouvait provisionner et piloter des containers.

Deux options pour corriger ça : les service tokens de Cloudflare Access (Zero Trust), plus « natifs » côté Cloudflare, ou un simple jeton partagé en Authorization: Bearer. Access aurait demandé un domaine personnalisé et une zone — que ce Worker n’a pas — plus une application Access à configurer hors de wrangler.toml. Le jeton partagé, lui, ne demande aucune infrastructure Cloudflare supplémentaire : juste du code.

// worker/src/handlers.ts
export function isAuthorized(request: Request, sharedSecret: string | undefined): boolean {
  if (!sharedSecret) return false; // fail closed si le secret n'est pas configuré
  const header = request.headers.get("Authorization") ?? "";
  if (!header.startsWith("Bearer ")) return false;
  return timingSafeEqual(header.slice(7), sharedSecret);
}

Vérifié avant même de parser la route, pour qu’un appelant non authentifié ne puisse pas distinguer une route existante d’une 404. La comparaison en temps constant est écrite à la main plutôt qu’avec crypto.subtle.timingSafeEqual — cette méthode est une extension Cloudflare du Web Crypto API, absente du SubtleCrypto de Node, alors que ce fichier reste volontairement testable en vitest classique (pas @cloudflare/vitest-pool-workers).

Côté executor/, GITLAB_CF_EXECUTOR_WORKER_TOKEN (même valeur que le SHARED_SECRET posé côté Worker via wrangler secret put, jamais commité) est envoyé sur chaque requête. Et comme pour les trois bugs de la section précédente, la vraie validation est venue du déploiement réel : le premier job de démo rejoué après la mise en place a échoué avec un 401 unauthorized — pas un faux négatif, mais la preuve que le binaire gitlab-cf-executor déjà en place sur le runner datait d’avant ce correctif et n’envoyait donc aucun jeton du tout. Une fois rebuild, le job est repassé au vert.

Limites actuelles / reste à faire

Ce projet est un POC, pas un produit fini. Ce qui n’est pas (encore) résolu :

Pas de lane arm64 : Cloudflare Containers ne fait que de l’amd64. Le choix du provider pour la partie arm64 (AWS Graviton, Oracle Ampere, Hetzner) n’est pas tranché, et l’intégration docker_autoscaler/fleeting qui en découle n’est pas encore implémentée — voir ADR-0002 et ADR-0003.
Pas d’authentification registre privé pour les images de job dynamiques : skopeo copy sait faire du --src-creds, mais ce n’est pas encore câblé.
Pas de cache de layers entre jobs : chaque container est détruit au cleanup, donc chaque job re-télécharge son image depuis zéro. Un cache R2 est envisagé si la latence devient un vrai problème en pratique.
La persistance de cache: entre jobs reste à la charge de l’opérateur du runner : restore_cache/archive_cache fonctionnent désormais correctement, mais sans [runners.cache] configuré côté config.toml (backend S3-compatible, R2 par exemple), il n’y a nulle part où persister le cache — une configuration d’infrastructure, pas quelque chose que ce projet peut fournir depuis le container.
Les services n’ont qu’un seul alias par défaut, dérivé du nom d’image (postgres:14 → postgres), pas le schéma complet multi-alias de GitLab — un alias: explicite couvre les cas plus complexes. Ils démarrent aussi séquentiellement, pas en parallèle, et sans protocole de disponibilité : un script de job doit sonder lui-même le service (comme le recommande GitLab de façon générale).
Build ≠ run dans le même job : Kaniko sait builder et pousser une image, mais rien n’est prévu pour l’exécuter dans la foulée, dans le même job.
Pas d’accès SSH/debug direct à une instance de Container Cloudflare pour le troubleshooting local.
wrangler dev peu fiable sur les requêtes longues (build Kaniko, cold start) — un problème confirmé local-only, sans impact sur un déploiement réel, contourné plutôt que corrigé dans les tests E2E.

Le détail de chacun de ces points, avec ses sources, est maintenu dans docs/TODO.md.

Liens vers le projet

Installer et configurer Renovate Bot sur GitLab CE

Sat, 27 Nov 2021 16:14:35 +0100

Renovate Bot est un outil permettant de contrôler les versions des dépendances de ses projets.

On peut le comparer au projet Dependabot qui est disponible sur GitHub.

Dans cette article, nous allons explorer comment installer et configurer Renovate pour fonctionner sur une instance de Gitlab CE.

Prérequis

Afin de pouvoir suivre le process d’initialisation vous devez pouvoir :

Créer des groupes et projets
Avoir accès ou installer, au moins, 1 GitLab Runner avec un executeur docker
Avoir un compte GitHub (même si nous allons utiliser GitLab, il servira notamment à récupérer les releases notes des projets)

Initialisation

Structure de projets

Créer un groupe projet Renovate
Créer 2 projets dans le groupe
- un projet renovate-config qui contiendra les fichiers de configurations partageables à tous les projets du GitLab;
- un projet renovate-runner qui contiendra les configurations pour dédier au conteneur Renovate.

Utilisateur Gitab

Comme le nom du projet l’indique (RenovateBot) nous allons avoir de créer un compte utilisateur représentant notre Bot.

Pour notre exemple, nous l’appelerons Renovate Bot <renovatebot@example.com> et le nom d’utilisateur renovatebot.

Cet utilisateur servira à 2 choses :

les Merge Requests, commits… seront crées par le Bot ;
restreindre les droits de renovate à ne parcourir que les projets sur lequels il est explicitement invités.

Configuration du projet renovate-runner

Nous allons commencer par travailler sur la partie Runner. Rendons nous donc dans le projet renovate-runner précédemment créé.

Création des tokens utilisateurs (PAT : Personal Access Token)

GitLab

Sur votre instance GitLab, connectez-vous avec le compte renovatebot créé précédemment.

Nous allons créé un Access Token via votre profil utilisateur (/-/profile/personal_access_tokens).

Nommez le token comme bon vous semble (renovatebot par exemple) et choisissez les scopes suivants comme indiqué dans la documentation :

read_user,
api,
write_repository.

Copiez le token et retourner sur le projet renovate-runner, dans les CI/CD Settings (menu Settings > CI/CD > Variables)

et créer une nouvelle variable nommée RENOVATE_TOKEN avec la valeur du token récupérée.

GitHub

Afin de pouvoir récupérer les releases notes des projets et ne pas être soumis aux limitations de l’API GitHub, il va nous falloir créer un GitHub et y créer un Personal Acces Token.

Copiez le token et retourner sur le projet renovate-runner, dans les CI/CD Settings (menu Settings > CI/CD > Variables)

et créer une nouvelle variable nommée GITHUB_COM_TOKEN avec la valeur du token récupérée.

Notre fichier `.gitlab-ci.yml`

image: renovate/renovate:29	

variables:
  RENOVATE_BASE_DIR: $CI_PROJECT_DIR/renovate
  RENOVATE_GIT_AUTHOR: Renovate Bot <renovatebot@exemple.com>
  RENOVATE_OPTIMIZE_FOR_DISABLED: 'true'
  RENOVATE_REPOSITORY_CACHE: 'true'
  LOG_LEVEL: debug


cache:
  key: ${CI_COMMIT_REF_SLUG}-renovate
  paths:
    - $CI_PROJECT_DIR/renovate

renovate:
  stage: deploy
  resource_group: production
  only:
    - schedules
  script:
    - renovate $RENOVATE_EXTRA_FLAGS

Renovate propose la plupart de ces configurations en variable d’environnements. Néanmoins, pour pouvoir utiliser le bot dans d’autres contextes que GitLab (un lancement manuel par exemple), je n’ai gardé que les paramètres spécifiques à GitLab dans le fichier .gitlab-ci.yml.

Le reste des configurations se trouvent donc dans le fichier config.js que nous allons regarder tout de suite. ⬇️

Fichier de configuration Renovate

Renovate s’appuie donc sur un fichier de configuration config.js

On y défini notamment la plateforme Git à utiliser, les options du configurations propres au runner et les profils de configurations (Config Presets) qui seront appliqués pour tous les projets onboardingConfig.

module.exports = {
        endpoint: 'https://[url du gitlab]/api/v4/',
        platform: 'gitlab',
        persistRepoData: true,
        logLevel: 'debug',
        onboardingConfig: {
                "extends": [
                        "local>groupes/sous-groupes/renovate/renovate-config"
                ],
        },
        autodiscover: true,
};

Tâche récurrente

Menu CI/CD > Schedules
Créer une nouvelle tâche planifiée avec la fréquence de passage que vous souhaitez (j’ai fait le choix, totalement arbitraire, de faire tourner l’analyse 2 fois par jour) et à déclencher.
Sauvegardez

Configuration des configurations par défaut

Dans le projet renovate-config nous allons créer un simple fichier renovate.json qui sera celui recherchait par défaut par le fichier config.json et notamment la ligne "local>groupes/sous-groupes/renovate/renovate-config".

Voici les choix que j’ai fait :

 {
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "depTypeList": ["devDependencies", "require-dev"],
      "updateTypes": ["patch", "minor", "digest"],
      "groupName": "devDependencies (non-major)"
    }
  ],
  "extends": [
    "config:base",
    ":preserveSemverRanges",
    ":dependencyDashboard",
    ":rebaseStalePrs",
    ":enableVulnerabilityAlertsWithLabel('security')",
    "group:recommended"
  ]
}

packageRules permet de créer des nouveaux regroupements. Dans notre cas, cela nous permet d’avoir une seule Merge Request contenant toutes les dépendances de développements du projet lorsqu’elles sont non-majeures.
extends nous permet de définir les règles/configs presets que l’on souhaite activer. On active notamment le Dependency Dashboard qui permet de suivre dans un ticket l’état de toutes les mises à jour disponibles et/ou des MR en cours et différents Group Presets.

Activer le bot pour les projets

Avec ces configurations, chaque projet souhaite activer le bot n’a que 4 étapes à suivre :

Ajouter l’utilisateur renovatebot sur le projet, avec au moins un droit de contributeur
Activer les issues pour le dependency Dashboard
Activer les merge requests pour tout d’abord avec une 1ère Merge Request de création de la configuration renovate, puis les MR associées aux mises à jours à appliquer.
Affiner les configurations de Renovate selon les spécificités de son projet

Et voilà 🍾

Nous avons maintenant un bot Renovate qui tourne de façon régulière et va updater l’ensemble des repositories auxquels il a accès.

Test de Gomplate

Sat, 20 Nov 2021 00:00:00 +0000

Gomplate est un utilitaire en Go qui permet de faire un rendu dynamique.

La possiblité d’utiliser du templating Go, d’utiliser les fonctions built-in de gotemplate et le support de datasources par Gomplate me paraissait intéressant.

Objectifs

Ce test va probablement détourner un peu l’objectif initial du produit mais je vais tenter de voir si Gomplate peut être un candidat pour aider à la génération de documentation dynamique.

Le projet

_Point de départ : Documentation de Gomplate

Préparation

Installation de Gomplate

Il existe de nombreuses méthodes pour installer Gomplate.

De mon côté, j’essaie en ce moment de privilégier l’utilisaton de asdf pour gérer mes utilitaires locaux et leurs versions.

La procédure n’étant pas détaillée dans la documentation officielle Gomplate, la voici ci-dessous :

Ajout du plugin

asdf plugin add gomplate

Installation de la version de gomplate souhaitée

asdf install gomplate v3.10.0

Activation pour tout le système

asdf global gomplate v3.10.0

Vérification de bon fonctionnement

gomplate --version
gomplate version 3.10.0

Ca fonctionne ! 👍

Découverte du fonctionnement de l’outil

Comment déclarer un template ?

Pour notre besoin, nous allons avoir besoin de pouvoir créer un (1) ou plusieurs fichiers d’entrée qui contiendront des variables que l’on souhaitera remplacer lors de la génération.

La documentation de la CLI parle de l’option -t pour un template mais cela ne semble pas être réellement notre besoin.

Par contre, la page de documentation sur la configuration mentionne des entrées qui semblent prométeuses inputFiles et inputDir. 🍾

Testons cela. 🚀

Test avec 1 seul template en entrée

Nous allons créer 2 fichiers pour ce test

test.tpl qui va simplement reprendre l’exemple de base de gomplate

Hello {{ .Env.USER }}

et le fichier .gomplate.yaml

inputFiles:
  - basic.tpl

Vérifions notre arborescence

tree -a
.
├── basic.tpl
└── .gomplate.yaml

0 directories, 2 files

Testons l’exécution de gomplate

gomplate
Hello jyg

Test avec plusieurs fichiers de template

Pour ce test, nous allons avoir une arborescence légèrement plus complexe avec l’ajout d’un dossier in dans lequel on va avoir 2 fois notre fichier précédent basic.tpl qui sera déposé (et légèrement édité).

tree -a -L 2
.
├── .gomplate.yaml
├── in
│   ├── basic2.tpl
│   └── basic.tpl

Nous faisons évoluer le fichier .gomplate comme ceci :

inputDir: in/

En exécutant gomplate on se rend compte qu’il n’y a pas d’output dans le terminal.

Par contre 2 fichiers on était créé à la racine de notre dossier :

tree -a -L 2
.
├── basic2.tpl
├── basic.tpl
├── .gomplate.yaml
├── in
│   ├── basic2.tpl
│   └── basic.tpl

et ces 2 fichiers contiennent bien la variable interprétée.

Il faut donc définir la valeur outputDir pour un mapping 1:1 ou outputMap si l’on souhaite pouvoir agir sur le nom des fichiers de sorti.

Exemple d’utilisation d’outputMap pour modifier l’extension du fichier de tpl à md (markdown).

inputDir: in/
outputMap: |
    out/{{ .in | strings.ReplaceAll ".tpl" ".md" }}

OK à priori, avec ces 2 directives nous devrions être en mesure de pouvoir avancer sur notre projet.

Implémentation du projet

Pour notre test, nous allons reprendre la structure simplifier d’un projet existant.

Quelques élements de contexte :

le projet sert de documentation,
chaque page de la documentation est un fichier markdown,
à la génération de la documentation, on souhaite être capable de récupérer ou injecter des variables, par exemple, la branche Git utilisée pour la génération,
on veut que les fichiers générés respectent l’arborescence initiale.

Préparation des dossiers et fichiers

tree -a -L 4
.
├── .gomplate.yaml
├── in
│   ├── en
│   │   ├── docker-compose.md
│   │   └── security
│   │       ├── cohesion.md
│   │       └── gitleaks.md
│   └── home.md

Les détails intéressants :

.gomplate.yaml

inputDir: in/
outputDir: out/

dans le fichier docker-compose.md on va définir la récupération d’une variable d’environnement représentant la branche Git.

# Docker-compose

## Docker-compose helper

...

```yaml
include:
  - project: '<group>/<project>/templates'
    ref: {{ env.Getenv "GITBRANCH" }}
    file: '/docker-compose.gitlab-ci.yml'
```

...

Exécution et vérification

On peut maintenant lancer la commande GITBRANCH=test gomplate et vérifiier les résultats.

✅ le dossier out contient bien la même arborescence de fichiers ;

tree -a -L 4
.
├── .gomplate.yaml
├── in
│   ├── en
│   │   ├── docker-compose.md
│   │   └── security
│   │       ├── cohesion.md
│   │       └── gitleaks.md
│   └── home.md
└── out
    ├── en
    │   ├── docker-compose.md
    │   └── security
    │       ├── cohesion.md
    │       └── gitleaks.md
    └── home.md

✅ la variable {{ env.Getenv "GITBRANCH" }}est bien remplacée par la valeur attendue ;
✅ il est possible de définir une valeur par défaut {{ env.Getenv "GITBRANCH" "defaultbranch" }}

# Docker-compose

## Docker-compose helper

...

```yaml
include:
  - project: '<group>/<project>/templates'
    ref: test
    file: '/docker-compose.gitlab-ci.yml'
```

...

Conclusion

Gomplate répond plutôt bien à un besoin simple de génération / transformation de fichiers. En moins d'1 heure, en ne connaissant par l’outil, nous avons réussi à répondre à notre besoin, sans partir dans des outils plus complexes à installer et utiliser.

Le fait que Gomplate soit disponible comme un simple binaire facilite son installation et est donc très intéressant à utiliser aussi dans le cadre d’une CI.

Prochaines étapes

Creuser les fonctionnalités/fonctions natives de Gomplate, notamment l’utilisation des datasources ;
Voir l’utilisation de Gomplate en remplacement de envsubst ;

Git - Trier les tags d'un repo utilisant du semantic versioning

Mon, 20 Sep 2021 23:10:00 +0200

Un rapide article aujourd’hui pour vous parler d’une découverte récente dans les fonctions de tri de Git et les tags basés sur le semantic versioning.

Par défaut, si vous lancez la commande git tag -l, Git va faire un tri alphabétique.

Cependant, ce tri donne des résultats déconcertant lorsque les tags utilisent une notation basée sur le semantic versioning.

git tag -l
v2.6.1
v2.6.10
v2.6.11
v2.6.12
v2.6.2
v2.6.3
v2.6.4
v2.6.5
v2.6.6
v2.6.7
v2.6.8
v2.6.9
v2.7.0

Noté ici la séquence v2.6.10, v2.6.11 et v2.6.12 qui s’intercale entre la version v2.6.1 et v2.6.2.

Afin de résoudre ce souci, il est possible d’utiliser la fonction de tri --sort avec l’attribut version dans Git.

git tag --sort=version:refname

Cela affichera les résultats triés de façon cohérente :

git tag --sort=version:refname
v2.6.1
v2.6.2
v2.6.3
v2.6.4
v2.6.5
v2.6.6
v2.6.7
v2.6.8
v2.6.9
v2.6.10
v2.6.11
v2.6.12
v2.7.0

Mettre à jour Buildx dans Docker CLI

Sat, 02 May 2020 14:29:42 +0200

Docker CLI, depuis la version 19.03 inclut le plugin buildx permettant d’étendre les fonctions de build de Docker en s’appuyant sur Buildkit.

Parmis les principaux points qu’apportent Buildkit on notera les suivants :

résolution en parallèle des dépendences
meilleure gestion du cache (import/export, résolution)
possibité de distribuer les charges de travail
exécution sans droits root

Et donc, comme indiqué plus haut, buildkit est maintenant inclut dans docker CLI. Problème, la version disponible et pré-paquagée n’est pas à jour des dernières évolutions.

Si vous souhaitez profiter des toutes dernières évolutions, il vous sera nécessaire de procéder à une mise à jour.

version de buildx

Ce tutoriel utilise la version 0.4.1 de buildx.
Pensez à vérifier le numéro de la dernière version avant de copier/coller les instructions.

Les étapes

Vérifier l’existance du dossier ~/.docker/cli-plugins. S’il n’existe pas, créez le

mkdir ~/.docker/cli-plugins

Télécharger la dernière version de buildx depuis la page de release Buildx sur Github ou directement via votre terminal

wget -O ~/.docker/cli-plugins/docker-buildx https://github.com/docker/buildx/releases/download/v0.4.1/buildx-v0.4.1.linux-amd64

Définir les droits d’éxécution sur le binaire : chmod +x ~/.docker/cli-plugins/docker-buildx

et voilà !

Il ne nous reste plus qu’à vérifier si la version de buildx est maintenant celle attendue

docker buildx version`

Si vous voulez que buildx deviennent le builder par défaut de Docker CLI

docker builx install

Démo

Azure-cli, activer l'auto-complétion sur Zsh

Tue, 26 Nov 2019 23:35:18 +0100

Azure-cli n’a pas d’auto-complétion activée sur Zsh et le framework Oh-My-Zsh n’a pas de plugin disponible en natif.

Cependant, Azure-cli est installé avec un script d’auto-complétion pour bash qui devrait se trouver dans le répertoire bash_completion.d.

Dans ma configuration, en utilisant Ubuntu 18.04, j’ai trouvé le script azure-cli dans un répertoire /etc/bash_completion.d/.

Maintenant nous avons juste besoin de charger le script autocomplete dans notre ~/.zshrc avec la ligne suivante :

source /etc/bash_completion.d/azure-cli

Sauvegardez et rechargez votre terminal. Fin.

Notes complémentaires

Si vous rencontrez une erreur au redémarrage, vous devrez peut-être ajouter cette ligne avant le chargement du script pour assurer la compatibilité croisée entre les scripts bash et zsh.

autoload -U +X bashcompinit && bashcompinit

En regardant les différents billets du blog, vous constaterez peut-être que le script s’appelle az, et non azure-cli.
D’après le répertoire que je l’ai trouvé, le script était chargé nativement si j’utilise le shell bash. Si vous utilisez bash et n’avez pas l’auto-complétion activée, vous devez probablement chercher le script azure-cli ou az puis le charger dans votre fichier ~/.bashrc.

Gitlab CI, After Script et Merge Request

Wed, 23 Oct 2019 09:52:49 +0200

Gitlab CI propose de nombreuses intégrations lorsque vous lancez vos tests (junit par exemple).

En complément, ou parfois à défaut d’avoir accès à la version entreprise de Gitlab, il peut être utile de voir le résultat d’une commande ou d’un export en commentaire de votre Merge Request.

Pour réaliser cela nous allons utiliser les options suivantes :

les variables d’environnement prédéfinies dans Gitlab CI
l’option only:merge_requests de Gitlab CI
la fonction after_script de Gitlab CI
l’API Gitlab pour les Merge Request
un jeton (token) Gitlab à générer en amont
curl
JQ

Avec ce process, nous pourrons ainsi avoir un retour dans notre Merge Request

Le script final

post:comment:on:merge-request:
  variables:
    FILE_EXPORT_PATH: "text-export.txt"
  before_script:
    - apk --no-cache add curl jq
  script:
    - echo "An awesome text to report" > text-export.txt
  after_script:
    - |
      if [ -f "text-export.txt" ]
      then
        printf "${CI_JOB_NAME} \n<pre>$(cat text-export.txt)\n</pre>\n" | \
        jq -R -c -s '{"body":.}' - | \
        curl -X POST "${CI_API_V4_URL}/projects/${CI_MERGE_REQUEST_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/notes" \
          --header "PRIVATE-TOKEN: ${GITLAB_PRIVATE_TOKEN}" \
          --header "Content-Type: application/json" \
          --data @-;
      fi
  only:
    refs:
      - merge_requests

Details

Préparation

Tout d’abord, nous devons nous assurer que notre image de base, une Alpine dans notre exemple, contient les outils curl et jq.

before_script:
    - apk --no-cache add curl jq

Le script

Au niveau de notre script, nous allons exporter la sortie dans un fichier qui sera ensuite exploité dans l’after_script

script:
    - echo "An awesome text to report" > ${FILE_EXPORT_PATH}

Nous allons nous assurer que le job n’est exécuté que lors d’une Merge Request, ce qui nous garantira d’avoir accès aux bonnes variables d’environnement.

only:
  refs:
    - merge_requests

After script

Enfin, notre after_script.

printf est utilisé ici pour aider à la mise en forme de notre texte, supprimer d’éventuelles contraintes de formatage…

On utilise la variable CI_JOB_NAME pour pouvoir directement voir dans le commentaire quel job à renvoyer l’information.

printf "${CI_JOB_NAME} \n<pre>$(cat text-export.txt)\n</pre>\n" | \

jq arrive ensuite pour formater le contenu avant sa transmission à l’API Gitlab.

jq -R -c -s '{"body":.}' - | \

Enfin, l’envoi à l’API Gitlab en utilisant les variables suivantes CI_API_V4_URL, CI_MERGE_REQUEST_PROJECT_ID, CI_MERGE_REQUEST_IID, GITLAB_PRIVATE_TOKEN.

La variable GITLAB_PRIVATE_TOKEN est la seule qui n’est pas “nativement” disponible. Il vous faudra la générer avec l’utilisateur qui postera le commentaire et la renseigner dans les variables CI/CD de votre projet.

curl -X POST "${CI_API_V4_URL}/projects/${CI_MERGE_REQUEST_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/notes" \
    --header "PRIVATE-TOKEN: ${GITLAB_PRIVATE_TOKEN}" \
    --header "Content-Type: application/json" \
    --data @-;

Quelques cas d’usage possibles

Terraform plan
Fuite de mots de passe / clés
Retours tests d’intrusions
Retours de tests de performance
…

Test de Ansible Molecule

Sat, 10 Aug 2019 00:00:00 +0000

Pour l’un de nos clients chez Clever Age, nous avons appuyer une grosse partie de notre provisioning de l’ensemble de nos environnements avec Ansible et nous utilisons un grand nombre de rôles créés par l’excellant Geerlingguy.

L’un de ces rôles est le rôle Ansible PHP.

Le rôle permet de confier à Ansible la gestion du fichier du pool php-fpm.

Malheureusement, il n’est pas possible de modifier certaines variables du fichier d’origine ou d’ajouter de nouvelles lignes simplement.

Objectifs

Nous voulons donc créer un nouveau rôle qui dépendra du rôle geerlingguy.php et viendra gérer de nouvelles variables, notamment :

pm pour pouvoir passer de dynamic à static
pm.max_requests

Le projet

Point de départ : Documentation de Molecule

Préparation

Installation de molecule

pip install --user molecule

Implémentation

Molecule permet de générer directement un nouveau rôle Ansible avec une préconfiguration des tests. Nous allons utiliser cette fonctionnalité pour créer notre rôle.

Générer un nouveau rôle Ansible avec Molecule

molecule init role --role-name newrole.php --verifier-name testinfra --driver-name docker

On définit ici le nom du rôle, l’outil de tests qui nous servira à vérifier le résultat du provisioning, verifier, et le pilote, driver, qui va exécuter recevoir l’éxécution des tests.

A noter : on définit ici testinfra et docker pour l’exemple, néanmoins ce sont les valeurs par défaut.

Une fois le rôle généré, vous obtenez la structure d’un rôle classique et un ensemble de dossiers et fichiers spécifique à Molecule :

.
├── defaults
│   └── main.yml
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── molecule
│   └── default
│       ├── Dockerfile.j2
│       ├── INSTALL.rst
│       ├── molecule.yml
│       ├── playbook.yml
│       └── tests
│           └── test_default.py
├── README.md
├── tasks
│   └── main.yml
└── vars
    └── main.yml

En regardant le fichier Install.rst, on se rend compte que pour faire fonctionner molecule avec Docker il faut ajouter un sous-module à notre système :

pip install 'molecule[docker]'

Si vous suivez une approche TDD, il est maintenant temps d’aller modifier les fichiers molecule.yaml et playbook.yaml pour y ajouter les éléments à provisionner.

Définir son playbook de tests

L’objectif du playbook est de tester le rôle courant et ses éventuels dépendances.

On va donc définir un playbook, dans le fichier playbook.yaml, avec nos variables et les rôles à appliquer

---
- name: Converge
  hosts: all
  become: yes

  vars:
    php_enable_webserver: false
    php_enable_php_fpm: true
    php_install_recommends: false
    php_fpm_pm_max_requests: 1000
    php_fpm_pm_type: "static"

  pre_tasks:
    - name: Update apt cache.
      apt: update_cache=true cache_valid_time=3600
      when: ansible_os_family == 'Debian'
      changed_when: false

  roles:
    - role: geerlingguy.php
    - role: newrole.php

Dans notre cas, on va tester l’installation du rôle geerlingguy.php suivi de notre nouveau role newrole.php et passer les 2 variables que l’on souhaite vérifier par la suite :

php_fpm_pm_max_requests: 1000
php_fpm_pm_type: "static"

Écrire des tests avec testinfra

Avant de lancer les tests, on va écrire un petit test avec testinfra, un module Pyhton pour tester ses configurations.

Dans le fichier newrole.php/molecule/default/tests/test_default.py, nous allons ajouter une nouvelle fonction

import os

import testinfra.utils.ansible_runner

testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
    os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('all')

def test_php_pool_file(host):
    f = host.file('/etc/php/7.0/fpm/pool.d/www.conf')

    # Check if www.conf file exists
    assert f.exists

    c = f.content

    # Check if our 2 variables exists with the right values
    assert b'pm = static' in c
    assert b'pm.max_requests = 1000' in c

Lancer les tests

La commande molecule test va lancer l’ensemble des étapes de tests (création, lint, provision, tests…).

Si l’on veut uniquement le provisioning, il est possible de lancer uniquement la commande molecule converge.

Si l’on veut tester manuellement le résultat du provisioning, molecule verify sera à lancer.

Les comandes essentielles

molecule test permet de lancer toutes les étapes
molecule converge permet de lancer le provisioning
molecule verify permet de lancer uniquement les tests
molecule login permet de se connecter dans le conteneur
molecule destroy pour supprimer le conteneur

Résumé

Les objectifs atteints :

Un nouveau rôle Ansible qui permet de surcharger les variables du fichier pool de fpm
Apprentissage des commandes principales de molecule
Découverte de testinfra
Un test, minimalistes, pour vérifier si les valeurs sont bien disponibles dans le fichier avec testinfra

Conclusion

Molecule permet de tester simplement dans divers contextes ses rôles Ansible. Sans garantir à 100% l’intégrité du résultat lors de l’application sur un autre environnement, il permet d’avoir un niveau de confiance bien plus élevé et de simplifier les tests de non régressions.

Prochaines étapes

Généraliser l’utilisation de molecule sur tous les nouveaux développements de rôle
Ajouter des tests sur les rôles existants
Creuser les options disponibles pour lancer des tests en mode matrice
Tester le provisioning d’un ensemble plus conséquent de rôles avec Molecule
Tester le framework de test goss en complément / remplacement de testinfra

Git - Tips & Tricks

Tue, 23 Apr 2019 14:44:54 +0200

Git est un outil très puissant et il propose de nombreuses fonctionnalités qui ne sont pas toujours connues ou simple à appréhender.

Vous trouverez ci-dessous quelques astuces pour vous aider au quotidien et ne plus avoir peur de faire une bêtise !

Visualiser son historique

Visualiser l’historique des logs de la branche courante

git log

Améliorer l’affichage de ses logs

git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short

que vous pouvez alias-er par exemple en git hist avec la commande suivante

git config --global alias.hist 'log --pretty=format:"%h %ad | %s%d [%an]" --graph --date'

ou en modifiant votre fichier de configuration ~/.gitconfig, section [alias]

[alias]
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short

Comparer 2 branches

git log <branch>..<branch>

pour plus de détails : Git - Comparer les commits de 2 branches Git

Vérifier / modifier ce que l’on commit

Découper ses modifications en plusieurs commits

git add -p

Vous pourrez avec cette commande ne sélectionner que les parties qui vous intéressent.

Faire un diff sur un nouveau fichier

git diff new_file.txt # Ne renvoi rien
git add --intent-to-add new_file.txt # ou git add -N
git diff new_file.txt # Renvoi le contenu du fichier

Voir le détail sur Stackoverflow

Commiter tous les fichiers modifiés

Si vous avez effectué un diff et que vous êtes certains que toutes les modifications sont à commiter, vous pouvez utiliser

git add --update

git add -u

Ajout interactif

La commande git add -i peut également être bien pratique, pour combiner plusieurs actions. Par exemple l’update complet d’un fichier, récupérer en mode patch certains éléments d’un autre fichier ou encore ajouter des fichiers jamais commités.

Ajout interactif de fichiers jamais commités

Lorsque vous avez des fichiers non trackés et que vous voulez les ajouter au repository, vous ne voulez pas forcément ajouter tout le répertoire.

Exemple :

git status
Sur la branche preview
Modifications qui seront validées :
Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)

	content/article/openshift/

On voit ici que le dossier content/article/openshift/ n’est pas présent dans le repository et doit donc être ajouté via git add.

Si nous faisons uniquement git add content/article/openshift/ alors tous les fichiers seront mis dans l’index.

Si le nombre de fichiers est limité, il sera rapide d’ajouter simplement le nom du fichier à la suite de la commande git add content/article/openshift/<my-file>.

Par contre, si vous avez plusieurs fichiers, alors la commande --interactive va grandement vous aider.

Etapes :

Lancer git add -i
Presser 4 pour afficher les fichiers non trackés
La liste affichée est numéroté.

Vous avez maintenant les options suivantes :

Soit saisir un numéro et presser entrée. Puis un autre numéro etc…
Si vous avez des plages de numéros, vous pouvez les déclarer via la syntaxe : <num1>-<num2>
Vous pouvez également utiliser le ; pour séparer 2 numéros : 1;2;3;4;12

Toutes ces options sont bien entendus combinables : 1-4;12

Corriger son dernier commit

Ajouter les modifications au commit précédent et vous proposer de modifier le message

git commit --amend

Ajouter les modifications au commit précédent sans modification du message de commit

git commit --amend --no-edit

Corriger un précédent commit

Version 1

git commit
git rebase -i <head>

Puis déplacer le dernier commit au niveau du commit dans lequel l’intégrer et définir le mot clé à fixup ou juste la lettre f.

Version 2

git commit --fixup <hash>

va automatiquement reprendre le nom du commit ciblé, préfixé par fixup!

Exemple :

* 61739a7 2019-04-25 | fixup! new commit (HEAD -> master) [Jean-Yves Gastaud]
* ccb6360 2019-04-23 | rename file [Jean-Yves Gastaud]
* 0dfc522 2019-04-23 | new commit [Jean-Yves Gastaud]
* 229fe83 2019-04-23 | new commit [Jean-Yves Gastaud]
* c1420d3 2019-04-23 | new commit [Jean-Yves Gastaud]
* cb893a3 2019-04-23 | new commit [Jean-Yves Gastaud]
* b95163d 2019-04-23 | Good commit [Jean-Yves Gastaud]

Il est ainsi possible de demander à Git de rebase l’historique dans le bon ordre automatiquement

git rebase -i --autosquash <hash>

Va proposer automatiquement la fusion des commits marqués en fixup avec son commit de référence.

pick b95163d Good commit
pick cb893a3 new commit
fixup 61739a7 fixup! new commit
pick c1420d3 new commit
pick 229fe83 new commit
pick 0dfc522 new commit
pick ccb6360 rename file

!! Attention aux conflits quand même !!

Faire un rebase en incluant le tout 1er commit

git rebase -i --root

Squash VS Fixup

Fixup

Comme vu ci-dessus, fixup va inclure un commit dans le commit précédent.

Le message du commit et la description du commit parent seront conservés.

Squash

Un squash est le regroupement d’un ou plusieurs commits dans un parent, de la même manière que fixup.

C’est une pratique couramment utilisé dans les projets Open Source afin de simplifier le tracking entre une Merge Request et un commit.

A la différence de fixup, squash va afficher l’éditeur de texte avec les messages et descriptions des n commits mergés et vous proposer de modifier la description pour correspondre au regroupement de vos commis.

Tout comme pour fixup, il est possible de définir directement un commit comme état “à squasher” :

git commit --squash <hash>

puis, comme pour fixup,

git rebase -i --autosquash <hash>

Modifier l’historique d’une branche

git rebase -i <hash>

Annuler un rebase en cours

Oula, qu’est ce qu’il se passe ici ?

Je vais plutôt annuler ça !

git rebase --abort

Valider une résolution de conflit dans un rebase

git add <file>
git rebase --continue

J’ajoute mon correctif de conflit et je continue le rebase !

Mon correctif sera inclu dans le commit qui vient d’être appliqué. C’est pour cela que je n’ai pas besoin de commité à nouveau.

Pas de changement lors du rebase ?

Parfois, un message indique que l’application du commit n’apporte pas de changement.

Le commit est donc déjà inclus dans une modification déjà appliqué au dépôt. Il peut être supprimé sans craintes.

git rebase --skip

Retrouver les changements effectuées sur une fonction

Avec git grep tu peux déjà avoir un certain niveau d’information (commit de la fonction, fichier dans laquelle elle est).

Si tu as un changement de nom par contre…

Exemple :

git grep -p csv_import_get_ftp_params_provider_2 $(git rev-list --all) renvoi

a79ed97f14eede3cdd98ae53ce3b990b58bbd351:sites/all/modules/custom/csv_import/csv_import_query.inc:function csv_import_get_ftp_params_provider_2() {
8b7ca76ca554accd397fcec1073776d60280521e:sites/all/modules/custom/csv_import/csv_import_query.inc:function csv_import_get_ftp_params_provider_2() {
118ffd0839985555dbaadd9edd9846ce9c18eb05:sites/all/modules/custom/csv_import/csv_import.module:function csv_import_get_ftp_params_provider_2() {
2b5196af0dddd28744acbf0ec015b6d59bddedee:sites/all/modules/custom/csv_import/csv_import.module:function csv_import_get_ftp_params_provider_2() {
d58b7662c6a8d47793fd79ec25030ee5c7cee4a6:sites/all/modules/custom/csv_import/csv_import.module:function csv_import_get_ftp_params_provider_2() {

Créer, partager et appliquer un patch

Créer un patch

`format-patch`

git format-patch <hash>..HEAD

va générer n fichiers (où n est égale au nombre de commits entre le hash et HEAD)

Si vous voulez regrouper les commits en 1 seul fichier

git format-patch -k --stdout <hash>..<hash> > my.patch

L’option -k permet de garder sujet/message du commit intact et ne pas avoir la mention [PATCH] insérer automatiquement.

Exemple : wk-patch n’a pas l’option -k

diff wk-patch.patch nok-patch.patch                
4c4
< Subject: fixup! new commit
---
> Subject: [PATCH 1/2] fixup! new commit
27c27
< Subject: change
---
> Subject: [PATCH 2/2] change

`diff`

Avec l’utilisation de la commande git diff vous pouvez également géréner un patch.

git diff <hash>..<hash> > my.patch

La différence avec format-patch est que l’on n’a pas de notions d’historique des commits et donc que :

toutes les modifications se retrouveront unfiées dans un seul fichier
on perd l’information sur l’auteur des commits

Partager un patch

!! peu de chance que vous ayez à l’utiliser mais toujours marrant de savoir que cela existe !!

git send-email --to="jygastaud <jygastaud@clever-age.com>" 0001-fixup-new-commit.patch

Sur Ubuntu/Debian, peut nécessiter l’installation d’un paquet spécifique : apt-get install git-email

Il faut aussi un serveur smtp dispo, soit en passer un en ligne de commande

Appliquer un patch

Si le patch a été créé avec format-patch

git am <my-patch-files>

Vous pouvez utiliser la commande apply

git apply <my-patch>

Supprimer un patch

git apply -R <my-patch>

Description d’une branche

Ajouter une description

git branch --edit-description

Voir la description

git config branch.master.description

git request-pull v1.0 origin master:v1.x -p
The following changes since commit 61739a74f55f6f08bfebbccfc00e5e2cbb9bda52:

  fixup! new commit (2019-04-25 17:51:22 +0200)

are available in the Git repository at:

  git@github.com:jygastaud/git-conferences.git v1.x

for you to fetch changes up to 967fbc53e959804b17acc90cec89bdafad2e63ce:

  change (2019-04-25 18:29:25 +0200)

----------------------------------------------------------------
(from the branch description for master local branch)

La branche de prod

----------------------------------------------------------------
Jean-Yves Gastaud (1):
      change

 README2.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/README2.md b/README2.md
index 504bc75..3a59441 100644
--- a/README2.md
+++ b/README2.md
@@ -12,3 +12,5 @@ Encore 1 ligne
 
 Derniere ligne ?
 
+A change
+

Gérer ses repositories distants

fetch + rebase VS pull (–rebase)

Gérer plusieurs remotes

Les hooks

Gérer et partager ses hooks simplement

tree gitconfig 
gitconfig
|-- .gitconfig
|-- hooks
|   |-- pre-commit
|   `-- prepare-commit-msg
`-- templates
    `-- .gitmessage

puis git config --local include.path ../gitconfig/.gitconfig

Debuger

git grep

Voir la section précédente

Savoir ce qui est déjà commité / pushé sur une autre branche

git bisect

git bisect start
git bisect good <hash>
git bisect bad
git bisect bad
git bisect reset

Si vous avez des tests automatisés et que vous avez une erreur sur ces tests, il est possible de lancer un git bisect pour exécuter automatiquement les tests

git bisect start
git bisect good <hash>
git bisect bad
git bisect run ./test.sh
git bisect reset

git reflog

L’historique de toutes les actions que vous avez pu effectuer sur votre repository local.

cc7ccc0 (HEAD -> squash, master) HEAD@{0}: rebase -i (finish): returning to refs/heads/squash
cc7ccc0 (HEAD -> squash, master) HEAD@{1}: rebase -i (start): checkout HEAD~5
cc7ccc0 (HEAD -> squash, master) HEAD@{2}: rebase -i (finish): returning to refs/heads/squash
cc7ccc0 (HEAD -> squash, master) HEAD@{3}: rebase -i (start): checkout HEAD~5
72f188e HEAD@{4}: commit: squash! vide2
74e13d7 HEAD@{5}: commit: vide3
7eb0740 HEAD@{6}: commit: vide2
2396775 HEAD@{7}: commit: vide
cc7ccc0 (HEAD -> squash, master) HEAD@{8}: checkout: moving from master to squash
cc7ccc0 (HEAD -> squash, master) HEAD@{9}: am: [PATCH 5/5] change

Comme vous pouvez le constater, chaque action contient un hash spécifique.

Avec ce hash, il vous ai possible de revenir revert simplement une action si nécessaire.

git worktree

git worktree permet de gérer plusieurs espaces de travail pour un même dépôt.

Un cas typique d’utilisation :

Je travaille sur une nouvelle fonctionnalité et j’ai des modifications en cours
Un ticket URGENT arrive et j’ai besoin de changer de branche pour faire une correction
Je commite mon travail en cours (au risque d’ajouter des choses non voulues) et je change de branche

STOP ! Utilisez maintenant worktree !

git worktree add <path> [<branch>]

avec cette commande, je vais créer un nouvel espace de travail dans un dossier différent et travailler dessus comme sur ma branche courante.

Une fois fini, le travail commité et poussé, il ne nous reste plus qu’à supprimer l’espace de travail :

git worktree prune

Configurer votre profil

Gérer plusieurs profils

Voir article Git - Gérer des profils distincts dans Git

Partager un repository

git bundle

Git bundle permet de partager une branche d’un dépôt avec tout son historique de commit, de commiter dessus et de réintégrer les modifications dans le dépôt d’origine.

Pratique lorsque vous devez bosser avec des équipes distantes qui ne peuvent pas avoir un vrai accès au dépôt initial.

git bundle create <repo.bundle> <branch or hash or tag>

puis partager le fichier repo.bundle.

Sur le poste de l’autre développeur, il est maintenant possible de cloner le dépôt

git clone -b <branch_name> <path/to/repo.bundle> <folder>

Le dev peut générer un nouveau bundle de diff à partager

git bundle create gitconf.bundle origin/master..master

puis vous pouvez réintégrer le fichier dans le repo d’origine avec les mêmes commandes que pour la mise à jour via un dépôt distant

Avec un commit merge

git pull ../testconf/gitconf.bundle master

Avec pull –rebase

git pull --rebase ../testconf/gitconf.bundle master

Si des modifications ont été faites sur le dépôt d’origine et qu’elles doivent être repartagée au développeur, il suffira de générer un diff avec le bundle précédent. Le développeur n’aura plus qu’à remplacer son fichier initial et faire un pull dessus.

GoHugo - Générer des déclinaisons d'images utilisables en page d'accueil

Thu, 11 Apr 2019 16:51:22 +0200

GoHugo, depuis la version 0.32, est capable de gérer des ressources dédiées à une page ainsi que de générer des déclinaisons d’images.

Cette fonctionnalité est notamment très pratique pour gérer automatiquement des déclinaisons responsives de ces images et les utiliser dans un template ou shortcode.

Cela fonctionne parfaitement lorsque l’on est dans un contenu.

Alors c’est quoi le soucis ?

Admettons que nous voulions utiliser des images responsives sur la page d’accueil de notre site.

La page d’accueil ne fait pas parti d’une section ou d’un bundle et n’a donc pas accès à des ressources
Les fichiers mis dans le répertoire static ne sont pas traités comme des ressources par Hugo

Il sera donc nécessaire de gérer “à la main”, la déclinaison de ces images et les inclure manuellement dans notre template.

Pour simplifier, nous avons donc l’aborescence suivante :

.
| content
| | _index.md
| layouts
| | index.html

Quoi ? Mais j’ai trop d’images à décliner et le contenu change souvent ?!

Pour arriver à automatiser le processus de génération, nous allons utiliser introduit en version 0.35 : les Headless Bundles.

Ce nouveau type de bundle permet de gérer du contenu qui ne produira pas une page à part entière lors du rendu fait par Hugo.

Il est donc pratique de s’en servir pour gérer des blocs, messages… qui sont ensuite injecter dans les pages.

En s’appuyant donc sur ce type de bundle et en le combinant avec la fonctionnalité de génération d’images, nous allons pouvoir obtenir automatiquement nos diverses déclinaisons d’images.

Nous allons suivre les quesques étapes suivantes.

Création d’un nouveau bundle `headless-img`

On aura donc maintenant l’arborescence de contenus suivante :

.
| content
| | _index.md
| | headless-img
| | | images
| | | | mon_image.png
| | | index.md

Le fichier headless-img/index.md contiendra

+++
headless = true
title = "homepage images"
+++

{{< imghp src="images/mon_image.png" alt="A nice image for our homepage" >}}

Nous avons donc créer ici une ressource headless qui va appeler un shortcode hugo nommé imghp et qui prend en paramètres un chemin et un texte alternatif.

Création du shortcode

Dans l’aborescence layouts/shortcodes nous allons créer un nouveau fichier nommé imghp.html qui contiendra la logique de génération de nos images et leur rendu.

{{ /* Le shortcode pour les images responsives de la HP */ }}

{{/* get file that matches the filename as specified as src="" in shortcode */}}
{{ $src := (.Site.GetPage "/headless-img").Resources.GetMatch (printf "*%s*" (.Get "src")) }}

{{/* set image sizes, these are hardcoded for now, x dictates that images are resized to this width */}}

{{ $tinyw := default "500x" }}
{{ $smallw := default "800x" }}
{{ $mediumw := default "1200x" }}
{{ $largew := default "1500x" }}

{{/* resize the src image to the given sizes */}}

{{ .Scratch.Set "tiny" ($src.Resize $tinyw) }}
{{ .Scratch.Set "small" ($src.Resize $smallw) }}
{{ .Scratch.Set "medium" ($src.Resize $mediumw) }}
{{ .Scratch.Set "large" ($src.Resize $largew) }}

{{/* add the processed images to the scratch */}}

{{ $tiny := .Scratch.Get "tiny" }}
{{ $small := .Scratch.Get "small" }}
{{ $medium := .Scratch.Get "medium" }}
{{ $large := .Scratch.Get "large" }}

{{/* only use images smaller than or equal to the src (original) image size, as Hugo will upscale small images */}}
{{/* set the sizes attribute to (min-width: 35em) 1200px, 100vw unless overridden in shortcode */}}

<img 
{{ with .Get "sizes" }}sizes='{{.}}'{{ else }}sizes="(min-width: 35em) 1200px, 100vw"{{ end }}
srcset='
{{ if ge $src.Width "500" }}
    {{ with $tiny.RelPermalink }}{{.}} 500w{{ end }}
{{ end }}
{{ if ge $src.Width "800" }}
    {{ with $small.RelPermalink }}, {{.}} 800w{{ end }}
{{ end }}
{{ if ge $src.Width "1200" }}
    {{ with $medium.RelPermalink }}, {{.}} 1200w{{ end }}
{{ end }}
{{ if ge $src.Width "1500" }}
    {{ with $large.RelPermalink }}, {{.}} 1500w {{ end }}
{{ end }}'
{{ if .Get $medium }}
    src="{{ $medium.RelPermalink }}" 
{{ else }}
    src="{{ $src.RelPermalink }}" 
{{ end }}
{{ with .Get "alt" }}alt='{{.}}'{{ end }}>

Ce template peut être retrouvé sur de nombreux sites comme exemple.

La principale différence avec les autres se situe dans cette ligne :
{{ $src := (.Site.GetPage "/headless-img").Resources.GetMatch (printf "*%s*" (.Get "src")) }}
qui nous permet de récupérer les ressources du bundle headless-img.

Lorsque ce shortcode est exécuté, il va donc chercher l’image définie dans le fichier headless-img/index.md et génère automatiquement les déclinaisons.

Et maintenant, j’affiche ça comment sur ma page d’accueil ?

Il ne nous reste plus qu’à appeler notre bundle dans notre template index.html.

Si vous n’avez qu’un uniquement 1 seul contenu index.md

{{ define "content" }}
  {{ /* Le rendu de la section headless. Assume */ }}
  {{ $headless := .Site.GetPage "/headless-img" }}
  {{ $headless.Content }}
{{ end }}

Si vous devez rendre plusieurs fichiers .md en se basant sur un nom. `img1`, `img2`… par l’exemple

{{ define "content" }}
  {{ $headless := .Site.GetPage "/headless-img" }}
  {{ $reusablePages := $headless.Resources.Match "img*" }}
  {{ range $reusablePages }}
    {{ .Content }}
  {{ end }}
{{ end }}

Et voilà, maintenant vos images sont bien rendues sur votre page d’accueil et leurs versions responsives sont également disponibles.

Drupal, Gitlab CI et Clever Cloud sont dans un bateau

Wed, 10 Apr 2019 15:15:36 +0200

Déployer un site Drupal 8 sur Clever Cloud avec Gitlab CI

Qu’est-ce que Clever Cloud

Clever Cloud est un hébergement PAAS (Platform As A Service).

Grands principes

A chaque déploiement de l’application, une nouvelle machine va être créée.
Le code disponible dans un repository Git fournit par Clever Cloud va être déployer sur la machine et si aucune erreur n’est détectée, l’ancienne machine et la nouvelle sont switchées.
Le stockage de données et le stockage permanent de fichiers sont assurés respectivement par l’add-on mysql et bucketFS.

Toutes les machines et services possèdent un identifiant unique et un alias.

Serveurs et services

2 environnements sont provisionnées.

PREPROD

type XS : 1GB de RAM, 1 CPU
Pas d’autoscalling
1 seule instance

Services

MySQL (la base de données)
- 10GB d’espace
2 FS Buckets
- 1 pour le répertoire public de Drupal
- 1 pour le repertoire privé de Drupal
- Assure la persistance des données / fichiers uploadés
- Pas de taille min / max

PROD

Identique à la PREPROD avec une machine un peu plus puissante : type S, 2GB de RAM, 2 CPUs

Configurations et variables d’environnement

Variables d’environnements

Afin d’accéder aux différents services associés depuis la VM, Clever Cloud fournit des variables d’environnement.

Les variables standards sur Clever Cloud et disponibles par environnement sont documentées au lien suivant :

Variables par instances

Les variables ci-dessous sont définies et modifiées pour chacune des instances.

Variables custom / customisables

CC_FS_BUCKET=/web/sites/default/files:bucket-xxxx-xxxx-xxxx-xxxx-xxxx-fsbucket.services.clever-cloud.com
CC_FS_BUCKET=/private/files:bucket-xxxx-xxxx-xxxx-xxxx-xxxx-fsbucket.services.clever-cloud.com

permet de définir quels répertoires doivent être stockés de façon permanente dans le FS BUCKETS.

CC_PRE_RUN_HOOK=composer.phar run-script drupal-update-all

Permet d’exécuter à la fin d’un déploiement les actions de migration de base de données / vidage de cache… Pour simplifier le process, on joue un script disponible dans le composer.json

CC_WEBROOT=/web

Permet de définir l’emplacement du fichier index.php/index.html pour l’affichage du site.

DRUPAL_SALT=xxxxxxx

Le SALT Drupal est obligatoire. Il sera nécessaire de le configurer également sur les instances de DEV/LOCAL en cas de redescente de base.

PHP_VERSION=7.2

Définie la version de PHP à utiliser

PORT=8080

Ne pas changer le port. Il est configuré par défaut sur 8080 pour le bon fonctionnement Clever Cloud.

GIT_TAG=CURRENT_VERSION

Cette variable est définie automatiquement par Gitlab CI.

Elle sert uniquement de repaire pour savoir quel est le dernier tag déployé

Variables liées aux services

BUCKET_HOST
MYSQL_ADDON_DB
MYSQL_ADDON_HOST
MYSQL_ADDON_PASSWORD
MYSQL_ADDON_PORT
MYSQL_ADDON_URI
MYSQL_ADDON_USER

Faire communiquer Drupal et les services Clever Cloud

Afin de pouvoir utiliser pleinement les services de Clever Cloud, les adaptations suivantes ont été faites sur Drupal.

Ajout au fichier default.settings.php d’une condition pour inclure un fichier de settings propre à Clever Cloud

if (getenv('APP_ID')) {
  include $app_root . '/' . $site_path . '/settings.clevercloud.php';
}

Commit du fichier settings.php (iso default.settings.php)
Création et commit du fichier settings.clevercloud.php qui ne s’inclue que si la variable APP_ID est disponible.

Sur Clever Cloud : APP_ID: the ID of the application. Each application has a unique identifier used to identify it in our system. This ID is the same than the one you can find in the information section of your application.

Modification de la partie scripts du fichier composer.json pour y ajouter des scripts d’installation et de mise à jour.

Extract du fichier composer.json

...
    "scripts": {
        ...
        "drupal-config-update": [
            "cd web && ../vendor/bin/drush cr",
            "cd web && ../vendor/bin/drush cim -y",
            "cd web && ../vendor/bin/drush csim -y",
            "cd web && ../vendor/bin/drush csim -y",
            "cd web && ../vendor/bin/drush locale:check",
            "cd web && ../vendor/bin/drush locale:update",
            "cd web && ../vendor/bin/drush cr"
        ],
        "drupal-db-update": [
            "cd web && ../vendor/bin/drush updb -y",
            "cd web && ../vendor/bin/drush entup -y"
        ],
        "drupal-monsite-default-install": [
            "cd web && ../vendor/bin/drush si monsite_profile --locale=en --account-name=admin --account-pass=admin -y",
            "cd web && ../vendor/bin/drush cset system.site uuid 28ece100-1664-4072-9a92-55a5a53192f3 -y",
            "@drupal-update-all"
        ],
        "drupal-theme-build": [
            "cd web/themes/custom/monsite && npm install && ./node_modules/.bin/gulp build -r"
        ],
        "drupal-update-all": [
            "@drupal-theme-build",
            "@drupal-db-update",
            "@drupal-config-update"
        ]
    },
...

Utiliser les outils PHP et Drupal avec Clever Cloud

Si besoin de lancer des commandes directement sur le serveur, il vous faudra passer par l’outil Clever Tools en ligne de commande.

La documentation d’installation

Connexion SSH

Clever Tools dispose d’une commande ssh.

Comme nous avons 2 VMs définies dans le .clever.json, il est nécessaire de préciser à cette commande l’environnement cible.

Connexion PREPROD : clever ssh mon-site-preprod
Connexion PROD : clever ssh mon-site-prod

Composer

Composer est disponible directement et globalement sur les machines via composer.phar.

Si vous avez besoin de lancer un composer install directement sur la machine, il vous faudra donc exécuter composer.phar install.

Drush, Drupal Console et autres binaires du projet

Drush et Drupal Console sont à déclarer en dépendance composer du projet.

Une fois le composer install exécuté, il est possible d’aller utiliser les binaires dans le dossier vendor/bin.

Exemple pour Drush depuis la racine de l’application : ./vendor/bin/drush MA_COMMANDE

Gitlab / Gitlab CI

Afin de simplifier la gestion et le déploiement de l’application, les actions suivantes ont été menées sur l’Intégration Continue (via Gitlab-ci).

Activation d’un runner Gitlab CI sur l’instance de QA
Activation de Gitlab CI dans le projet Drupal
Création d’une tâche de déploiement pour la PREPROD
- cette tâche se déclenche automatiquement que si des changements se produisent sur la branche release
- On force la mise à jour du code dans le dépôt Git de Clever Cloud à chaque déploiement.
Création d’une tâche de déploiement sur la PROD
- Cette tâche doit être déclenché manuellement et n’est proposée que lorsque d’un tag est poussé
Création de 2 jobs planifiés dans Gitlab
- Mise en sommeil de la VM de PREPROD à 19h
- Reveil de la VM de PREPROD à 8h
Commit du fichier .clever.json qui contient les infos pour accéder aux 2 machines.

L’ensemble des jobs/tâches sont définies dans le fichier .gitlab-ci.yml à la racine du repository Git.

Des variables d’environnement ont été définies dans le projet Gitlab pour être accessible par Gitlab CI :

APP_ID_PREPROD
APP_ID_PROD
APP_ALIAS_PREPROD
APP_ALIAS_PROD
APP_NAME_PREPROD
APP_NAME_PROD
CLEVER_SECRET
CLEVER_TOKEN

(Ré)Installation des environnements

2 jobs, à lancer manuellement sont disponibles dans Gitlab-ci.

install_preprod
install_prod

Ces 2 jobs réinstallent complètement le site (réinstallation du profil d’install)

install_preprod:
  stage: oneshot
  environment:
    name: preproduction
    url:  https://$APP_NAME_PREPROD.cleverapps.io
  when: manual
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - /release/
  except:
    - schedules
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-monsite-default-install" --alias $APP_ALIAS_PREPROD
    - ./clever deploy --alias $APP_ALIAS_PREPROD -f

install_prod:
  stage: oneshot
  environment:
    name: production
    url:  https://$APP_NAME_PROD.cleverapps.io
  when: manual
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - tags
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-monsite-default-install" --alias $APP_ALIAS_PROD
    - ./clever deploy --alias $APP_ALIAS_PROD -f

Le déploiement est géré par 3 nouveaux stages.
Le déploiement en prod, s’il est réussi, va déclencher le job update_info_prod et modifier la variable d’environnement GIT_TAG qui peut nous permettre de tracker simplement la dernière version déployée.

deploy_preprod:
  stage: deploy_preprod
  environment:
    name: preproduction
    url:  https://$APP_NAME_PREPROD.cleverapps.io
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - /release/
    - /clevercloud/
  except:
    - schedules
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/1.0.0/clever-tools-1.0.0_linux.tar.gz
    - tar -xvf clever-tools-1.0.0_linux.tar.gz --strip-components=1
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-update-all" --alias $APP_ALIAS_PREPROD -v
    - ./clever deploy --alias $APP_ALIAS_PREPROD -f -v

deploy_prod:
  stage: deploy_prod
  environment:
    name: production
    url:  https://$APP_NAME_PROD.cleverapps.io
  when: manual
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - tags
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-update-all" --alias $APP_ALIAS_PROD
    - ./clever deploy --alias $APP_ALIAS_PROD -f
  allow_failure: false

update_variable_prod:
  stage: update_info_prod
  environment:
    name: production
    url:  https://$APP_NAME_PROD.cleverapps.io
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - tags
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set GIT_TAG $CI_COMMIT_TAG --alias $APP_ALIAS_PROD
  when: on_success

Pour la PREPROD, nous avons également planifiés des jobs automatiques qui vont arrêter et démarrer la machine.
Ces 2 jobs sont définis via l’interface Gitlab et contiennent des variables dédiées (SLEEPING et WAKEUP)

good_night_preprod:
  stage: money
  only:
    variables:
      - $SLEEPING == "PREPROD"
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever stop --alias $APP_ALIAS_PREPROD

wakeup_preprod:
  stage: money
  only:
    variables:
      - $WAKEUP == "PREPROD"
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-update-all" --alias $APP_ALIAS_PREPROD
    - ./clever restart --alias $APP_ALIAS_PREPROD

Le fichier gitlab-ci.yml complet

image: debian:9-slim

variables:
  GIT_STRATEGY: clone

stages:
  - oneshot
  - deploy_preprod
  - deploy_prod
  - update_info_prod
  - money

deploy_preprod:
  stage: deploy_preprod
  environment:
    name: preproduction
    url:  https://$APP_NAME_PREPROD.cleverapps.io
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - /release/
    - /clevercloud/
  except:
    - schedules
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/1.0.0/clever-tools-1.0.0_linux.tar.gz
    - tar -xvf clever-tools-1.0.0_linux.tar.gz --strip-components=1
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-update-all" --alias $APP_ALIAS_PREPROD -v
    - ./clever deploy --alias $APP_ALIAS_PREPROD -f -v

deploy_prod:
  stage: deploy_prod
  environment:
    name: production
    url:  https://$APP_NAME_PROD.cleverapps.io
  when: manual
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - tags
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-update-all" --alias $APP_ALIAS_PROD
    - ./clever deploy --alias $APP_ALIAS_PROD -f
  allow_failure: false

update_variable_prod:
  stage: update_info_prod
  environment:
    name: production
    url:  https://$APP_NAME_PROD.cleverapps.io
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - tags
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set GIT_TAG $CI_COMMIT_TAG --alias $APP_ALIAS_PROD
  when: on_success

good_night_preprod:
  stage: money
  only:
    variables:
      - $SLEEPING == "PREPROD"
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever stop --alias $APP_ALIAS_PREPROD

wakeup_preprod:
  stage: money
  only:
    variables:
      - $WAKEUP == "PREPROD"
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-update-all" --alias $APP_ALIAS_PREPROD
    - ./clever restart --alias $APP_ALIAS_PREPROD

install_preprod:
  stage: oneshot
  environment:
    name: preproduction
    url:  https://$APP_NAME_PREPROD.cleverapps.io
  when: manual
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - /release/
  except:
    - schedules
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-monsite-default-install" --alias $APP_ALIAS_PREPROD
    - ./clever deploy --alias $APP_ALIAS_PREPROD -f

install_prod:
  stage: oneshot
  environment:
    name: production
    url:  https://$APP_NAME_PROD.cleverapps.io
  when: manual
  before_script:
    - apt-get update -yqq
    - apt-get install git curl -y
  only:
    - tags
  script:
    - curl -O https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
    - tar -xvf clever-tools-latest_linux.tar.gz --strip-components=1
    - ./clever login --token $CLEVER_TOKEN --secret $CLEVER_SECRET
    - ./clever env set CC_PRE_RUN_HOOK "composer.phar run-script drupal-monsite-default-install" --alias $APP_ALIAS_PROD
    - ./clever deploy --alias $APP_ALIAS_PROD -f

Gérer des profils distincts dans Git

Thu, 24 Jan 2019 00:02:55 +0100

Vous utilisez votre ordinateur pour travailler et, plus que jamais, il vous arrive sûrement d’utiliser Git (que feriez-vous sur cet article sinon ?).
Peut-être vous arrive-t-il aussi de travailler sur un projet personnel sur ce même ordinateur ?
Ou de contribuer à un projet Open-Source, toujours sur la même machine.

Vous avez probablement défini une identité (nom + mail) globale à votre machine et vous la surchargée pour chaque projet en fonction du contexte.

Parfait !

Et pourtant malgré ces précautions d’usage, qui n’a jamais commité dans un projet avec une mauvaise identité ? Parfois peut être vous en vous rendu compte tardivement et votre email personnel se retrouve maintenant ad vitam æternam dans les logs d’un projet.

Alors comment essayer de limiter le risque d’erreurs ?

Pourrait-on automatiser la sélection de la bonne identité pour nos projets ?

Et bien, la bonne nouvelle est que la réponse est OUI et que nous allons voir comment juste après.

.gitconfig et includes conditionnels grâce à IncludeIf

Prenons le fichier .gitconfig, généralement présent dans votre $HOME.

[user]
	name = Jean-Yves Gastaud
	email = mon.super@mail.com

[alias]
  amend = commit --amend
  st = status
  co = checkout

Ce fichier défini notre identité par défaut et nos aliases globaux.

Grâce à utilisation de la directive includeIf¹ dans notre fichier .gitconfig, nous pouvons maintenant ajouter des includes conditionnels liés, notamment à des répertoires.

[includeIf "gitdir:/workspace/work/"]
  path = ~/.gitconfig-work

[includeIf "gitdir:/workspace/opensource/"]
  path = ~/.gitconfig-opensource

[includeIf "gitdir:/workspace/perso/"]
  path = ~/.gitconfig-perso

Pour chaque includeIf défini, il ne nous reste plus qu’à créer le fichier correspondant au chemin que nous avons défini dans path.

Dans le fichier ~/.gitconfig-work, nous n’avons donc plus qu’à ajouter ou surcharger les configurations qui nous intéresse.

Exemple :

[user]
        email = my.work@mail.com

[core]
        editor = "code -w"

Dans ce fichier, on surcharge donc notre email et on ajoute un éditeur de code par défaut.

Maintenant, tout dossier sous le répertoire /workspace/work bénéficiera automatiquement du chargement des configuration fichier .gitconfig, surcharger ou compléter par celles du fichier .gitconfig-work.

Pour vérifier votre configuration, allez dans n’importe quel répertoire sous le répertoire ciblé, /workspace/work dans notre exemple et lancer la commande git config -l

Vous devriez voir la fusion de vos fichiers de configs.

user.name=Jean-Yves Gastaud
email = mon.super@mail.com
alias.amend=commit --amend
alias.st=status
alias.co=checkout
includeif.gitdir:/workspace/work/.path=~/.gitconfig-work
user.email=my.work@mail.com
core.editor=code -w
includeif.gitdir:/workspace/opensource/.path=~/.gitconfig-opensource
includeif.gitdir:/workspace/perso/.path=~/.gitconfig-perso
core.repositoryformatversion=0
core.filemode=true
…

Comme vous pouvez le constater, les 2 mails définis sont présents dans le listing.
Le dernier “parlant” ayant raison, c’est donc bien la valeur du fichier .gitconfig-work qui sera considéré lors du commit.

Vous remarquerez aussi que les 2 autres includes sont listés mais n’ajoutent pas de nouvelles variables / surcharges car leur condition d’application n’est pas remplie.

Cela nous laisse toujours la possibilité de surcharger, localement au repository, toutes configurations souhaitées, comme avant.

En quelques lignes et une gestion simple de vos répertoires de travail, il vous est donc possible de ne plus risquer de vous tromper dans le changement de vos identités.

Depuis la version 2.13 de Git (mai 2017). Documentation sur les Includes dans Git ↩︎

Mon workflow Git

Tue, 22 Jan 2019 08:51:19 +0100

Résumé du workflow Git, en ligne de commande, que j’applique de façon quasi-systématique à mes projets.

Dans cet article, je n’entrerai pas le détail de la gestion des Pull Request / Merge Request, des process de validation…

Ces éléments peuvent, bien entendu, modifier légèrement le process en fonction des contraintes que peuvent avoir les outils utilisés.

Branches principales

Au démarrage du projet, 3 branches principales et permanentes (qui seront toujours présentes) sont créées.

master : La branche de production
stage : La branche de préproduction. Contient toutes les branches de story / ticket validées, prêtes à passer en production.
dev : La branche de développement. Contient les branches à tester. Les branches sont mergées dessus au fil de l’eau.

A l’initialisation, toutes les branches auront donc le même point de départ.

Au fil des développements, ces 3 branches, en plus des branches de tickets, vont vivres à des rythmes différents.

Pour chaque ticket ou story, une nouvelle branche sera créée. Nous verrons plus loin l’origine de cette branche.

Cycle de vie des branches principales

dev

La branche de dev reçoit les merges des branches de ticket au fil de l’eau.

Les branches de ticket peuvent ne pas être rebase au moment du merge dans dev.

Il est possible de merger plusieurs fois une même branche de ticket dans dev.

stage

Tous les développements ou les créations de nouvelles branches partent de la branche stage.

merge de la branche t2 dans stage

Les merges sur stage doivent être obligatoirement fait en fast-forward.

Cela implique que chaque branche est rebase avant d’être mergée dans stage.

On garde ainsi un historique propre et linéaire.

merge avec fast-forward

En cas de merge de multiples branches, le travail peut être un peu fastidieux car il implique de passer sur chaque branche 1 par 1 pour la rebase avant de la merger.

master

On ne merge sur master que dans 2 cas :

lors d’un passage en production de fin de sprint ou de cycle de release. Le merge se fait uniquement via la branche stage.
en cas de hotfix. Via une branche de ticket.

merge de stage dans master

La branche master ne doit jamais être rebase ou “push forcée”.

Idéalement la branche master est protégée pour éviter les erreurs.

Réinitialisation des branches

Cas 1 : Merge dans master

A la suite d’un merge dans master, il conviendra,

de rebase stage

merge de stage dans master

de réinitialiser dev

réinitialisation de dev

Cas 2 : Divergences des branches

Avec le fait d’accepter n’importe quel merge sur dev, cette branche peut devenir rapidement très différentes, diverger, de la branche de production, master, voir de stage comme illustré ci-dessous :

Divergences importantes entre stage et dev

La branche dev sera donc régulièrement réinitialisée à partir de la branche stage, qui rappelons-le contient la dernière version des tickets validés et prêts à passer en production.

Concrètement, nous allons donc faire un git reset --hard origin/stage

Une fois la réinitialisation faite, il conviendra, si cela est nécessaire, de :

rebase les branches de développements à partir de stage
(Re)merger dans dev les branches qui auraient pu être en attente de tests.

Dans notre exemple, les branches t1-new-feat, t2-new-feat, t3-new-feat n’ont pas encore été mergées dans stage et seront donc rebase puis merge dans dev.

Historique git propre

Détaillons maintenant le workflow de gestion des tickets via Git.

Workflow ticket / story

Pour traiter un nouveau ticket, nous commençons d’abord par se mettre sur la branche stage et s’assurer qu’elle soit à jour de notre remote.

git checkout stage
git fetch
git reset --hard origin/stage

Nous avons ainsi une branche locale stage à jour de notre remote.

Si vous avez plusieurs remote, un git fetch --all est recommandé et il conviendra d’adapter le reset --hard.

Créons maintenant notre branche de ticket/story.

Pour cela, nous partons toujours de la branche stage.

git checkout -b [NUM-TICKET]-[short-description]

Si vous utilisez Gitlab pour vos tickets, il existe une fonction permettant de générer directement des branches à partir d’un ticket et ainsi d’avoir un nommage de vos branches cohérent.
Gitlab se base sur le titre du ticket pour nommer la branche.
Il conviendra d’avoir définie la branche stage comme branche par défaut dans Gitlab pour que le process expliqué ci-dessus s’applique automatiquement.

Une fois le ticket terminé, ou dans un état suffisamment stable pour être testé, nous pouvons merger la branche dans dev.

git checkout dev
git merge [NUM-TICKET]-[short-description]

Si le ticket n’est pas validé, vous pouvez merger à nouveau la branche de ticket dans dev.

Si le ticket est validé (tests automatisés validés, recette OK…), il est donc considéré comme pouvant potentiellement passer en production.

Dans le cadre d’un projet Agile avec des sprints ou d’une TMA avec lotissement de correctifs / évolutions, le ticket ne passera potentiellement pas en production.

Notre branche de ticket va donc être mergé dans la branche stage (notre préproduction).

Avant le merge, assurons nous de nouveau que stage est (toujours) à jour localement.

git checkout stage
# Mise à jour de stage si nécessaire; Voir plus haut
git merge --ff-only [NUM-TICKET]-[short-description]
git push origin stage

Si vous avez un message d’erreur, c’est probablement que la branche de ticket n’est pas à jour de stage.
Pensez à la rebase.

Si une autre branche de ticket (également validée) doit être mergée sur stage, nous devons donc rebase cette branche avant de pouvoir la merger.

git checkout [NUM-TICKET]-[short-description]
git rebase origin/stage

Et nous recommençons ensuite l’étape précédente.

Le code de stage peut ainsi être déployé en préproduction pour validation finale et globale.

Une fois le sprint fini ou la release complétée, nous allons finalement merger l’ensemble de la branche stage sur master.

git checkout master
# Mise à jour de la branche master locale si nécessaire
git merge origin/stage
* git push origin master

Ici, nous ne mergons pas la branche stage en fast-forward afin d’avoir une lecture simplifiée / rapide, grâce au commit de merge, de la dernière livraison.
Je vous laisse choisir si vous préférez cela ou non.

Enfin il est possible de tagger la branche master et publier notre release.

Une fois notre branche stage mergée dans master, nous pouvons réinitialiser nos branches stage et dev.

git checkout stage && git reset --hard origin/master

FAQ

Quelques questions / objections récurrentes reviennent régulièrement quand je présente ce workflow.

Pourquoi avoir une branche de preproduction / stage ?

C’est certainement le point qui fait le plus débat.

Il serait possible de se passer de la branche stage et merger directement nos tickets dans master.
master serait ainsi toujours la branche par défaut, le point d’origine de tous les nouveaux développements.

J’apprécie d’avoir une branche stage pour les raisons suivantes :

En cas de bug sur ma branche stage : parceque 2 développements ne sont finalement pas totalement compatibles entre eux ou qu’ils entrainent une régression, il est possible simplement d’ajouter un hotfix sur stage en s’assurant qu’il ira en prod,
En cas de non validation d’un ticket au sein d’une release : il est autorisé de ré-écrire l’historique de stage (même si cela doit être exceptionnel) sans grosses contraintes de communication avec l’ensembe de l’équipe.
Alors que la ré-écriture de l’historique de master n’est pas autorisée.

Avoir une branche stage offre donc une plus grande souplesse dans le workflow.

Rebase chaque branche de travail avant le merge sur `stage` peut être long et conflictuel

Cela n’est vrai que si vos branches de travail sont longues et trainent dans le temps.
Éventuellement si vous êtes un très grand nombre de développeurs à travailler sur de nouvelles branches simultanéement.

Il est donc nécessaire que l’équipe applique un minimum de rigeur sur la gestion des points suivants :

Rebase régulier des branches de travail depuis stage : les principaux conflits sont ainsi résolus directement par le développeur. Il peut s’assurer que son travail n’a pas été impacté.
Les branches de travail doivent avoir une durée de vie courte, quelques heures ou jours maximum.
Au plus les process de tests / non régressions sont automatisés, au plus vous serez en mesure de réduire ce délai.

Comment faire si une branche de travail dépend d’un autre développement en cours et non disponible sur `stage` ?

C’est une question sans réelle solution que l’on retrouvera dans tous workflows.

En fonction du niveau de dépendance, 2 cas peuvent s’appliquer :

Je ne dépend que d’un commit présent dans une autre branche : dans ce cas, je préconise de cherry-pick le commit dans la branche. On garde ainsi nos branches indépendantes.
Ma nouvelle feature vient compléter une autre branche : dans ce cas, ma suggestion est d’avoir une branche commune qui regroupera les 2 développements au moment du merge dans stage.

Notre nouvelle branche pourra donc, selon un choix à discuter avec les équipes,

soit partir de la branche du ticket dont je dépend et être rebase régulièrement avec les nouveaux développements de cette branche,
soit travailler directement sur la même branche.

Alors qu’en pensez-vous ? A vous maintenant de réagir et partager vos propres workflows¹.

graph git généré grace à Grawkit ↩︎

Git - Comparer les commits de 2 branches Git

Fri, 18 Jan 2019 09:50:14 +0100

Listing des différentes manières de comparer des branches dans Git.

TLDR;

Toute la magie réside dans l’utilisation des plages de révision et la syntaxe BRANCH_1..BRANCH_2

Connaitre les différences entre 2 branches

git diff [BRANCH_1]..[BRANCH_2]

retourne les différences de code entre 2 branches.

diff --git a/readme.txt b/readme.txt
index ac28f91..ae362e4 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1 @@
-Coucou
+Coucou2

On constate ici que dans le fichier readme.txt de a branche b, le mot Coucou a été remplacé par Coucou2.

Comparer les commits de 2 branches

Avec l’utilisation de diff, nous n’avons cependant pas la vision sur les commits qui ont créé le delta.

Pour ce type de comparaison, il est possible d’utiliser git log.

git log [BRANCH_1]..[BRANCH_2]

retourne uniquement les commits de branch_2 non présents dans branch_1

commit fc372ddecf5d98a8ba0d000a3c1ccf77a4f1237b (b)
Author: Jean-Yves Gastaud <jeanyves@gastaud.io>
Date:   Thu Jan 10 16:53:07 2019 +0100

    third commit

Pour avoir plus de détails sur le contenu du changement, il est possible d’utiliser toutes la panoplie d’options de la commande log.

L’utilisation des options --graph et --stat est particulièrement utile dans ce cas.

$ git log --oneline --decorate --graph --stat [BRANCH_1]..[BRANCH_2]

retourne

* fc372dd (b) 3eme commit
   readme.txt | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

Admettons maintenant que branch_1 est été rebase par rapport à master mais pas la branch_2, est-ce que mon delta de commit sera toujours cohérent ?

Prenons l’exemple suivant :

master contient

* 81faeea 2019-01-18 | a commit in master (master) [Jean-Yves Gastaud]
* 3be0b31 2019-01-10 | 1er commit [Jean-Yves Gastaud]

branch_1 a été rebase avec les données de master et contient 2 commits de plus.

* 5b3a95a 2019-01-18 | a commit (BRANCH_1) [Jean-Yves Gastaud]
* 19b7763 2019-01-10 | 2nd commit [Jean-Yves Gastaud]
* 81faeea 2019-01-18 | a commit in master (master) [Jean-Yves Gastaud]
* 3be0b31 2019-01-10 | 1er commit [Jean-Yves Gastaud]

branch_2 quant à elle n’est pas rebase et par toujours du 1er commit sur master.

* fc372dd 2019-01-10 | 3eme commit (BRANCH_2) [Jean-Yves Gastaud]
* 3be0b31 2019-01-10 | 1er commit [Jean-Yves Gastaud]

Retestons notre
git log --oneline --decorate --graph --stat [BRANCH_1]..[BRANCH_2]

* fc372dd (BRANCH_2) 3eme commit
   readme.txt | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

Super, nous voyons toujours notre commit non présent dans la branch_1 !

Si besoin de savoir quelles sont les commits de la branch_1 non présents dans branch_2, il est bien entendu possible d’inverser les arguments.

Ainsi git log --oneline --decorate --graph --stat [BRANCH_2]..[BRANCH_1] nous renverra

* 5b3a95a (BRANCH_1) a commit
|  readme.txt | 3 +--
|  1 file changed, 1 insertion(+), 2 deletions(-)
* 19b7763 2nd commit
|  readme.txt | 3 ++-
|  1 file changed, 2 insertions(+), 1 deletion(-)
* 81faeea (master) a commit in master
   readme.txt | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

Enfin, si notre branch_1 a été mergée dans master, nous pouvons toujours avoir les mêmes résultats.

Un git log --oneline --decorate --graph --stat [BRANCH_2]..master renverra bien l’ensemble de l’arbre de commits absents.

*   9eb6957 (HEAD -> master) Merge branch 'a'
|\
| * 5b3a95a (a) a commit
| |  readme.txt | 3 +--
| |  1 file changed, 1 insertion(+), 2 deletions(-)
| * 19b7763 2nd commit
|/
|    readme.txt | 3 ++-
|    1 file changed, 2 insertions(+), 1 deletion(-)
* 81faeea a commit in master
   readme.txt | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

Split JSON avec jq

Wed, 16 Jan 2019 16:36:46 +0100

Vous êtes vous déjà demandé comment découper un JSON en plusieurs “sous-“fichiers” ?

Si oui, cette ligne de commande est faite pour vous !

La seule dépendance ici est l’utilisation de l’outils jq.

Je vous encourage d’ailleurs à regarder cet outil très puissant sur la manipulation de JSON.

TL;DR

jq -c -M '.[]' myfile.json | \
while read line; do echo $line > $(echo $line | jq -r -c ".id").json; done

La commande va parser le fichier myfile.json et créer 1 fichier pour chaque id trouvé.

Cela fonctionne également en récupérant directement la sortie d’un service / API…

Exemple

echo '[{ "id": "16", "name": "produit 1" }, { "id": "17", "name": "produit 2" }, { "id": "18", "name": "produit 3" }, { "id": "19", "name": "produit 4" }]' | \
jq -c -M '.[]' | \
while read line; do \
echo $line > $(echo $line | jq -r -c ".id").json; \
done

Détails

Parsing du fichier JSON initial

jq -c -M '.[]' myfile.json

On va parser le fichier myfile.json et récupérér 1 ligne pour chaque entrée de 1er niveau.

Lire chaque ligne et créer le json associé

Tant qu’il y a des lignes, on boucle dessus.

while read line; do 
    ...
done

On renvoi ensuite la ligne et on utilise de nouveau jq pour récupérer l’id afin de nommer le fichier

echo $line > $(echo $line | jq -r -c ".id").json;

Fichier myfile.json

[
    {
        "id": "16",
        "name": "produit 1"
    },
    {
        "id": "17",
        "name": "produit 2"
    },
    {
        "id": "18",
        "name": "produit 3"
    },
    {
        "id": "19",
        "name": "produit 4"
    }
]

Options de la commande

-c compact instead of pretty-printed output; : nous permet d’avoir 1 ligne affiché par résultat
-M monochrome (don't colorize JSON); : purement esthétique pour ne pas risquer de polluer l’extraction
-r output raw strings, not JSON texts; : permet de supprimer le guillemet de sortir de notre ID.

Bonus : Ajouter des informations à un fichier JSON

$ jq '. += { "category": "ma categoie", "subcategory": "ma sous categorie" }' 19.json

jq va ajouter les entrées category et subcategory au fichier 19.json lors de l’affichage.

Il vous ai bien entendu ensuite possible de passer ce nouveau JSON à un nouveau fichier et l’enregistrer.

Makefile et parallélisation des jobs

Wed, 16 Jan 2019 15:18:58 +0100

PoC / Tests sur l’utilisation des jobs parallèles via Make et résultats constatés

https://www.gnu.org/software/make/manual/html_node/Parallel.html

Tests basiques

Makefile

all: test test2 test3 test4 test5 test6 test7

test:
	@sleep 2 && \
	echo "---> 1"

test2:
	@sleep 2 && \
	echo "---> 2"

test3: test test2 .FORCE
	@sleep 2 && \
	echo "---> 3"

test4:
	@sleep 2 && \
	echo "---> 4"

test5:
	@sleep 2 && \
	echo "---> 5"

test6:
	@sleep 2 && \
	echo "---> 6"

test7:
	@sleep 2 && \
	echo "---> 7"

.FORCE:

Tests sans parallélisation

On exécute 7 jobs à la suite.

Pour tester plus facilement nos résultats, chaque job dure environ 2 secondes.

$ date +'%Y%m%d%H%M%S' && make &&  date +'%Y%m%d%H%M%S'
20181213172307
---> 1
---> 2
---> 3
---> 4
---> 5
---> 6
---> 7
20181213172321

Comme prévu, nos jobs mettent 14 secondes à s’éxécuter.

Tests avec parallélisation

On lance maintenant la même commande en parallélisant les 7 jobs.

$ date  +'%Y%m%d%H%M%S' && make -j7 && date  +'%Y%m%d%H%M%S'
20181213172242
---> 1
---> 5
---> 7
---> 2
---> 6
---> 4
---> 3
20181213172246

On a ici un temps d’éxécution de 4 secondes correspondant au temps d’éxécution du test3 qui est obligé d’attendre l’éxéution de test1 et test2.

Soucis : Les jobs s’exécutent dans un ordre aléatoire.

Job Parallèles indépendants

Maintenant que nous avons vu comment fonctionne les jobs parallèle avec Make, comment gérer l’éxécution de plusieurs étapes ayant des dépendances de façon optimisée ?

Dans notre exemple, nous allons simuler 2 étapes :

Le clone de 2 repositories Git
Le lancement d’une commande composer

Makefile

steps: ## les 2 étapes, sans parallélisation
	$(MAKE) step1
	$(MAKE) step2

steps_j: ## les 2 étapes, avec parallélisation
	$(MAKE) step1 -j2
	$(MAKE) step2 -j2

step1: clone_toto clone_tata

clone_toto:
	@sleep 2 && \
	echo "git clone toto"

clone_tata:
	@sleep 2 && \
	echo "git clone tata"

step2: composer_toto composer_tata

composer_toto:
	@sleep 2 && \
	echo "composer toto"

composer_tata:
	@sleep 2 && \
	echo "composer tata"

Tests sans parallélisation

On lance notre test de référence

$ date +'%Y%m%d%H%M%S' && make steps &&  date +'%Y%m%d%H%M%S'
20181213173756
make step1
make[1] : on entre dans le répertoire « /var/www/make-parallel »
git clone toto
git clone tata
make[1] : on quitte le répertoire « /var/www/make-parallel »
make step2
make[1] : on entre dans le répertoire « /var/www/make-parallel »
composer toto
composer tata
make[1] : on quitte le répertoire « /var/www/make-parallel »
20181213173804

Ce test met 48 secondes à s’éxécuter.

Make semble particulièrement lent dans les appels récursifs à lui même.
Je n’ai pas creusé pourquoi.

Le même test en adaptant steps comme suit nous fait revenir au timing initialement prévu (8 secondes)

steps2: step1 step2

Tests avec parallélisation

En appliquant les capacités de paralélisation de Make, on peut donc maintenant assurer un ordre d’éxécution sur les jobs et lancer en même ceux indépendants.

$ date +'%Y%m%d%H%M%S' && make steps_j &&  date +'%Y%m%d%H%M%S'
20181213173803
make step1 -j2
make[1] : on entre dans le répertoire « /var/www/make-parallel »
git clone toto
git clone tata
make[1] : on quitte le répertoire « /var/www/make-parallel »
make step2 -j2
make[1] : on entre dans le répertoire « /var/www/make-parallel »
composer tata
composer toto
make[1] : on quitte le répertoire « /var/www/make-parallel »
20181213173807

On obtient une exécution de seulement 4 secondes !

Notre Makefile de tests complet

all: test test2 test3 test4 test5 test6 test7

test:
	@sleep 2 && \
	echo "---> 1"

test2:
	@sleep 2 && \
	echo "---> 2"

test3: test test2 .FORCE
	@sleep 2 && \
	echo "---> 3"

test4:
	@sleep 2 && \
	echo "---> 4"

test5:
	@sleep 2 && \
	echo "---> 5"

test6:
	@sleep 2 && \
	echo "---> 6"

test7:
	@sleep 2 && \
	echo "---> 7"

.FORCE:

steps:
	$(MAKE) step1
	$(MAKE) step2

steps_j:
	$(MAKE) step1 -j2
	$(MAKE) step2 -j2

step1: clone_toto clone_tata

clone_toto:
	@sleep 2 && \
	echo "git clone toto"

clone_tata:
	@sleep 2 && \
	echo "git clone tata"

step2: composer_toto composer_tata

composer_toto:
	@sleep 2 && \
	echo "composer toto"

composer_tata:
	@sleep 2 && \
	echo "composer tata"

Kubernetes a gagné la bataille des orchestrateurs

Thu, 05 Jul 2018 00:00:00 +0000

L’arrivée il y a quelques années de solutions permettant de simplifier la création et gestion de conteneurs, telles que Docker ou rkt, combinées aux approches micro-services et leurs popularités croissantes ont entraîné rapidement le besoin de solutions dites d’orchestration de conteneurs.

De nombreuses solutions d’orchestration ont vu le jour et se sont retrouvées disponibles en Open-Source.
Apache Mesos Marathon, Docker Swarm, Kubernetes ou encore OpenStack Magnum permettent toutes de traiter ces problématiques.

Il y a encore 2 ou 3 ans, les communautés Mesos et Docker avait fait de gros efforts pour rendre Mesos capable d’orchestrer des Docker.

Pourtant, cela n’empêcha pas Docker inc. de lancer sa propre solution, Docker Swarm, pour traiter ces aspects. Avec une volonté affichée d’être une solution d’orchestration plus intégrée à Docker, plus simple à mettre en place tout en assumant une gestion moines “fines” des ressources que Mesos.

Chacun a sa place, pour son besoin. Pas de vraie compétition entre les 2.

Mesos (via Marathon) semblait avoir pris de l’avance sur ces concurrents. En milieu d’année 2017, une bascule a commencé à se produire vers Kubernetes, utilisé chez Google depuis plus de 10 ans.

Alors pourquoi peut-on penser aujourd’hui que Kubernetes a gagné cette bataille et devient, un peu au même titre que Docker pour les conteneurs, le standard de l’industrie ?

Des signes qui ne trompent pas

Une croissance très rapide

Kubernetes est actuellement le projet le plus actif sur Github.
Les plateformes comme OpenShift ou CoreOS intègrent Kubernetes.
Le CNCF (Cloud Native Computing Foundation) en a fait le 1er projet Graduated, son rang le plus haut.
L’écosystème autours de Kubernetes s’étoffe très vite pour plus d’intégrations autours des systèmes, du monitoring, la sécurité, le déploiement continue…

Le Cloud public l’a adopté

Toutes les principales plateformes Cloud proposent Kubernetes en tant services :

Google Cloud Platform avec GKE (Google Kubernetes Engine)
Amazon Web Services avec EKS (Amazon Elastic Container Service for Kubernetes)
Azure avec AKS (Azure Kubernetes Service)
Digital Ocean propose une beta privée

Docker (for mac) intègre nativement Kubernetes

Docker a annoncé l’année dernière intégrée directement Kubernetes dans son application Docker for mac et propose maintenant le choix entre Swarm et Kubernetes.

Conclusion

Faut-il donc oublier vraiment toutes les autres solutions et ne faire plus que Kubernetes ?

Pour des problématiques d’orchestration combinant des applications non conteneurisées et/ou des conteneurs, alors une solution comme Mesos pourra vous être d’une grande aide.

Pour des problématiques d’orchestration dédiés uniquement aux conteneurs, sur une petite volumétrie de serveurs et conteneurs, une solution comme Docker Swarm sera certainement un bon tremplin, plus abordable.

Enfin, si vous avez besoin d’une solution fiable, robuste, scalable et pérenne, alors la balance tend clairement vers Kubernetes.

Drupal Behat afterFeature

Fri, 02 Sep 2016 17:12:10 +0200

Snippet permettant d’éxécuter des actions à la fin de l’éxécution d’une feature Behat.

/**
 * Defines application features from the specific context.
 */
class FeatureContext extends RawDrupalContext implements SnippetAcceptingContext {

  /**
   * That function will be executed after the end of the feature.
   *
   * @AfterFeature
   */
  public static function cleanupSomethingAfterFeatureExcution() {
    // Do something.
  }
}

Ressources

Obtenir l'url d'une page gérée via page_manager

Tue, 09 Aug 2016 14:48:18 +0200

Ci-dessous une technique pour récupérer l’url définie dans une page gérée via le module page_manager (inclus dans Ctools).

// Load ctools plugins.
ctools_include('page', 'page_manager', 'plugins/tasks');

// Load path "my-page" page.
$path = page_manager_page_load('my-page')->path;

Drupal 8 - Suppression de configurations à la désinstallation du module

Mon, 02 May 2016 15:21:25 +0200

Lors de l’implémentation d’un module, il va vous arriver de créer des configurations lors de l’installation.

Il est nécessaire de penser à les supprimer à la désinstallation.

Pour cela, il vous suffit d’utiliser le hook_uninstall dans le fichier .install de votre module, comme cela pouvait être fait sur Drupal 7.

Exemple avec une configuration du type migration nommée communique:

/**
 * Implements hook_uninstall().
 */
function migrate_communique_uninstall() {
    \Drupal::entityTypeManager()->getStorage('migration')->load('communique')->delete();
}

Import de fichier XML sous Drupal 8 - Traitements spécifiques sur la source

Mon, 02 May 2016 10:13:54 +0200

Dans l’article précédent, Réaliser un import de fichier XML sous Drupal 8, nous avons vu comment importer un fichier XML via Migrate. La configuration était simple et nous avons pu faire l’ensemble du mapping sans manipuler les données du fichier XML.

Nous allons étendre notre exemple précédent pour importer une date.
Cependant cette date n’a pas un format de date standard et n’est pas valide pour être importée dans Drupal directement.

Mise à jour du contexte

Fichier XML à importer

<?xml version="1.0" encoding="utf-8"?>
<flux-communiques>
    <communique>
        <id-communique>1</id-communique>
        <titre>Titre de l'article 1</titre>
        <date-diffusion>2016-02-05 16:07:00</date-diffusion>
        <corps><![CDATA[<div style="color: red">Un texte bleu</div>]]></corps>
        <pj1>http://example.com/monfichier.pdf</pj1>
    </communique>
    <communique>
        <id-communique>2</id-communique>
        <titre>Titre de l'article 2</titre>
        <date-diffusion>2016-01-14 16:24:00</date-diffusion>
        <corps><![CDATA[<div style="color: red">Un texte rouge</div>]]>
        </corps>
        <pj1>http://example.com/monfichier2.pdf</pj1>
    </communique>
</flux-communiques>

La champ date-diffusion n’est pas valide et nous allons avoir besoin d’ajouter un T entre la date et l’heure pour obtenir le format suivant : 2016-02-05T16:07:00

Type de contenus

Nous possédons un type de contenus, nommé Communique avec les champs suivants :

Label	Nom machine
Titre	title
Corps	body
Date de diffusion	field_communique_date
Pièce jointe	field_communique_attachment
Id du communiqué	field_communique_id

Modifications du module d’import

Nouveau mapping des champs source

Dans la partie source, nous allons ajouter une entrée pour mapper la date de diffusion.

source:
  #...
  fields:
    #...
    -
      name: date_diffusion
      label: Date Diffusion
      selector: date-diffusion
  #...

Nouveau mapping des champs Drupal

process:
  #...
  field_press_release_date: date_diffusion
  #...

Si vous lancez un drush migrate-fields-source vous devriez voir le nouveau champ apparaitre

$drush mfs communique
ID              id_communique  
Titre           titre          
Corps           corps          
Date Diffusion  date_diffusion
Lien            pj1

Modification de la class Source

Comme indiqué précédemment, il va maintenant nous falloir altérer la valeur de la date de diffusion pour qu’elle est un format interprétable par Drupal et ainsi que l’import de ce champ se réalise correctement.

Pour cela nous allons devoir modifier le comportement du plugin de la source (Url.php dans notre) et utiliser, comme sur Drupal 7, la méthode prepareRow().

Nous allons donc créer une nouvelle class nommée Communique.php dans ./src/Plugin/migrate/source/Communique.php
On obtient l’arborescence de module suivante :

.
├── config
│   └── install
│       └── migrate_plus.migration.communique.yml
├── migrate_press_release.info.yml
└── src
    └── Plugin
        ├── migrate
        │   └── source
        │       └── Communique.php

Notre nouvelle class Communique.php :

<?php

namespace Drupal\migrate_communique\Plugin\migrate\source;

use Drupal\migrate\Row;
use Drupal\migrate_plus\Plugin\migrate\source\Url;

/**
 * Source plugin for communique content.
 *
 * @MigrateSource(
 *   id = "communique"
 * )
 */

class Communique extends Url {

    /**
     * {@inheritdoc}
     */
    public function prepareRow(Row $row) {
        // Alter XML provided date.
        $row->setSourceProperty('date_diffusion', $this->processDateDiffusion($row->getSource()['date_diffusion']));
        return parent::prepareRow($row);
    }

    /**
     * Format Date from XML to be compliant with DateTime format.
     *
     * @param $element
     * @return string
     */
    protected function processDateDiffusion($element) {

        $exploded = explode(' ', (string) $element);
        $data = implode('T', $exploded);

        return $data;
    }
}

Nous avons donc ici une class qui étant la class Url et prépare le format de la date obtenue dans le champ date_diffusion pour correspondre à ce qu’attend Drupal.
L’utilisation de $row->setSourceProperty() permet de (re)définir la valeur de la date de diffusion.

Il ne nous reste plus qu’à préciser à notre migration de prendre en compte cette source en remplacement de la source url initialement définie.

Pour cela, nous allons modifier notre fichier migrate_plus.migration.communique.yml pour lui renseigner l’id de notre source : communique

source:
  # L'identifiant de notre source custom.
  plugin: communique
  #...

Afin que les changements de configuration soient pris en compte, il vous faudra désinstaller le module, supprimer la config déjà enregistrée et réinstaller le module. Voir l’article Drupal 8 - Suppression de configurations à la désinstallation du module

Une fois les modifications effectuées, il ne vous reste plus qu’à relancer votre migration.

Réaliser un import de fichier XML sous Drupal 8

Mon, 02 May 2016 10:13:54 +0200

Dans cette article nous allons voir comment réaliser un import de contenu XML dans Drupal 8 à l’aide des modules migrate, migrate_plus et migrate_source_xml.

Récupération des modules et installation

migrate est disponible dans le coeur de Drupal 8. Cependant il ne contient à ce jour que la possibilité de migrer des contenus en provenance d’une base SQL.
migrate_plus est un module contribué qui permet notamment d’obtenir la possibilité de migrer des contenus à partir d’une URL.

drush dl migrate_plus --dev

migrate_source_xml permet d’avoir une class de migration gérant des fichiers XML.

# depuis le dossier ./modules/[contrib]
git clone --branch refactor https://git.drupal.org/project/migrate_source_xml.git

Contexte

Fichier XML à importer

<?xml version="1.0" encoding="utf-8"?>
<flux-communiques>
    <communique>
        <id-communique>1</id-communique>
        <titre>Titre de l'article 1</titre>
        <corps><![CDATA[<div style="color: red">Un texte bleu</div>]]></corps>
        <pj1>http://example.com/monfichier.pdf</pj1>
    </communique>
    <communique>
        <id-communique>2</id-communique>
        <titre>Titre de l'article 2</titre>
        <date-diffusion>2016-01-14 16:24:00</date-diffusion>
        <corps><![CDATA[<div style="color: red">Un texte rouge</div>]]>
        </corps>
        <pj1>http://example.com/monfichier2.pdf</pj1>
    </communique>
</flux-communiques>

Type de contenus

Nous possédons un type de contenus, nommé Communique avec les champs suivants :

Label	Nom machine
Titre	title
Corps	body
Pièce jointe	field_communique_attachment
Id du communiqué	field_communique_id

Création du module d’import

Création du module migrate_communique

Nous allons nommer notre module migrate_communique et commencer par créer le dossier du même nom dans le répertoire modules à la racine de Drupal.

./modules
├── migrate_communique
└── README.txt

et définir le fichier migrate_communique.info.yml

type: module
name: Migrate Communiqué
description: 'Migration des communiqués.'
package: Migration
core: 8.x
dependencies:
  - migrate_plus
  - migrate_source_xml

On notera ici les dépendances aux modules migrate_plus et migrate_source_xml.

Définition du mapping entre le XML et le type de contenus

Nous allons créer un fichier de configuration nommé migrate_plus.migration.communique.yml dans le dossier config/install à partir de la racine du module.

.
├── config
│   └── install
│       └── migrate_plus.migration.pressrelease.yml
├── migrate_communique.info.yml

La configuration contenue dans ce fichier sera initialisée à l’installation du module.

Contenu du fichier migrate_plus.migration.communique.yml

Contenu intégral du fichier

Nous détaillerons juste après le contenu de ce fichier

# Configuration de la migration des communiqués.
id: communique
label: Communique
migration_group: Communique
migration_dependencies: {}

source:
  plugin: url
  data_fetcher_plugin: http
  data_parser_plugin: xml
  urls: http://exemple/monfichier.xml
  item_selector: /flux-communiques/communique
  fields:
    -
      # Nom machine utilisé pour le mapping lors du processing.
      name: id_communique
      # Label qui sera affiché dans l'UI.
      label: ID
      # Nom du champ dans le XML.
      selector: id-communique
    -
      name: titre
      label: Titre
      selector: titre
    -
      name: corps
      label: Corps
      selector: corps
    -
      name: pj1
      label: Lien
      selector: pj1

  ids:
    id_communique:
      type: string

destination:
  plugin: entity:node

process:
  type:
    plugin: default_value
    default_value: communique

  title: titre
  field_communique_id: id_communique
  'field_communique_body/value': corps
  'field_communique_body/format':
      plugin: default_value
      default_value: full_html
  field_communique_attachment: pj1

  sticky:
    plugin: default_value
    default_value: 0

  uid:
    plugin: default_value
    default_value: 1

Configuration générale

id: communique
label: Communique
migration_group: Communique
migration_dependencies: {}

Mapping de la source

source:
  plugin: url
  data_fetcher_plugin: http
  data_parser_plugin: xml

plugin permet de définir le nom du plugin qui va servir de base pour la parsing de la source.
Ici le plugin url est fourni par le module migrate_plus dans la class Url.php (./modules/contrib/migrate_plus/src/Plugin/migrate/source/Url.php)

Dans cette class, on retrouve notamment l’annotation suivante qui nous permet d’obtenir l’id du plugin :

/**
 * Source plugin for retrieving data via URLs.
 *
 * @MigrateSource(
 *   id = "url"
 * )
 */

data_fetcher_plugin : plugin implémenté dans migrate_plus pour permettre de récupérer un fichier depuis une URL (./modules/contrib/migrate_plus/src/Plugin/migrate_plus/data_fetcher/Http.php)

/**
 * Retrieve data over an HTTP connection for migration.
 *
 * @DataFetcher(
 *   id = "http",
 *   title = @Translation("HTTP")
 * )
 */

data_parser_plugin : plugin implémenté par migrate_source_xml (./modules/contrib/migrate_source_xml/src/Plugin/migrate_plus/data_parser/Xml.php)

/**
 * Obtain XML data for migration.
 *
 * @DataParser(
 *   id = "xml",
 *   title = @Translation("XML")
 * )
 */

urls : une liste d’urls auxquelles récupérer le fichier XML.

  urls: http://exemple/monfichier.xml

item_selector : permet de définir l’emplacement des items qui seront mappés et parsés (au format XPath)

  item_selector: /flux-communiques/communique

fields : permet de définir le mapping entre les champs XML et la class de migration

On va ici définir pour chaque champs :

un nom machine - qui sera réutiliser plus tard lors du processing du champ
un label (optionnel)
un sélecteur - le nom du champ dans le XML

  fields:
    -
      # Nom machine utilisé pour le mapping lors du processing.
      name: id_communique
      # Label qui sera affiché dans l'UI.
      label: ID
      # Nom du champ dans le XML.
      selector: id-communique
    -
      name: titre
      label: Titre
      selector: titre
    -
      name: corps
      label: Corps
      selector: corps
    -
      name: pj1
      label: Lien
      selector: pj1

ids : permet de définir l’identifiant unique dans le flux pour gérer les nouveaux imports et mises à jour

  ids:
    id_communique:
      type: string

Destination de la migration

destination:
  plugin: entity:node

On définie ici une migration vers une entitité de type node. On peut tout à fait envisager également de migrer vers d’autres entités comme les utilisateurs ou .

# Exemple pour l'entité User.
destination:
  plugin: entity:user

Mapping avec les champs Drupal

La partie process du yaml permet de définir le type de contenus dans lequel importer les données.

process:
  type:
    plugin: default_value
    default_value: communique

Le type est ici forcé à Communique. Tous les contenus créés auront seront donc des communiqués.
Le plugin default_value permet de définir la valeur par défaut que prendra un champ.
On réutilise ce plugin plus bas pour définir la valeur du champ Sticky et l’identifiant de l’utilisateur (uid)

sticky:
  plugin: default_value
  default_value: 0

uid:
  plugin: default_value
  default_value: 1

Nous retrouvons ensuite le mapping des champs à proprement parler.

  title: titre
  field_communique_id: id_communique

Il s’écrit sous la forme :

  nom_machine_champ_drupal: nom_machine_source_yaml

Enfin on retrouvera une notation un peu particulière pour les champs composés tels que le champ body qui attend une valeur complète, un format et potentiellement un résumé.

  'field_communique_body/value': corps
  'field_communique_body/format':
      plugin: default_value
      default_value: full_html

Comme vous l’avez sûrement remarqué, ces champs s’écrivent sous la forme 'nom_champ/propriété'.
Il est important de ne pas omettre les guillemets simples autour du nom du champ.

Lancer la migration avec Drush

Il est possible, comme sur Drupal 7 de lancer les migrations via Drush. Pour cela, il va cependant nous falloir installer un module complémentaire : migrate_tools.

Un simple drush dl migrate_tools --dev et drush en migrate_tools devrait suffire.

Ce module permet de faire le pont entre drush et migrate, qui rappelons-le est maintenant inclus directement dans le coeur de Drupal.

Une fois le module installé, on va avoir aux habituelles commandes drush migrate

drush --filter=migrate_tools
All commands in migrate_tools: (migrate_tools)
 migrate-fields-sourc  List the fields available for mapping in a source.
 e (mfs)                                                                  
 migrate-import (mi)   Perform one or more migration processes.           
 migrate-messages      View any messages associated with a migration.     
 (mmsg)                                                                   
 migrate-reset-status  Reset a active migration's status to idle.         
 (mrs)                                                                    
 migrate-rollback      Rollback one or more migrations.                   
 (mr)                                                                     
 migrate-status (ms)   List all migrations with current status.           
 migrate-stop (mst)    Stop an active migration operation.

Vérification du mapping des champs

drush mfs communique
ID              id_communique  
Titre           titre          
Corps           corps          
Lien            pj1

On retrouve bien ici les champs mappés dans la partie source.

Status des imports

drush ms communique
 Group: Communique  Status  Total  Imported  Unprocessed  Last imported       
 communique         Idle    2      0         0

Lancer la migration

drush mi communique --update
Processed 2 items (2 created, 0 updated, 0 failed, 0 ignored) - done with 'communique'          

drush mi communique --update
Processed 2 items (0 created, 2 updated, 0 failed, 0 ignored) - done with 'communique'

Voilà ! Vos noeuds ont été créés et sont maintenant visibles dans le back-office Drupal.

Utiliser Tmux et Tmuxinator pour gérer vos confs projets

Wed, 27 Apr 2016 19:00:00 +0200

Pré-requis

Avoir installé sur vos machines

Votre nouveau projet en 3 étapes

tmuxinator new [project_name] : Cette commande va générer un fichier YAML avec la configuration par défaut
Editer le fichier généré : ~/.tmuxinator/[project_name].yml (voir exemple ci-dessous)
Lancer mux [project_name] dans votre terminal

Exemple de configuration Tmuxinator pour le projet Store sous Drupal


# ~/.tmuxinator/store.yml

name: store
root: ~/www/store

windows:
  - drupal:
      layout: main-vertical
      panes:
        # Aller dans le réperoire docroot/ et utiliser l'alias drush projet.local
        - cd www/store/docroot && drush use @projet.local
        # crée simplement un panneau dans le répertoire root défini
        -
        # Lancer vagrant et se connecter dedans
        - vagrant up && vagrant ssh
  - dev: drush use @projet.dev
  - staging: drush use @projet.test
  - prod:  drush use @projet.prod
  # Lancer PHPStorm
  - editor: pstorm .

Dans le terminal, lancer mux store permettra ainsi de lancer 5 fenêtres tmux + phpstorm.

Références

Oubliez cURL et Wget grâce à HTTPie

Thu, 14 Apr 2016 11:49:35 +0200

HTTPie est un utilitaire en ligne de commande qui a vocation à remplacer simplement l’utilisation des commandes cURL et wget tout en ajoutant une petite touche bien agréable.

Installation

Plusieurs modes d’installation sont possibles. En effet HTTPie est disponible via les packages officiels (pas forcement la dernière version) ou via pip.

Vous trouverez toutes les informations nécessaires dans le Readme du projet.

Formatage et couleur

Formatage

Si vous avez déjà lancé des requêtes à une API via cURL, vous avez déjà du voir des résultats comme ci-dessous.

curl "https://www.drupal.org/api-d7/user.json?name=jygastaud"

{"self":"https:\/\/www.drupal.org\/api-d7\/user?name=jygastaud","first":"https:\/\/www.drupal.org\/api-d7\/user?name=jygastaud\u0026page=0","last":"https:\/\/www.drupal.org\/api-d7\/user?name=jygastaud\u0026page=0","list":[{"field_industries_worked_in":[],"field_organizations":[{"uri":"https:\/\/www.drupal.org\/api-d7\/field_collection_item\/468341","id":"468341","resource":"field_collection_item"},{"uri":"https:\/\/www.drupal.org\/api-d7\/field_collection_item\/724935","id":"724935","resource":"field_collection_item"}],"field_bio":[],"field_irc_nick":"jygastaud","field_websites":[{"url":"http:\/\/www.clever-age.com","attributes":[]}],"field_country":"France","field_gender":"male","field_languages":["English","French"],"field_terms_of_service":true,"field_areas_of_expertise":[],"field_contributed":["patches","modules","issues","applications","forums","services","irc","mentor"],"field_events_attended":[],"field_mentors":[],"field_drupal_contributions":[],"field_first_name":null,"field_last_name":null,"og_user_node":[],"og_membership":[],"og_membership__1":[],"og_membership__2":[],"og_membership__3":[],"og_user_node__og_membership":[],"og_user_node__og_membership__1":[],"og_user_node__og_membership__2":[],"og_user_node__og_membership__3":[],"uid":"660334","name":"jygastaud","url":"https:\/\/www.drupal.org\/u\/jygastaud","edit_url":"https:\/\/www.drupal.org\/user\/660334\/edit","created":"1259343731","language":"en","flag_sid":0,"flag_drupalorg_user_spam_user":[]}]}

Pas très lisible, vous en conviendrez ?

Avec HTTPie, fini les requêtes CURL à une API qui renvoi un gros bloc illisible. Vous pouvez maintenant avoir un retour lisible dans votre terminal.

http "https://www.drupal.org/api-d7/user.json?name=jygastaud"

HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Age: 0
Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 546
Content-Security-Policy: frame-ancestors 'self'
Content-Type: application/json
Date: Thu, 14 Apr 2016 10:16:55 GMT
Etag: "1460629015-1"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Fastly-Debug-Digest: 760fd3aa9c342b8e1bbdc30d5ebbb895ba37763ccd3ce2e0bdab520ac08df17e
Last-Modified: Thu, 14 Apr 2016 10:16:55 GMT
Server: Apache
Strict-Transport-Security: max-age=10886400; includeSubDomains; preload
Vary: Cookie,Accept-Encoding
Via: 1.1 varnish
Via: 1.1 varnish
X-Cache: MISS, MISS
X-Cache-Hits: 0, 0
X-Content-Type-Options: nosniff
X-Drupal-Cache: MISS
X-Frame-Options: SAMEORIGIN
X-Served-By: cache-sea1924-SEA, cache-fra1227-FRA
x-host: www.drupal.org
x-url: /api-d7/user.json?name=jygastaud

{
    "first": "https://www.drupal.org/api-d7/user?name=jygastaud&page=0",
    "last": "https://www.drupal.org/api-d7/user?name=jygastaud&page=0",
    "list": [
        {
            "created": "1259343731",
            "edit_url": "https://www.drupal.org/user/660334/edit",
            "field_areas_of_expertise": [],
            "field_bio": [],
            "field_contributed": [
                "patches",
                "modules",
                "issues",
                "applications",
                "forums",
                "services",
                "irc",
                "mentor"
            ],
            "field_country": "France",
            "field_drupal_contributions": [],
            "field_events_attended": [],
            "field_first_name": null,
            "field_gender": "male",
            "field_industries_worked_in": [],
            "field_irc_nick": "jygastaud",
            "field_languages": [
                "English",
                "French"
            ],
            "field_last_name": null,
            "field_mentors": [],
            "field_organizations": [
                {
                    "id": "468341",
                    "resource": "field_collection_item",
                    "uri": "https://www.drupal.org/api-d7/field_collection_item/468341"
                },
                {
                    "id": "724935",
                    "resource": "field_collection_item",
                    "uri": "https://www.drupal.org/api-d7/field_collection_item/724935"
                }
            ],
            "field_terms_of_service": true,
            "field_websites": [
                {
                    "attributes": [],
                    "url": "http://www.clever-age.com"
                }
            ],
            "flag_drupalorg_user_spam_user": [],
            "flag_sid": 0,
            "language": "en",
            "name": "jygastaud",
            "og_membership": [],
            "og_membership__1": [],
            "og_membership__2": [],
            "og_membership__3": [],
            "og_user_node": [],
            "og_user_node__og_membership": [],
            "og_user_node__og_membership__1": [],
            "og_user_node__og_membership__2": [],
            "og_user_node__og_membership__3": [],
            "uid": "660334",
            "url": "https://www.drupal.org/u/jygastaud"
        }
    ],
    "self": "https://www.drupal.org/api-d7/user?name=jygastaud"
}

couleur

Regarder l’image en exemple sur le dépôt github

![curl vs httpie](https://raw.githubusercontent.com/jkbrzt/httpie/master/httpie.png)

Comme vous pouvez le voir, HTTPie en plus d’apporter un formatage de la sortie vous apportera aussi une colorisation.

Uniformation

Donc avant, vous aviez cURL pour requêter vos URLs et Wget pour télécharger des fichiers.

Grâce à HTTPie, vous pouvez maintenant ne retenir qu’une seule syntaxe !

Ainsi

wget https://ftp.drupal.org/files/projects/devel-8.x-1.x-dev.tar.gz

devient

http --download https://ftp.drupal.org/files/projects/devel-8.x-1.x-dev.tar.gz

Le fait d’être capable d’utiliser une même commande pour les requêtes et pour le téléchargement va vite vous simplifier la vie. Une seule syntaxe à retenir.

Le fait de n’avoir plus qu’une commande à retenir va nous simplifier la vie et cela est encore plus vrai si on doit utiliser des certificats SSL.

Par exemple, nous avons une API que l’on doit requêter et une route de récupération de fichier zip, le tout accessible uniquement via une clé et un certificat SSL.

On passera donc des commandes suivantes

curl -i -v --key ./certs/mon-certicat.key --cert ./certs/mon-certicat.pem "https://mon-api.com/infos"

wget --private-key="./certs/mon-certicat.key" --certificate="./certs/mon-certicat.pem" "https://mon-api.com/infos/images.zip"

http --cert=./certs/mon-certicat.pem --cert-key=./certs/mon-certicat.key https://mon-api.com/infos

http --download --cert=./certs/mon-certicat.pem --cert-key=./certs/mon-certicat.key https://mon-api.com/infos/images.zip

C’est quand même plus simple à retenir quand on a qu’une seule syntaxe non ?

Pour aller plus loin

Lisez la documentation disponible sur le dépôt Github HTTPie elle est vraiment très complète.

Tmux - Exemple de fichier de configuration

Thu, 07 Apr 2016 13:49:38 +0200

Exemple de fichier .tmux.conf

# Update default binding of `Enter` to also use copy-pipe
unbind -t vi-copy Enter
bind-key -t vi-copy Enter copy-pipe "reattach-to-user-namespace pbcopy"

# Mouse scrolling and selection
set -g mode-mouse on
set -g default-terminal "screen-256color"

# Allows for faster key repetition
set -s escape-time 0

# C-b is not acceptable -- Vim uses it; Set ctrl+a as a prefix
set -g prefix C-a
unbind-key C-b
bind-key a send-prefix

bind-key C-a last-window

# Kill windows and panes faster, by rebinding the confirmation key
bind-key &amp; kill-window
bind-key x kill-pane
bind-key q kill-server

# Renumber windows sequentially after closing any of them
set -g renumber-windows on

# set window and pane index to 1 (0 by default)
set-option -g base-index 1
setw -g pane-base-index 1

# increase scrollback lines
set -g history-limit 10000

# get notification when something happend on a tmux window
setw -g monitor-activity on

# disable auto-rename from tmux
set-window-option -g allow-rename off

[Vidéo] La gestion de produit Agile en 2 mots

Thu, 07 Apr 2016 13:32:21 +0200

J’ai (re)découvert cette vidéo il y a quelque temps.

C’est une présentation synthétique de 15 minutes permettant de comprendre très simplement les grands concepts de l’agilité d’un point de vue métier dans le cadre de développement logiciel Agile.
La vidéo a été réalisée par de Henrik Kniberg, traduite par Cédric Chevalérias et doublée par Florent Lothon.

A diffuser sans modération !

[![IMAGE ALT TEXT](https://img.youtube.com/vi/3qMpB-UH9kA/0.jpg)](http://www.youtube.com/watch?v=3qMpB-UH9kA "Voir la vidéo")

HTTP 1.x ou HTTP/2 - Lequel choisir ?

Tue, 02 Feb 2016 13:45:17 +0200

Le support de HTTP/2 est maintenant suffisamment stable et implémenté dans les serveurs les plus couramment utilisés alors qu’elles sont les raisons qui pourraient nous pousser à choisir une version ou l’autre dans nos projets ?

HTTP 1.x

Vous serez obliger de continuer à utiliser HTTP 1.x dans les cas suivants :

site en HTTP non sécurisé

Bien qu’HTTP/2 supporte officiellement le protocole HTTP non sécurisé, l’ensemble des navigateurs ont pour le moment fait le choix de ne pas l’implémenter. Du coup, si vous n’avez pas de certificat pour votre nom de domaine, il vous faudra rester sur HTTP 1.x

Restrictions techniques par rapport au serveur web utilisé

Les cas sont rares maintenant. Vous pouvez vérifier si le votre le supporte sur le Github HTTP2

mon hébergeur ne veut pas le faire

Changer d’hébergeur ! :)

HTTP/2

Si vous avez la main sur l’architecture serveur de votre application ou êtes à même d’être prescripteur sur les solutions à implémenter alors il est préconisé d’envisager de passer à HTTP/2 dès maintenant.

Les contraintes

un serveur supportant HTTP/2
un certificat SSL

Et vous alors êtes-vous déjà passer à HTTP/2 ?

Bash - Récupérer le chemin absolu d'exécution du script

Thu, 10 Dec 2015 13:50:52 +0200

Lors de l’exécution d’un fichier bash, il est parfois nécessaire de récupérer le chemin d’exécution du script.

TL;DR

$(dirname $(readlink -f $0))

Attention : Sur Mac OS X, readlink ne fonctionne pas de la même façon que sur Linux. Il vous faudra chercher une alternative. 3 pistes :

la plus universelle $( cd “$( dirname “${0}” )” && pwd )
utiliser realpath -s $0
installer greadlink

La commande dirname

L’un des moyens les plus courant est d’utiliser la commande

`dirname "$0"`

$0 renvoi le nom du script

Le soucis ici c’est que le retour de dirname ne sera pas identique en fonction de son lieu d’exécution.

Par exemple, les appels suivants auront tous un retour différent :

vagrant@store-dev:~$ sh www/store/updates/update_sample.sh
dirname: www/store/updates

vagrant@store-dev:~/www/store/updates$ sh update_sample.sh
dirname: .

vagrant@store-dev:~/www/store$ sh ./updates/update_sample.sh
dirname: ./updates

vagrant@store-dev:~/www/store/docroot$ sh ../updates/update_sample.sh
dirname: ../updates

Readlink pour nous sauver

Pour s’assurer que dirname nous renvoi toujours un chemin consistant, il est possible de le combiner avec la commande readlink

La combinaison des 2 nous renverra ainsi un chemin absolu vers le script. On aura donc maintenant un retour identique pour tous nos appels au script.

vagrant@store-dev:~$ sh www/store/updates/update_sample.sh
dirname: www/store/updates
dirname/readlink: /home/vagrant/www/store/updates

vagrant@store-dev:~/www/store/updates$ sh update_sample.sh
dirname: .
dirname/readlink: /home/vagrant/www/store/updates

vagrant@store-dev:~/www/store$ sh ./updates/update_sample.sh
dirname: ./updates
dirname/readlink: /home/vagrant/www/store/updates

vagrant@store-dev:~/www/store/docroot$ sh ../updates/update_sample.sh
dirname: ../updates
dirname/readlink: /home/vagrant/www/store/updates

Vérifier ce qui marche chez vous

A mettre dans un fichier test.sh

#!/usr/bin/env bash

echo "pwd: `pwd`"
echo "\$0: $0"
echo "basename: `basename $0`"
echo "dirname: `dirname $0`"
echo "dirname/readlink: $(dirname $(readlink -f $0))"
echo "realpath: $(dirname $(realpath -s $0))"
echo "cd/pwd: $( cd "$( dirname "${0}" )" &amp;&amp; pwd )"

Mise en application

L’exemple ci-dessous nous permet de définir, en fonction des paramètres d’appel du script, l’alias drush à utiliser. Cependant si le script est appelé sans paramètre, nous souhaitons passer définir --root en tant qu’alias.

#!/usr/bin/env bash

# Si pas de paramètres.
if [ -z "${1}" ]
then
    DIR=$(dirname $(readlink -f $0))

    # On vérifie que docroot existe.
    if [ -d ${DIR}"/../docroot" ]
    then
        drush_alias="--root=${DIR}/../docroot"
    else
        echo "Script was not run."
        exit 1
    fi
else
    drush_alias="@${1}"
fi

# La suite du script.

Git : Supprimer toutes les branches mergées sur le dépot distant

Thu, 03 Dec 2015 13:51:38 +0200

Supprimer toutes les branches mergées sur votre dépot distant en 1 ligne de commande c’est possible !

TL;DR

git branch -r --merged master | grep -v master | sed 's/origin\///' | xargs -n 1 git push --delete origin

Attention : cette commande permet de véritablement supprimer des branches dans le dépôt distant. Par exemple, si develop est mergé avec master, cela supprimera develop. Mais peut-être que les développeurs n’ont pas le droit de pousser du code sur master directement… et se retrouveront, du coup, bloqués. Pensez-y !

Exemple excluant une branche nommée `develop`

git branch -r --merged master | grep -v master | grep -v develop | sed 's/origin\///' | xargs -n 1 git push --delete origin

Explications

git branch -r --merged master va récupérer la liste des branches distantes mergées (par rapport à master)
grep -v master va exclure la branche master des résultats (vous pouvez ajouter d’autres branches à exclure si nécessaire)

Ces 2 premières commandes combinées vont renvoyés un résultat dans ce style :

  origin/t-619
  origin/t-63
  origin/t-675
  origin/t-707
  origin/t-808
  origin/t-809
  origin/t-819

sed 's/origin\///' permet de supprimer le origin/
xargs -n 1 git push --delete origin va prendre chaque ligne renvoyée et lancer la commande git push --delete origin BRANCHE

Envoyer des mails HTML via Drupal et Rules

Tue, 03 Nov 2015 13:54:56 +0200

Modules de la contribution

HTML Mail pour la gestion pure du mail au format HTML
Mail System pour définir quel type de mail on envoi en fonction des actions
Variable Email vous permettra de stocker le mail dans une variable et l’envoyer via Rules.

Configuration du module HTML Mail

Définissez dans le module HTMLMail le thème de votre site. Cela permettra de centraliser vos templates au sein de votre thème.

Configuration du module Mail System

Configuré le module pour envoyer des mails passant par HTMLMail dans les cas qui vous intéressent, par exemple les mails système (création de compte, demande de renouvellement de mots de passe) en paramétrant la class HTMLMailSystem

Si vous voulez que les mails envoyés via Rules passent également par HTML Mail, il est possible de créer un “New settings” en sélectionnant le module Rules dans la liste. Une fois le nouveau paramétrage créé, il est possible de lui associer la class HTMLMailSystem

Créer une nouvelle variable de type mail

Dans le .info du module, ajouter une dépendance à

dependencies[] = variable

Créer un fichier my_module.variable.inc

<?php

/**
 * @file
 * my_module.variable.inc
 */

/**
 * Implements hook_variable_info().
 */
function my_module_variable_info($options) {

  $variable['mail_do_something_[mail_part]'] = array(
    'title' => t('Send mail when something happend'),
    'type' => 'mail_text',
    'default' => array(
      'subject' => 'My default subject',
      'body' => 'My default body',
    ),
    'required' => TRUE,
    'group' => 'store_mails',
    'token' => TRUE,
  );

  return $variable;
}

Permettre la modification et traduction de la variable

Allez sur la page /admin/config/regional/i18n/variable et cocher la nouvelle variable créée.
Enregistrer
La variable devrait être disponible en édition pour les différentes langues de votre site sur la page /admin/store/mails
Modifier les valeurs des différentes langues pour y inclure le markup HTML du mail
Enregistrer

Packaging du mail

Ajouter à votre feature la variable à packager Ajouter à votre feature la variable variable_realm_list_language

<?php

$strongarm = new stdClass();
$strongarm->disabled = FALSE; /* Edit this to true to make a default strongarm disabled initially */
$strongarm->api_version = 1;
$strongarm->name = 'variable_realm_list_language';
$strongarm->value = array(
  0 => 'mail_do_something_[mail_part]',
);
$export['variable_realm_list_language'] = $strongarm;

Utiliser la variable dans Rules

Ajouter une Action : Send mail with Variable
Sélectionner la variable créée
Ajouter node:author:language dans la partie Langue, ce qui permettra d’envoyer automatiquement la variable localisée à l’utilisateur

Lors du packaging de votre rules, une dépendance à variable_email devrait se créer.

dependencies[] = variable_email

Dans l’exemple, ci-dessous nous allons envoyer un mail à l’auteur du contenu à sa création et on obtient l’export suivant :

<?php

/**
 * Implements hook_default_rules_configuration().
 */
function my_module_default_rules_configuration() {
  $items = array();
  $items['rules_mail_to_author'] = entity_import('rules_config', '{ "rules_mail_to_author" : {
      "LABEL" : "Send mail to author",
      "PLUGIN" : "reaction rule",
      "OWNER" : "rules",
      "REQUIRES" : [ "variable_email", "rules" ],
      "ON" : { "node_insert--page" : { "bundle" : "page" } },
      "DO" : [
        { "variable_email_mail" : {
            "to" : [ "node:author:mail" ],
            "variable" : "mail_do_something_[mail_part]",
            "language" : [ "node:author:language" ]
          }
        },
      ]
    }
  }');

  return $items;
}

Et vous comment gérez-vous les envois de mails HTML dans Drupal ?

Tests unitaires avec Simpletest dans Drupal 7

Thu, 22 Oct 2015 22:18:35 +0200

Si vous ne l’avez pas encore lu, allez lire l’article Tester ses modules Drupal 7.

Les tests fonctionnels via Simpletest sont gérés par la class DrupalUnitTestCase qu’il faut ensuite étendre dans son module.

Drupal va exécuter chaque fonction commençant par test définie dans la class.

Contrairement aux tests fonctionnels, Drupal ne va pas reconstruire d’environnement pour lancer ce type de tests. Il va se contenter de charger les modules spécifiés dans l’initialisation et lancer les fonctions donner avec les bons paramètres.

Les fonctions testées ne doivent donc pas dépendre de données récupérées en base. C’est le retour de la fonction qui sera ensuite vérifié.

Mise en place des tests

Comme pour les tests fonctionnels il faut étendre une class de base de Drupal : DrupalUnitTestCase

<?php

class MyModuleUnitTestCase extends DrupalUnitTestCase {}

On va également déclarer la méthode getInfo().

<?php

public static function getInfo() {
  // Note: getInfo() strings should not be translated.
  return array(
    'name' => 'My module unit tests',
    'description' => 'Test that utilities functions used in my_module modules work fine.',
    'group' => 'My module group',
  );

}

Déclaration les modules dont on va charger le code via la méthode setUp()

<?php

/**
 * Set up the test environment.
 *
 * Note that we use drupal_load() instead of passing our module dependency
 * to parent::setUp(). That's because we're using DrupalUnitTestCase, and
 * thus we don't want to install the module, only load it's code.
 *
 * Also, DrupalUnitTestCase can't actually install modules. This is by
 * design.
 */
public function setUp() {
  drupal_load('module', 'my_module');
  parent::setUp();
}

et enfin déclarer nos fonction de test qui doivent commencer par le mot clé test.

<?php

/**
 * Test my_module_check_login().
 *
 * Note that no environment is provided; we're just testing the correct
 * behavior of a function when passed specific arguments.
 */
public function testMyModuleCheckLoginFunction() {
  // Your tests
}

Exemple

On souhaite pouvoir tester le retour de la fonction suivante :

<?php

/**
 * Check the user login match the regex.
 *
 * @return
 */
function my_module_check_login($login) {
  // Extract all regex defined.
  $regex_list = explode(';', '/^[0-9]{7}[A-Z]$/i;/^(P|A|Z|F|E|S)[A-Z]{3}[0-9]{5}$/i;/^.*domain\.fr$/i');

  // Check if the login verify at least one regex.
  foreach ($regex_list as $regex) {

    // If there is one result.
    if (preg_match($regex, $login)) {
      return TRUE;
    }
  }
  return FALSE;
}

ce qui pourrait donner un test comme ceci :

<?php

/**
 * Test my_module_check_login().
 *
 * Note that no environment is provided; we're just testing the correct
 * behavior of a function when passed specific arguments.
 */
public function testMyModuleCheckLoginFunction() {
  $result = my_module_check_login(NULL);
  // Note that test assertion messages should never be translated, so
  // this string is not wrapped in t().
  $message = 'A NULL value should return FALSE.';
  $this->assertFalse($result, $message);

  $result = my_module_check_login('');
  $message = 'An empty string should return FALSE.';
  $this->assertFalse($result, $message);

  $result = my_module_check_login('something@domain.fr');
  $message = 'An string with @domain.fr should return TRUE.';
  $this->assertTrue($result, $message);

  $result = store_user_check_login('@domain.fr');
  $message = 'An string with @domain.fr should return TRUE.';
  $this->assertTrue($result, $message);

  $result = my_module_check_login('AZER01234');
  $message = 'A string that looks like a CP code should return TRUE.';
  $this->assertTrue($result, $message);

}

Tests fonctionnels avec Simpletest dans Drupal 7

Thu, 22 Oct 2015 22:17:56 +0200

Si vous ne l’avez pas encore lu, allez lire l’article Tester ses modules Drupal 7.

Les tests fonctionnels via Simpletest sont gérés par la class DrupalWebTestCase qu’il faut ensuite étendre dans son module.

Pour chaque fonction commençant par test définie dans la class, Simpletest va reconstruire entièrement une instance de Drupal, activer les modules désirés et exécuter les tests.

L’avantage de ce type de tests réside dans le fait que Drupal a accès aux informations de la base de données et est donc en capacité d’exécuter la totalité des fonctions disponibles.

Il est donc possible d’utiliser dans ces tests des fonctions comme node_save(), variable_get() …

Mise en place des tests

Déclarer ces fichier de tests

Drupal décrit l’ensemble de ces tests dans des fichiers portant l’extension .test.
Chaque fichier de test doit ensuite être déclaré dans le .info de votre module via la déclaration files[] qui est notamment utilisé par Drupal pour charger ces class.

Ainsi si vous nommez le fichier contenant vos tests mon_module.test, il vous faudra ajouter la ligne suivante dans le .info : files[] = mon_module.test

Contenu minimal d’un fichier de tests

Etendre la class de base de Drupal

Dans le cadre de tests fonctionnels, c’est donc la class DrupalWebTestCase que l’on veut étendre.

<?php

class EditorListTests extends DrupalWebTestCase {}

Déclaration des infos de notre test

C’est la fonction static getInfo() qui se charge de recevoir ces informations. Elle retourne un tableau contenant un nom, une description et un groupe.

Le nom doit être unique pour votre class. Le groupe peut être commun à plusieurs modules, ce qui est pratique pour pouvoir lancer par exemple l’ensemble des tests de vos modules custom en 1 fois.

<?php

public static function getInfo() {
  // Note: getInfo() strings should not be translated.
  return array(
    'name' => 'Editor List tests',
    'description' => 'Test that editor_list module work fine.',
    'group' => 'Editor List',
  );

}

Déclaration des modules à activer

2nd fonction obligatoire à déclarer dans vos fichiers de tests, il s’agit de setUp(). Cette fonction vous permet de définir, notamment, les modules à charger lors de l’initialisation des environnements de test.

Dans l’exemple ci-dessous, on déclare ainsi que les environnements doivent avoir le module editor_list de charger. A l’initialisation Drupal se charge de regarder les dépendances des modules à activer et les activer automatiquement. Il n’est donc pas nécessaire de tous les déclarer explicitement.

<?php

/**
 * {@inheritdoc}
 */
public function setUp() {
  parent::setUp('editor_list');
}

Il est également possible d’utiliser cette méthode setUp() pour définir des éléments nécessaires à l’ensemble de vos tests. Par exemple, création d’un compte admin, création de contenus de tests … Ces éléments pourront ainsi être exploiter directement dans vos tests sans avoir besoin de répéter la phase de création à chaque fois.

Déclarer une fonction de test

Un fonction de test doit obligatoirement commencer par le mot clé test.

<?php

/**
 * Test Administration page access and edition.
 */
public function testAdministrationPage() {
  // Your tests
}

L’obligation d’avoir le mot clé test au début du nom de votre fonction vous permet de créer des fonctions utilitaires dans la même class en étant certains qu’elles ne seront pas exécuter par Simpletest si vous ne les appelez pas explicitement.

Exemple complet

Module editor_list

Tester ses modules Drupal

Thu, 22 Oct 2015 22:17:21 +0200

Les tests fonctionnels et encore plus unitaires sous Drupal c’est la galère.

Voilà une phrase qu’il est fréquent d’entendre.

Nous allons donc essayer via une série d’articles de voir quels types de tests s’offrent à nous, que ce soit via les outils fournis directement par Drupal ou via l’utilisation d’outils externes.

Démarrons donc par une présentation du framework de tests embarqué dans Drupal 7 : Simpletest.

Types de tests disponibles

Simpletest met à disposition 2 types de tests :

des tests fonctionnels
des tests unitaires

Tests fonctionnels

Ces tests sont gérés par la class DrupalWebTestCase qu’il faut ensuite étendre dans son module.

Pour chaque fonction commençant par test définie dans la class, Simpletest va reconstruire entièrement une instance de Drupal, activer les modules désirés et exécuter les tests.

L’avantage de ce type de tests réside dans le fait que Drupal a accès aux informations de la base de données et est donc en capacité d’exécuter la totalité des fonctions disponibles.

Il est donc possible d’utiliser dans ces tests des fonctions comme node_save(), variable_get() …

Si le nombre de tests lancé est conséquent, il est possible que ces tests prennent beaucoup de temps.

Tests fonctionnels avec Simpletest sous Drupal 7

Tests unitaires

Ces tests sont gérés par la class DrupalUnitTestCase qu’il faut ensuite étendre dans son module.

Comme pour les tests fonctionnels, Drupal va exécuter chaque fonction commençant par test définie dans la class.

Les fonctions testées ne doivent donc pas dépendre de données récupérées en base. C’est le retour de la fonction qui sera ensuite vérifié.

Tests unitaires dans Drupal 7 avec Simpletest

Commandes de base

Pour pouvoir lancer vos tests sur Drupal, il faut activer le module Simpletest.
drush en simpletest -y

Lancer les tests via le coeur de Drupal
- pour un groupe de tests
  php scripts/run-tests.sh --url http://site.dev "Editor List"
- pour une class à tester
  php scripts/run-tests.sh --url http://site.dev --class EditorListTests
Lancer les tests via Drush
- pour un groupe de tests
  drush test-run --uri=http://site.dev "Editor List"
- pour une class à tester
  drush test-run --uri=http://site.dev EditorListTests

Stocker les résultats des tests

Que ce soit via Drush ou le sh, vous pouvez spécifier l’option –xml=chemin/dossier/resultats/de/tests qui recevra les récapitulatifs des tester effectués.

drush test-run --uri=http://site.dev --xml=$PWD/tests MonModuleTests

Réinitiliser tous les emails et mots de passe utilisateur avec Drush

Mon, 05 Oct 2015 13:51:52 +0200

Si vous récupérez une base de données Drupal en local, il peut être utile d’assigner des valeurs par défaut aux comptes utilisateurs.

Cela permet entre autre :

de se connecter simplement à l’ensemble des comptes
d’éviter que des mails de tests soient envoyés aux contacts réels

Avec Drush, cela est possible en une ligne de commande :

drush sql-sanitize --sanitize-email="user+%uid@localhost" --sanitize-password="password"

Installer la dernière version de Git sur Ubuntu

Wed, 30 Sep 2015 10:44:14 +0200

Si vous utilisez régulièrement les systèmes de paquets fournis avec vos distributions, vous avez surement remarqué que les versions fournies sont généralement anciennes.

Sur Ubuntu, Git ne déroge pas à la règle.

En effet, Ubuntu 14.04 LTS donne accès à Git 1.9 et Ubuntu 15.05, Git 2.1. Au mieux une version sortie en fin 2014.

Faites le test par vous même en ouvrant votre terminal et en lançant la commande suivante :

$> git --version

Pourquoi mettre à jour ?

Dans un 1er temps pour profiter des corrections et optimisations apportées régulièrement au produit (amélioration des capacités de merge par exemple qui permet d’avoir une meilleure gestion des conflits), sans oublier les évolutions qui sont ajoutées régulièrement.

On peux par exemple noté que la version 2.5 de Git apporte la possibilité d’avoir plusieurs worktree - nos espaces de travail - simultanés via la commande git worktree et depuis le 28 septembre 2015, la version 2.6.0 de Git est sortie.

Alors comment mettre à jour simplement notre machine pour avoir accès aux dernières versions de Git.

Comment on fait ?

La solution en 3 commandes (à lancer dans votre terminal)

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git

Et voilà ! Vous devriez maintenant avoir accès à la dernière version de Git.

Pour vérifier lancer à nouveau, dans votre terminal :

git --version

Si la commande vous renvoie git version 2.6.0 (ou un nombre supérieure), c’est que tout c’est bien déroulé.

Maintenant, votre version de Git continuera à se mettre à jour.

Je vous invite donc à suivre régulièrement les Releases Notes de Git, toujours pleines de bonnes informations à découvrir.

Gestion et surcharge d'un field instance sous Drupal 8

Mon, 31 Aug 2015 23:54:38 +0200

![entity connect](entityconnect.png)

Retour sur le portage des options de configuration de champs pour le module Entity Connect sous Drupal 8.

Entity Connect vient ajouter de nouvelles fonctionnalités aux champs de type Entity Reference. Le module propose de définir, pour chaque instance de champ, si les fonctionnalités proposées doivent être activées ou non.

Surcharge de l’instance du champ Entity Reference

Dans notre cas, nous avons besoin de surcharger la class ConfigurableEntityReferenceItem.

<?php

namespace Drupal\entityconnect;

use Drupal\entity_reference\ConfigurableEntityReferenceItem;
use Drupal\Core\Form\FormStateInterface;

class ConfigurableEntityconnectItem extends ConfigurableEntityReferenceItem {
  // Do something.
}

Création du formulaire

Ajout des paramètres au field instance.

Drupal 7

Sur Drupal 7, nous implémentions le hook_field_instance_settings_form que nous invoquions ensuite via un hook_form_alter.
C’est l’utilisation du hook_form_alter qui permettait de passer de nouvelles valeurs de configuration au champ.

<?php

/**
 * Add settings to an instance field settings form.
 *
 * Invoked from field_ui_field_edit_form() to allow the module defining the
 * field to add settings for a field instance.
 *
 * @return array
 *   The form definition for the field instance settings.
 */
function entityconnect_field_instance_settings_form($field, $instance) {
  $settings = $instance;

  // Add choice for user to not load entity connect "add" button
  // on the field.
  $form['entityconnect_unload_add'] = array(
    '#type' => 'radios',
    '#title' => t('Display Entity Connect "add" button.'),
    '#default_value' => !isset($settings['entityconnect_unload_add']) ? variable_get('entityconnect_unload_add_default', 1) : $settings['entityconnect_unload_add'],
    '#description' => t('Choose "No" if you want to unload "add" button for the field'),
    '#options' => array(
      '0' => t('Yes'),
      '1' => t('No'),
    ),
    '#weight' => 1,
  );

  // ...
}

<?php

/**
 * Implements hook_FORM_ID_form_alter().
 *
 * @param $form
 * @param $form_state
 * @param $form_id
 */
function entityconnect_form_field_ui_field_edit_form_alter(&$form, &$form_state, $form_id) {

  $field_types = _entityconnect_get_references_field_type_list();

  // Use to add choice field.
  if (in_array($form['#field']['type'], $field_types)) {
    $instance = $form['#instance'];
    $field = $form['#field'];
    $additions = module_invoke('entityconnect', 'field_instance_settings_form', $field, $instance);
    if (is_array($additions) && isset($form['instance'])) {
      $form['instance'] += $additions;
    }
  }
}

Drupal 8

Sur Drupal 8, la déclaration du formulaire va passer par la fonction fieldSettingsForm().

La récupération de la configuration va se faire via $this->getSettings(). Cette fonction renvoi un tableau.
On va charger le formulaire parent (la configuration de notre champ Entity Reference) et ensuite ajouter nos champs. Sans cela, seuls nos nouveaux champs vont apparaitre.

<?php

  /**
   * {@inheritdoc}
   */
  public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
    $settings = $this->getSettings();

    $form = parent::fieldSettingsForm($form, $form_state);

    // ...

    $form['entityconnect']['buttons']['button_add'] = array(
      '#required' => '1',
      '#default_value' => $settings['entityconnect']['buttons']['button_add'],
      '#description' => $this->t('Default: "off"<br />
                            Choose "on" if you want the "add" buttons displayed by default.<br />
                            Each field can override this value.'),
      '#weight' => '0',
      '#type' => 'radios',
      '#options' => array(
        '0' => $this->t('on'),
        '1' => $this->t('off'),
      ),
      '#title' => $this->t('Default Entity Connect "add" button display'),
    );


    // ...
  }

Comme dans le formulaire d’administration, nous n’avons pas besoin de tester l’existance ou non d’une configuration.
On se contente de récupérer la valeur configurée.

Définir les valeurs par défaut de notre instance de champ

Utiliser des valeurs définies en dures

<?php

  /**
   * {@inheritdoc}
   */
  public static function defaultFieldSettings() {
    return array(
      'entityconnect' => array(
        'buttons' => array(
          'button_add' => 1,
          'button_edit' => 1,
        ),
        'icons' => array(
          'icon_add' => 0,
          'icon_edit' => 0,
        ),
      ),
    ) + parent::defaultFieldSettings();
  }

Attention à ne pas oublier l’appel à + parent::defaultFieldSettings(); sous peine de ne pas avoir l’ensemble des settings disponibles.

Utiliser les valeurs par défaut disponible dans la configuration

<?php

  /**
   * {@inheritdoc}
   */
  public static function defaultFieldSettings() {

    $config = \Drupal::config('entityconnect.administration_config');
    $data = $config->getRawData();

    return array(
      'entityconnect' => $data
    ) + parent::defaultFieldSettings();
  }

\Drupal::config('entityconnect.administration_config') nous permet de charger les informations de configurations disponibles
$config->getRawData() nous permet de récupérer un tableau des valeurs (ci-dessous) par défaut (celles définies à l’installation ou configurées via le Back-Office).

# Le retour de l'appel à $config->getRawData();
# Dans cet exemple, on voit que les valeurs par défaut
#   ont été changées dans l'interface d'administration.
array (size=2)
  'buttons' =>
    array (size=2)
      'button_add' => string '1' (length=1)
      'button_edit' => string '0' (length=1)
  'icons' =>
    array (size=2)
      'icon_add' => string '2' (length=1)
      'icon_edit' => string '1' (length=1)

Il ne nous reste plus qu’à remplacer nos valeurs en dures par nos valeurs dynamiques.

Prise en compte de notre nouvelle class

Le module Entity Reference définie sa class dans son fichier .module et utilise le hook_field_info_alter

 1<?php
 2
 3/**
 4 * Implements hook_field_info_alter().
 5 */
 6function entity_reference_field_info_alter(&$info) {
 7  // Make the entity reference field configurable.
 8  $info['entity_reference']['no_ui'] = FALSE;
 9  $info['entity_reference']['class'] = '\Drupal\entity_reference\ConfigurableEntityReferenceItem';
10  $info['entity_reference']['list_class'] = '\Drupal\Core\Field\EntityReferenceFieldItemList';
11  $info['entity_reference']['default_widget'] = 'entity_reference_autocomplete';
12  $info['entity_reference']['default_formatter'] = 'entity_reference_label';
13  $info['entity_reference']['provider'] = 'entity_reference';
14}

Afin que notre class soit prise en compte, nous allons nous aussi utiliser ce hook et remplacer la class ConfigurableEntityReferenceItem par la notre.

1<?php
2
3/**
4 * Implements hook_field_info_alter().
5 */
6function entityconnect_field_info_alter(&$info) {
7  $info['entity_reference']['class'] = '\Drupal\entityconnect\ConfigurableEntityconnectItem';
8}

Création d'un formulaire d'administration sous Drupal 8

Thu, 27 Aug 2015 15:47:06 +0200

Retour sur le portage de la partie d’administration du module Entity Connect sous Drupal 8.

Conversion du fichier .info

Le nom du fichier change légèrement. Il passe ainsi de *.info à *.info.yml
Comme vous pouvez vous en douter en lisant le nom du nouveau fichier, le format utilisé dans ce fichier est le YAML.

Drupal 7

.info

name = "Entity Connect"
description = "Allows for referenced entity to be created and edited from the entity reference field"
core = "7.x"
package = Entity Connect
configure = admin/config/content/entityconnect

Drupal 8

.info.yml

name: Entity Connect
type: module
description: Allows for referenced entity to be created and edited from the entity reference field
core: 8.x
package: Entity Connect
configure: entityconnect.administration_form
dependencies:
  - entity_reference

La notation YAML fait que les = deviennet des :
Les guillemets sont toujours optionnels
Il faut maintenant définir un type : type: module
Le lien configure permettant d’afficher un lien direct vers l’interface d’administration ne contient plus directement un lien mais une référence à une route définie dans le fichier entityconnect.routing.yml (voir ci-dessous).
Le module entityreference (sous D7) fait maintenant partie intégrante du coeur et s’appelle entity_reference.

Définition des routes

Drupal 7

la définition d’un nouveau chemin d’accès (route) passait par l’utilisation du hook_menu.

<?php
/**
 * Implements hook_menu().
 */
function entityconnect_menu() {
  $items = array();

  $items['admin/config/content/entityconnect'] = array(
    'title' => 'Entity Connect',
    'description' => 'Configure default values for Entity Reference fields using Entity Connect',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('_entityconnect_admin_form'),
    'access arguments' => array('administer site configuration'),
    'file' => 'includes/entityconnect.admin.inc',
  );

  return $items;
}

Drupal 8

nous définissons maintenant ces éléments dans un fichier en *.routing.yml

entityconnect.administration_form:
  path: '/admin/config/content/entityconnect'
  defaults:
    _form: '\Drupal\entityconnect\Form\AdministrationForm'
    _title: 'Entity Connect Administration'
  requirements:
    _permission: 'access administration pages'

Conversion du formulaire

Drupal 7

<?php
/**
 * Defines the settings form.
 */
function _entityconnect_admin_form($form, &$form_state) {
  $form = array();
  $form['entityconnect'] = array(
    '#type' => 'fieldset',
    '#title' => t('EntityConnect default Parameters'),
  );
  $form['entityconnect']['button'] = array(
    '#type' => 'fieldset',
    '#title' => t('Buttons display Parameters'),
  );
  $form['entityconnect']['button']['button_add'] = array(
    '#required' => '1',
    '#key_type_toggled' => '1',
    '#default_value' => variable_get('entityconnect_unload_add_default', 1),
    '#description' => t('Default: "off"<br />
                          Choose "on" if you want the "add" buttons displayed by default.<br />
                          Each field can override this value.'),
    '#weight' => '0',
    '#type' => 'radios',
    '#options' => array(
      '0' => t('on'),
      '1' => t('off'),
    ),
    '#title' => t('Default Entity Connect "add" button display'),
  );
  $form['entityconnect']['button']['button_edit'] = array(
    '#required' => '1',
    '#key_type_toggled' => '1',
    '#default_value' => variable_get('entityconnect_unload_edit_default', 1),
    '#description' => t('Default: "off"<br />
                          Choose "on" if you want the "edit" buttons displayed by default.<br />
                          Each field can override this value.'),
    '#weight' => '1',
    '#type' => 'radios',
    '#options' => array(
      '0' => t('on'),
      '1' => t('off'),
    ),
    '#title' => t('Default Entity Connect "edit" button display'),
  );
 ...

  $form['submit'] = array(
    '#type' => 'submit',
    '#value' => 'Save',
    '#weight' => '2',
  );

  return $form;
}

<?php

/**
 * The settings form submit.
 */
function _entityconnect_admin_form_submit($form, &$form_state) {
    variable_set('entityconnect_unload_add_default', $form_state['values']['button_add']);
    variable_set('entityconnect_unload_edit_default', $form_state['values']['button_edit']);
    drupal_set_message(t('The settings were saved.'));
}

Drupal 8

Nous allons devoir définir une class qui va étendre la class ConfigFormBase de Drupal.
Pour assurer l’autoload des classes, Drupal suit les conventions PSR-4.
Nous allons donc créer notre nouvelle class au sein de l’arborescence suivante :

.
├── src
│   └── Form
│       └── AdministrationForm.php

On défini une namespace à notre class qui sera de la forme Drupal\nom_du_module\Form\MyForm

Les modules avec un nom composé utilisent le caractère underscore ( _ ) comme séparateur.

<?php

/**
 * @file
 * Contains Drupal\entityconnect\Form\AdministrationForm.
 */

namespace Drupal\entityconnect\Form;

On va définir les classes utilisées dans notre Formulaire.

<?php

use Drupal\Core\Form\ConfigFormBase;
use Drupal\Core\Form\FormStateInterface;

On instancie notre class qui étend ConfigFormBase.

<?php

/**
 * Class DefaultForm.
 *
 * @package Drupal\entityconnect\Form
 */
class AdministrationForm extends ConfigFormBase {

ConfigFormBase nous permet ne pas avoir à redéfinir l’action de sauvegarde, l’instanciation du thème et du message de confirmation d’enregistrement.

Nous commençons par initialiser la fonction getEditableConfigNames() qui va nous permettre de définir un tableau contenant les noms des objets de configuration que notre formulaire va pouvoir éditer.

<?php
  /**
   * {@inheritdoc}
   */
  protected function getEditableConfigNames() {
    return [
      'entityconnect.administration_config'
    ];
  }

La documentation Drupal fait généralement référence à un nom de la forme mon_module.settings. Cependant settings n’est pas un nom obligatoire. Le format attendu étant le suivant <module_name>.<config_object_name>.<optional_sub_key>.yml.

Ce nom sera utilisé à chaque fois qu’il est nécessaire de récupérer ou modifier cet élément de configuration. Il sera également utilisé pour instancier les valeurs par défaut.

On donne ensuite un Id à notre formulaire.

<?php

  /**
   * {@inheritdoc}
   */
  public function getFormId() {
    return 'entityconnect_administration_form';
  }

Il est recommandé de faire commencer le formId par le nom du module.

Et on construit notre formulaire via la fonction buildFrom.
Comme nous avons besoin de récupérer des éléments de configuration, nous allons charger la configuration via $this->config('entityconnect.administration_config') que l’on stocke dans une variable nommée $config.
Ainsi nous utiliserons la variable $config pour récupérer la valeur souhaitée via l’appel $config->get('ma_variable'),

<?php

  /**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {
    $config = $this->config('entityconnect.administration_config');

    $form['entityconnect'] = array(
      '#type' => 'fieldset',
      '#title' => $this->t('EntityConnect default Parameters'),
    );

    // ...

    $form['entityconnect']['button']['button_add'] = array(
      '#required' => '1',
      '#default_value' => $config->get('button_add'),
      '#description' => $this->t('Default: "off"<br />
                            Choose "on" if you want the "add" buttons displayed by default.<br />
                            Each field can override this value.'),
      '#weight' => '0',
      '#type' => 'radios',
      '#options' => array(
        '0' => $this->t('on'),
        '1' => $this->t('off'),
      ),
      '#title' => $this->t('Default Entity Connect "add" button display'),
    );

    // ...

Et on fini par retourner un appel à la class parent avec les éléments de formulaire ajoutés.

<?php
    return parent::buildForm($form, $form_state);
  }

Enfin il est nécessaire de pouvoir enregistrer les valeurs après validation du formulaire. Nous allons donc encore une fois utiliser l’objet $this->config('entityconnect.administration_config') et définir la variable avec la valeur du formulaire.

<?php

  /**
   * {@inheritdoc}
   */
  public function submitForm(array &$form, FormStateInterface $form_state) {
    parent::submitForm($form, $form_state);

    $this->config('entityconnect.administration_config')
      ->set('icon_add', $form_state->getValue('icon_add'))
      ->set('icon_edit', $form_state->getValue('icon_edit'))
      ->save();
  }

}

On a maintenant un formulaire prêt à fonctionner et enregistrer des éléments de configuration.

Définition des valeurs par défaut

Vous aurez peut être remarqué qu’à la différence de la fonction variable_get() dans Drupal 7, nous n’avons pas défini de valeurs par défaut à nos ~~variables~~ configuration.

Il n’est donc plus possible (et nécessaire) de redéfinir à chaque appel la valeur par défaut associée à une variable comme dans cet exemple variable_get('entityconnect_unload_add_default', 1) où 1 était la valeur par défaut.

Dans Drupal 8, les configurations sont maintenant stockées dans des fichiers.
Pour définir une valeur par défaut à nos éléments de configuration, il est donc nécessaire de définir cela à l’installation du module.

2 voies sont possibles :

soit via le hook_install, si les valeurs a renseignée sont dynamiques

<?php
/**
 * Implements hook_install() in Drupal 8.
 */
function modulename_install() {
  // Set default values for config which require dynamic values.
  \Drupal::configFactory()->getEditable('modulename.settings')
    ->set('default_from_address', \Drupal::config('system.site')->get('mail'))
    ->save();
}

soit via l’utilisation d’un fichier YAML qui contiendra les configurations par défaut (si les valeurs sont statiques).
```
# Contenu du fichier entityconnect.administration_config.yml
button_add: 1
button_edit: 1
icon_add: 0
icon_edit: 0
```

Ce fichier doit se nommer avec le même nom que l’objet de configuration que nous appelons dans notre formulaire.

Le fichier YAML créé doit être placé dans l’arborescence suivante :

.
├── config
│   └── install
│       └── entityconnect.administration_config.yml

Organisation des fichiers (récapitulatif)

Drupal 7

.
├── entityconnect.info
├── entityconnect.module
├── includes
│   ├── entityconnect.admin.inc

Drupal 8

.
├── config
│   └── install
│       └── entityconnect.administration_config.yml
├── entityconnect.info.yml
├── entityconnect.module
├── entityconnect.routing.yml
├── src
│   └── Form
│       └── AdministrationForm.php

Docker - Comprendre le fonctionnement du tag latest

Thu, 09 Apr 2015 00:00:00 +0000

Cet article est une synthèse d’une publication parue sur Medium qui explique de manière précise le fonctionnement du tag latest disponible sur les images Docker.

Comme vous le savez surement, il est possible de tagger ces images Docker pour les déposer sur un registry.

Cependant si vous avez essayé d’utiliser le tag lastest disponible pour certaines images, notamment sur le Hub Docker, vous avez pu vous rendre compte que ce tag n’a pas toujours le comportement espéré.

Un secret enfin révélé

Ce que l’on apprend dans l’article, c’est que ce tag “latest” n’est pas vraiment un tag.

Il n’est en réalité présent que pour désigner la dernière version commitée sans tag et non pas la dernière version taggée/commitée.

Il est ainsi probable que beaucoup de versions “latest” sur le Hub Docker ne soit en réalité pas les versions les plus à jour. Cela implique en effet une forte rigeur (et connaissance du fonctionnement que l’on vient de décrire) de la part des auteurs des images disponibles car pour maintenir le tag “latest” à jour, il est obligatoire de toujours prévoir un double taggage de son image.

une première fois sans numéro de tag
une seconde fois avec une numéro de tag

Le conseil de l’auteur

Oublier que ce tag latest existe et ne jamais l’utiliser.
Toujours penser à tagger vos images

Je vous invite à lire l’intégralité de la démonstration pour plus de détails.

Docker - Erreurs de débutant

Tue, 12 Aug 2014 00:00:00 +0000

Dans l’article précédent, je parlais du projet [Wintersmith Docker]((https://github.com/jygastaud/wintersmith_docker) et mentionnais le fait que j’avais fait des erreurs dans la conception initiale, dûes à un manque de connaissance de Docker.

Le Dockerfile

L’une des premières erreurs que j’ai fait a été de vouloir tout mettre dans le Dockerfile en pensant que tout doit passer par là pour automatiser les choses.

C’est en partie vrai mais il est parfois préférable de séparer la partie stack logiciel, data et build.

Mon 1er Dockerfile ressemblait à cela

# DOCKER-VERSION 0.9.1
FROM  ubuntu

RUN     sudo apt-get update -qq
RUN     sudo apt-get install python-software-properties -y -qq
RUN     sudo apt-get install nodejs npm -y -qq
RUN     sudo apt-get install nodejs-legacy -y -qq

# Bundle app source
ADD ./www /www

# Install app dependencies
RUN sudo npm install wintersmith -g

# Create new site
WORKDIR /www
RUN wintersmith new site

# Launch Wintersmith preview
WORKDIR /www/site
CMD ["wintersmith", "preview"]

EXPOSE  8080

Rentrons un peu dans le détail du fichier pour voir les différentes problématiques:

FROM ubuntu nous ne spécifions aucune version ce qui a pour conséquence de provoquer le téléchargement de tous les layers Ubuntu et non pas ceux seulement dédiés à la version souhaitée.

Il est donc préférable d’écrire l’instruction sous la forme suivante: FROM ubuntu:<VERSION>

RUN wintersmith new site était censé créé l’arborescence du site par défaut tel que présentée ci-dessous

www
└── site
    ├── contents
    │   ├── articles
    │   │   ├── XXXXXXXXXXX
    │   │   ├── YYYYYYYYYYY
    │   │   ├── ZZZZZZZZZZZ
    │   ├── authors
    │   └── css
    ├── plugins
    └── templates

La commande s’exécutait bien mais le dossier créé n’est pas récupérable.

Avec quelques recherches, il s’avère que la commande docker cp semblait être faite pour cela mais l’export de fonctionne pas car cp n’est, à ce jour, capable de ne copier qu’un fichier à la fois (nous y reviendrons dans un prochain article).

CMD ["wintersmith", "preview"] bien que cette commande ne soit pas fausse en soit, il est recommandé par par Docker l’utilisation de ENTRYPOINT[] et de garder au niveau du CMD[] uniquement les paramètres de la commande.

J’apprenais d’ailleurs par la suite, en discutant sur le channel IRC de Docker, que ENTRYPOINT ne servait pas que au niveau des commandes du Dockerfile mais aussi du run d’un conteneur en définissant la commande par défaut exécutée.

En effet, lors du run, il est possible de spécifier des paramètres d’exécution à l’image d’origine. Il est ainsi possible d’éxécuter différents types de conteneur:

docker run -d jygastaud/wintersmith preview permettra de lancer le mode preview
docker run -d jygastaud/wintersmith new nouveau_site lancera la commande de génération de site de Wintersmith.

Finalement, après qelques ajustements et changements de méthodes, mon Dockerfile ressemble à cela maintetenant:

FROM ubuntu:14.04
MAINTAINER jygastaud

# Some stuff
# Here

ENTRYPOINT ["wintersmith"]

# Clean up APT when done.
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Cette configuration nous donne un panel d’utilisation globale de Wintersmith en ne stockant qu’un minimum d’information.

Wintersmith Docker - Introduction

Fri, 08 Aug 2014 00:00:00 +0000

Après plusieurs lectures et essais rapides de Docker, j’ai décidé d’y consacrer une peu plus de temps de manière concrête.

Etant en pleine réflexions sur l’outil que j’allais utilisé pour la réalisation de ce blog, j’ai donc décidé de lancer le projet Wintersmith Docker afin de pouvoir tester Wintersmith, un générateur de site statique basé sur Nodejs, dans un conteneur Docker.

Ca sert à quoi ce projet?

Le projet donne accès à 2 types d’utilisation:

Pour les utilisateurs de Vagrant, un Vagrantfile est disponible en plus du Dockerfile afin d’avoir l’installation de Docker, la création de l’image et le lancement du conteneur Docker réalisé de manière automatisé.
Pour les utilisateurs de Docker, le Dockerfile permet de créer une image contenant Nodejs et Wintersmith pré-installés qui peut être ensuite appeler pour la création d’un ou plusieurs containers.

La mise en place de ce projet a été extremement formatrice sur Docker. Je vous invite à lire les quelques notes en vracs que j’ai posté dans mon billet précédent.

Un peu d’historique

L’idée initiale du projet était simple et se décomposait comme ceci:

Créer une image via Docker contenant Wintersmith et Nodejs pour pouvoir à volonté:

Créer un nouveau site Wintersmith: wintersmith new <site name>
Partager un site existant

Créer un conteneur Docker qui

Lancerait Wintermith en mode preview: wintersmith preview
Permettrait de voir en live les modifications / ajouts faits dans le dossier de contenus.

Le tout sans avoir besoin d’installer Wintersmith et Nodejs en local (comme avec une VM Vagrant en fait mais en plus léger).

Un peu d’honnêteté

Soyons franc,tout n’a pas été tout beau et tout rose.

Docker n’offre pas la même souplesse qu’un machine virtuelle complète et est notamment restreint par:

le fait de ne devoir gérer qu’un seul processus par conteneur (tout du moins si l’on ne passe pas par des solutions de contournement telles que Supervisor)
le fait de ne pas pouvoir exécuter plusieurs commandes lors du run d’un conteneur
le fait de ne pas avoir d’accès direct (via ssh par exemple) au conteneur lancé
etc

Ces quelques exemples montrent bien les différences, potentiellement mal perçues/comprises, entre un Docker et une VM.

Les usages que l’on peut trouver aux 2 systèmes ne sont pas forcement concurrents. Pour preuves, Vagrant propose de faire son provisioning avec Docker.

Mes notes sur Docker

Mon, 04 Aug 2014 00:00:00 +0000

Le fichier Dockerfile produit une Image
Dans le Dockerfile il n’est possible de mettre qu’une seule instruction CMD.
- Si 2 intructions (ou plus) sont dans le même fichier, seule la dernière sera exécutée.
Il est possible de commiter, pusher ou récupérer une image (à la façon de GIT)
docker run ... produit une instance de l’image
Les fichiers ajoutés via l’image (et le Dockerfile) sont fixes à chaque lancement de run
Si la commande run contient l’option -v il est possible de partager un dossier local (alors dynamique dans le conteneur)
- Si un ADD dans le dockerfile contient le même chemin que celui que l’on veut rendre dynamique, cela ne marche pas.
Il est possible de partager des volumes entre les conteneurs lors du run via l’option –volumes-from
On peut nommer un conteneur (–name) ce qui permet d’effectuer les opérations via son nom et non son ID (ne marche pas pour toutes les commandes)

Configurer Nginx pour gérer automatiquement vos sous-domaines locaux

Tue, 07 Jan 2014 00:00:00 +0000

Lors des développements locaux, nous avons pris l’habitude de toujours définir un nom de domaine local (mon_site.local dans notre exemple) afin de coller au plus proche de la réalité du site final.

Le processus classique était le suivant

Ajout d’un nouveau dossier allant contenir notre site dans notre répertoire de développement (/var/www dans notre exemple). On obtient ainsi l’arborescence suivante:

/var/www/
├── mon_site1
│   └── index.html
├── mon_site2
│   └── index.html

Ajout d’un nouvel host local dans le fichier /etc/hosts

127.0.0.1 mon_site.local

Fonctionnement désiré

Le but principal de notre implémentation est de pouvoir traiter un ensemble de sous-sites de manière générique pour ne pas avoir à recréer de nouveaux vhosts et aller modifier le fichier hosts local à chaque nouvelle implémentation.

Ainsi avec l’arborescence ci-dessous,

/var/www/
├── local.dev
│   └── www
│       ├── test1
│       │   └── index.html
│       └── test2
│           └── index.html

il nous sera immédiatement possible d’accéder aux sous-domaines suivants et de charger le bon fichier d’index:

test1.local.dev
test2.local.dev

Configuration de Nginx

Nous partons du prérequis que vous avez déjà Nginx installé sur votre machine. Si ce n’est pas le cas, une bref recherche vous permettra de trouver de nombreux tutoriaux traitant de ce sujet.

Dans notre exemple, la version de nginx utilisée est la suivante: nginx version: nginx/1.4.1 (Ubuntu)

Création d’un nouveau site nginx

Configuration de notre site dans le dossier /etc/nginx/sites-available

server {
    # On écoute le port 80.
    listen 80;

    # On va utiliser une expression régulière
    # pour récupérer le sous-domaine dans une variable nommée "sub".
    server_name  ~^(?P<sub>.+)\.local\.dev$;

    location / {
         # On définie le chemin local
         # en utilisant la variable "sub" récupérée précédemment.
         root /var/www/local.dev/www/$sub;
    }
}

On active notre site via un lien symbolique dans le dossier /etc/nginx/sites-enable

ln -s /etc/nginx/sites-available/local.dev /etc/nginx/sites-enable/local.dev

et on redémarre le serveur via la commande:

service nginx restart

Configuration d’un hote générique

1ères tentatives

Notre 1ère logique a donc était d’essayer de définir un domaine générique au sein de notre fichier /etc/hosts comme nous pouvions le faire avec notre domaine classique.

Nous avons donc tenter l’ajout de plusieurs lignes avec ou sans wildcard (*) telles que:

127.0.0.1 local.dev
127.0.0.1 .local.dev
127.0.0.1 *.local.dev

mais rien n’y fait, ces solutions ne marchent pas et il nous fallait toujours ajouter nos sous-domaines “à la main” dans le fichier hosts.

Le problème

Le fichier hosts ne permet pas de définir de wildcards pour un domaine.

Il est donc normal que nos tentitves précédentes ne fonctionnent pas.

La solution

Nos diverses recherches nous ont emmené à découvrir que la seule solution possible pour obtenir le résultat escompté était de passer par un serveur de DNS installé en local et qui se chargerait de faire l’interprétation et la traduction du nom de domaine.

Plusieurs solutions existes pour cela et dont la plus connue est Bind. Toutefois, Bind nous paraissait trop lourd à implémenter pour notre besoin et nous nous sommes finalement rabattus sur l’utilisation de DNSMasq qui permet une implémentation rapide et une configuration très simple.

###DNSmasq

Dans le fichier /etc/dnsmasq.conf (le créer s’il n’existe pas), il vous suffit d’ajouter la ligne suivante:

address=/mon_nom_de_domaine.extension/127.0.0.1

et c’est tout!

Dans notre exemple, nous avons donc ajouter:

address=/local.dev/127.0.0.1

On redémarre dnsmasq (service dnsmasq restart sur Ubuntu) et on peut constater que nos domaines sont accessibles.

Drupal Export des noeuds en Markdown

Wed, 01 Jan 2014 00:00:00 +0000

Ressources utiles:

* https://github.com/lukaswhite/Drupal-Markdownify
* https://github.com/lukaswhite/Drupal-Jekyll-Export
* http://www.gizra.com/content/dekyll-drupal-on-jekyll/

DrupalCamp Paris2013 - Behat et Drupal

Sat, 22 Jun 2013 15:00:28 +0100

Behat et Drupal

Selenium API et IDE

Comment automatiser les tests?
- Selenium Server
- PHPUnit
- Selenium IDE
- …
Comment tester l’ajax?
- Selenium à installer
Comment tester le multi-domaine

Behaviour Driven Development (BDD)

CF: Ryan Weaver portland 2013

Gherkin

Langage qui permet de définir des tests

Feature
- Scenario
  - Steps
    - Context: Given
      - And
    - When
      - And
    - Result: Then

Cucumber

Gherkin + Ruby

Behat + Mink

Behat

Gherkin + PHP => Behat

Mink

Drivers
- ZombieDriver
- Sahi
- Goutte (si pas besoin de js)
- Selenium (avec js)
MinkExtension sert à lier Behat et Mink
Behat est indépendant de l’application web
Behat s’installe via Composer
Exécutable dans dossier bin/

FeatureContext.php doit être modifié pour étendre MinkContext Il est possible de créer des subcontexts

Attention le mouseover ne fonctionne que sur les éléments javascript, pas css

Projet Drupal

DrupalExtension => project/drupalextension

DrupalCamp Paris2013 - GED

Fri, 21 Jun 2013 15:00:28 +0100

GED

Acquisition

Imports: Feed, custom
Services, CMIS API
Solr

Stockage

Versionning + diff Archivage: Taxonomie Workflow: Maestro

Classement

Gestion des permissions
FacetAPI

Principales

Alfresco Knowledge Tree

Annexes

ExoPatform
Quotero

Comparaison

Faiblesses de Drupal:

Intégration avec MS et Google Docs
WebDav

Avantages de Drupal :

Garantie de support et d’évolutivité
Confiance
431 modules uniquement pour la gestion de fichiers
Couverture fonctionnelle “sans limite”

Cas clients

Intranet collaboratif : Médecin Sans Frontière

Problèmes:

Documents non structurés
Pas toujours à jour

Solutions:

FacetApi
LDAP

Constructeur automobile

Problèmes:

Médiathèque déjà en place
Pas de partages
Pas de visualisation

Solutions:

Feed + Feeds Xpath Parser pour les imports

Prêt à porter

Problèmes:

Gestion manuelle des PDF
Synchronisation journalière de l’ensemble des docs
Uniquement accessible sur le réseau d’entreprise

Solutions:

Classement par taxo
Module custom pour import automatique 1 fois / jour
Versionning Drupal
Apache Solr
- 6000 pdf / jour à importer en 2 heures
Permissions gérées de façon hierarchique
- Modules custom d’import du LDAP avec la hierachie associé
Délégations des permissions
- Le salarié C peut déléguer au salarié B
- Module Custom

Drupal est-il toujours pertinant?

Toujours faire le pendant entre le niveau de custom à faire vs autres solutions du marché

Dans ce cas, penser à faire collaborer Alfresco et Drupal via module CMIS

On peut donc toujours utiliser Drupal en pensant bien les besoins à l’avance.

Q&A

Niveau indexation: Les optimisations sont plus simples à mettre en place coté Drupal que Alfresco

Pas de modules contribués

DrupalCamp Paris2013 - Livraison continue avec Drupal 7

Fri, 21 Jun 2013 15:00:28 +0100

Prise de note lors de la conférence du DrupalCamp Paris 2013.

Comment faire un site en 1,5 mois sans le faire à l’arrache?

Faut le faire en agile!

On s’engage sur une date ou sur un périmètre mais pas les 2
Définition du “Minimum Viable Product”

Comment livrer le plus souvent possible:

Tout automatisé

Construction d’un build pipeline

Flux automatisé jusqu’à la mise en production

commit -> Inté continue -> recette développeur -> déploiement en intégration -> recette métier -> déploiement en pré prod -> validation finale -> déploiement en production

Tout a été orchestré avec Jenkinks

Quelle base de données fait foi?

La base de données de developpement doit être la base de référence

Comment transposer la configuration d’un environnement à l’autre?

Features
hook_update

1 feature par grand domaine, pas par réelles fonctionnalités

Toujours valider le déploiement (smoke tests)

Lancement des tests d’intégration automatisés -> Dans le cadre du projet, seul le front a été testé automatiquement

Et la qualité du code?

Coder
Lint
phpmd
phpcd

Tests de performances

JMeter
Gatling? en Scala

Outils utilisés

Déploiement en environnement de dév -> Capistrano
Validation -> PHPUnit + cURL

Capistrano

Permet de faire de déploiement parallélisé via un domaine spécifique Il permet de déployer les fichiers spécifiques aux devs et ne pas se préoccuper des fichiers spécifiques à l’environnement.

Permet de sauvegarder l’ancienne version du code, partage des fichiers de config

Quasi plus besoin d’actions manuelles sur le serveur au final.

Smoke Tests

Permet de détecter les “fuites” coté Front

Succession de curl
- home en HTTP 200
- Pas de blocs d’erreurs
- Pas de 404 sur les assets
- Blocs importants bien présents

Comment on monitore?

Buildwall Jenkins

Et les tests unitaires dans tout ça?

Uniquement sur le front dans le cadre de ce projet
SimpleTest trop lent

Découpage pour la mise en production avec 2 taches

1 pour le merge de DEV vers PROD only
1 pour la mise en prod de la branch “mergée”

Coordonnées contact

twitter: @arnaudhuon mail: ahuon@octo.com

DrupalCamp Paris2013 - Magnifiez votre backend

Fri, 21 Jun 2013 01:14:28 +0100

Les formulaires peuvent être très long

Création d’un concept => FormMode basé sur le concept des ViewsMode : https://drupal.org/sandbox/Artusamak/1796634

Field Extra Widget : https://drupal.org/project/field_extrawidgets

Views Megarow => Edition en ligne dans le backend : https://drupal.org/project/views_megarow

Démo du Back Cartier

Bundle Switcher : https://drupal.org/project/bundleswitcher

Créer vos propres plugins pour l’api de views

Views Matrix

Gérer les transitions de workflow

Une 12ene de type d’entité Problématique avec les modules contrib qui ne gèrent que les nodes

Statefield: https://drupal.org/sandbox/damz/1550106

(hors session: https://drupal.org/sandbox/andypost/1114392)

Créer des variantes de certaines parties du contenus

avec propriétés et champs surchargeables

Objectif: Pas de duplication de nodes pour ce besoin

Entity override : https://drupal.org/project/entity_override

Utiliser aussi pour la traduction!! Exportable dans des features Est capable de créer l’entité cible.

Module Tree + TreeField

Device Management

EntityBundlePlugin : https://drupal.org/project/entity_bundle_plugin ?

Synchronisation des contenus via Migration et XMLRPC

Le backend a été implémenté comme un sous-projet à part en tiers 18 mois du 1er jour à la mise en ligne 1 => Par contre les nouveaux sites sont simples à mettre en ligne

1 master pour piloter tous les sites, choisir si le site est Ecommerce ou non. Les frontaux sont totalement passifs.

Jean-Yves Gastaud blog

Faire tourner GitLab CI sur Cloudflare Workers & Containers : un exécuteur GitLab Runner maison

Pourquoi ce projet

Comment ça s’articule

Objectifs atteints

services:, cache:, artifacts: : comment ça marche concrètement

Ce que le déploiement réel a révélé

Sécuriser l’API du control plane

Limites actuelles / reste à faire

Liens vers le projet

Installer et configurer Renovate Bot sur GitLab CE

Prérequis

Initialisation

Structure de projets

Utilisateur Gitab

Configuration du projet renovate-runner

Création des tokens utilisateurs (PAT : Personal Access Token)

GitLab

GitHub

Notre fichier .gitlab-ci.yml

Fichier de configuration Renovate

Tâche récurrente

Configuration des configurations par défaut

Activer le bot pour les projets

Test de Gomplate

Objectifs

Le projet

Préparation

Découverte du fonctionnement de l’outil

Comment déclarer un template ?

Test avec 1 seul template en entrée

Test avec plusieurs fichiers de template

Implémentation du projet

Préparation des dossiers et fichiers

Exécution et vérification

Conclusion

Prochaines étapes

Git - Trier les tags d'un repo utilisant du semantic versioning

Mettre à jour Buildx dans Docker CLI

Les étapes

Démo

Azure-cli, activer l'auto-complétion sur Zsh

Notes complémentaires

Gitlab CI, After Script et Merge Request

Le script final

Details

Préparation

Le script

After script

Quelques cas d’usage possibles

Test de Ansible Molecule

Objectifs

Le projet

Préparation

Implémentation

Générer un nouveau rôle Ansible avec Molecule

Définir son playbook de tests

Écrire des tests avec testinfra

Lancer les tests

Les comandes essentielles

Résumé

Conclusion

Prochaines étapes

Git - Tips & Tricks

Visualiser son historique

Visualiser l’historique des logs de la branche courante

Améliorer l’affichage de ses logs

Comparer 2 branches

Vérifier / modifier ce que l’on commit

Découper ses modifications en plusieurs commits

Faire un diff sur un nouveau fichier

Commiter tous les fichiers modifiés

Ajout interactif

Ajout interactif de fichiers jamais commités

Corriger son dernier commit

Corriger un précédent commit

Version 1

Version 2

Faire un rebase en incluant le tout 1er commit

Squash VS Fixup

`services:`, `cache:`, `artifacts:` : comment ça marche concrètement

Notre fichier `.gitlab-ci.yml`

`format-patch`

`diff`

Création d’un nouveau bundle `headless-img`

Si vous devez rendre plusieurs fichiers .md en se basant sur un nom. `img1`, `img2`… par l’exemple