AlpineLab blog technique

Pour ce blog j'utilise Middleman, j'ai donc un repository pour les sources. Mais dès qu'il s'agit de déployer (i.e. compiler puis pusher les fichiers compilés sur un autre repository, que github:pages reconnait comme devant les mettre en ligne), voilà la séquence de commandes que je dois executer :

$ git push
$ middleman build --clean
$ middleman deploy --clean

Épuisant.

J'ai donc besoin d'un moyen d'éxécuter toutes ces commandes d'un coup. Comme un alias ou un scriptshell seraient trop faciles, j'ai regardé du côté des alias git.

En gros, je veux pouvoir tout simplement entrer :

$ git dpush # 'dpush' commme 'deploy & push'

Il suffit donc de déclarer un alias git comme ça :

$ git config alias.dpush '!git push origin master && middleman build --clean && middleman deploy --clean'

Cette commande va ajouter les lignes suivantes au fichier .git/config :

[alias]
  dpush = !git push origin master && middleman build --clean && middleman deploy --clean

Voilà, plus qu'à executer git dpush pour pusher son code, compiler, puis déployer un nouvel article.

Notes

1. Le point d'exclamation (!) en première position de l'alias sert à indiquer que c'est une commande à part entière. Sans ce point d'exclamation, les alias portent par défaut sur d'autres commandes git. Genre, pour pouvoir écrire git st au lieu de git status, comme piouPiouM : [alias] st = status
2. Comme on le déclare ici, l'alias est local : il ne s'applique qu'au repository courant (d'ailleurs il est stocké dans .git/config qui est la config du repository courant uniquement). Pour créer un alias qui fonctionne partout, il faut utiliser le switch --global : l'alias sera alors déclaré non pas dans .git/config mais dans ~/.gitconfig et sera donc accessible dans tous vos repository git.

Sources

Tout est parti d’une réponse sur StackOverflow

Comment utiliser son beau nom de domaine qu'on vient de réserver pour son site hébergé sur GitHub Pages ? En fait c'est très simple et tout est expliqué dans la documentation officielle (RTFM, comme on dit).

Configuration de GitHub Pages

Il faut tout d'abord créer un fichier CNAME à la racine de son site qui contient le nom de domaine qu'on veut utiliser (moi, pour ce blog, c'est www.alpine-lab.com). Comme j'utilise Middleman, ça donne donc ça (la racine du site est dans le sous-répertoire source) :

$ echo "www.alpine-lab.com" > source/CNAME

Voilà, c'est tout.

Une fois cette modification déployée, GitHub Pages saura que quand un navigateur lui demande www.alpine-lab.com, il devra répondre avec notre site.

Comme il est malin, il va créer automatiquement certaines redirections. Là, dans notre exemple, si on pointe son navigateur sur alpinelab.github.com (l'adresse d'origine), il nous redirigera automatiquement sur www.alpine-lab.com. Même chose avec alpine-lab.com (sans les www). Pratique, non ?

Configuration DNS

Tout ce qu'il reste à faire, c'est quand même configurer votre serveur DNS pour que www.alpine-lab.com et alpine-lab.com soient redirigés vers l'adresse IP de GitHub Pages (entrée A dans votre config DNS) 204.232.175.78 ou vers le nom de domaine (entrée CNAME) alpinelab.github.com.

Voilà à quoi ressemble la conf DNS, chez moi :

Voilà. C'est tout bon.

Bonus : patience !

GitHub Pages peut mettre jusqu'à 10 minutes pour réagir et se rendre compte qu'on lui a pushé un fichier CNAME. Inutile de péter un cable parce que ça ne marche pas immédiatement, il faut parfois simplement attendre. Je dis ça parce que ça m'est arrivé.

Sources

• La documentation officielle de GitHub Pages

Quand vous développez (en Ruby, entre autres), vous écrivez des tests, n'est-ce pas ? Carrément en TDD ou au moins pour assurer la non-régression, j'espère. Le problème est : comment être sûr que tout votre code est bien testé ? Que vous n'avez pas un peu zappé d'écrire de tests pour telle méthode ou telle classe ?

La réponse s'appelle la couverture de code (“code coverage”, en anglais). Ça consiste à calculer le pourcentage de votre code qui est couvert par des tests. La chance, c'est qu'en Ruby, si votre code est hébergé sur GitHub, il existe une solution en SaaS qui fait ça toute seule : Coveralls !

Inscription

Il faut en premier lieu s'inscrire sur Coveralls.io, mais grâce à l'authentification GitHub, c'est fait en 2 clics.

Coveralls vous demandera ensuite sur quels repositories vous voulez l'activer avec des petits boutons on/off très intuitifs (comme souvent, c'est gratuit pour les projets open-source, payant pour les projets privés) :

Installation

Comme d'habitude, c'est super simple, il y a une gem à ajouter à votre fichier Gemfile :

gem 'coveralls', require: false

Puis, il suffit de faire un bundle install pour l'installer.

Enfin, il faut dire à notre suite de tests d'utiliser la gem, en ajoutant les lignes suivantes au fichier de config de votre suite de tests (moi j'utilise RSpec donc c'est spec/spec_helper.rb, mais je vous laisse adapter à votre suite de test : Coveralls est compatible entre-autres avec RSpec, Cucumber, Test::Unit, …) :

require 'coveralls'
Coveralls.wear!

Ou, pour une application Rails :

require 'coveralls'
Coveralls.wear!('rails')

Configuration

Si vous utilisez Travis, c'est très simple : il n'y a rien de plus à faire ! Dès votre prochain push, Travis devrait donc tester votre build, et envoyer le rapport à Coveralls, qui calculera en détail la couverture de votre code.

Si vous utilisez Semaphore ou CircleCI, ça marche aussi, mais je n'ai pas testé : je vous laisse vous reporter à la documentation.

Si vous n'utilisez pas de service d'intégration continue, je vous conseille de vous y mettre rapidement, c'est de la tuerie. Moi j'adore Travis, et en plus, il est gratuit pour les projets open-source. Sinon, pour Coveralls, vous pouvez le configurer (en ajoutant une variable repo_token à un fichier .coveralls.yml) pour pouvoir faire des analyse de couverture à la main, avec un simple bundle exec coveralls push.

Résultat

Sur le site de Coveralls, vous pouvez donc voir un résumé de votre projet, build par build :

Pour chaque build, un résumé fichier par fichier :

Et enfin, le truc le plus utile et productif : pour chaque fichier, le détail de couverture ligne par ligne :

Là, par exemple, on voit que je n'ai pas écris de test pour la méthode download_best_subtitle, ce que je peux donc m'empresser d'aller faire.

Bonus : le badge GitHub

On peut même récupérer le code pour insérer un badge dans notre README, pour avoir la classe américaine sur GitHub :

Sources

• Le site de Coveralls
• La doc Coveralls pour Ruby