Quand je compilais mon site en local, les dates et heures étaient correctes, mais dès que je déployais sur GitHub celles-ci n’étaient plus bonnes. Et là ça m’a sauté aux yeux : mon ordi et GitHub n’étaient pas sur le même fuseau horaire ! Du coup, j’ai cherché si il y avait possibilité de changer le fuseau horaire de GitHub et effectivement, pour un site généré avec Jekyll, il existe le paramètre timezone à configurer dans le fichier _config.yml.

Du coup, pour passer mon site sur le fuseau horaire de Paris, rien de plus simple :

timezone: Europe/Paris

À première vu c’est assez chouette et simple à mettre en place, même si il semble qu’on soit obligé d’ajouter les metadata d’un post à chaque fois qu’on en crée un nouveau.
Il y a peut-être moyen de faire en sorte qu’il garde ça en mémoire, il faudra que je me penche là dessus.

Après, je ne sais pas si ça va bien se comporter comme Github Pages ne supporte visiblement pas ce plugin. J’imagine qu’il faudra que je fasse attention de ne pas faire de git commit du fichier config.yml, ou en tout cas de la ligne spécifiant “jekyll-admin” comme plugin.

Si jamais vous avez des astuces ou des ressources à partager sur ce plugin, n’hésitez pas à m’en parler sur Twitter

Pour la faire courte, la réponse est : non, pour l’instant.

Pourquoi GitHub Pages ne me convient pas ?

La plateforme est géniale, la mise à jour du blog sous Jekyll est instantanée à chaque git push origin master, plus besoin de lancer un jekyll build pour générer le site mis à jour, GitHub Pages s’occupe de tout !

Malheureusement, même si il est possible de forcer le HTTPS sur les pages du site, celui-ci doit obligatoirement avoir une URL du style https://username.github.io/repository. Impossible de forcer HTTPS si on veut utiliser son propre nom de domaine. Et comme j’avais déjà passé mon site en HTTPS il était hors de question de revenir en arrière, par principe.

Et puis, comme ça l’air de rien une petite newsletter OVH tombe dans ma boîte mail, proposant un nom de domaine en .me à -70%, du coup je me laisse tenter et puis une chose en entrainant une autre, je décide de prendre un petit VPS à pas cher…

Déployer Jekyll via GitHub

J’aime beaucoup GitHub, je m’en sert principalement pour sauvegarder quelques projets et ça m’évite de garder une copie sur un disque externe, je souhaitais donc pouvoir l’utiliser comme relai entre ma machine et le serveur, comme ça si il me prend l’envie de tout remettre à zéro, j’ai mes projets sauvés sur GitHub, un git clone et on en parle plus.

N’ayant jamais vraiment utilisé Linux, je me suis dit que c’était l’occasion. J’ai donc choisi de configurer mon VPS en distribution nue sous Debian 8 pour pouvoir installer uniquement ce dont j’avais besoin et laisser le plus de place possible pour mon site sur le disque dur. En gros : Apache, Git, Ruby et Let’s Encrypt.

Ici je n’expliquerai pas comment j’ai installé Apache, Git, Ruby et Let’s Encrypt. Je me contenterai de partager ma méthode pour déployer Jekyll.

Créer le dépôt Git distant

La première étape de ma méthode a consistée à créer un dépôt Git à la racine du VPS avec la commande suivante :

# connexion au VPS
ssh git@mon.vps
# création du dépôt distant
git clone --bare https://github.com/nighcrawl/jekyll-blog.git blog.git

Avec cette commande on clone le dépôt GitHub nu sur le VPS, c’est à dire en ne gardant que les fichiers normalement contenus dans .git/ dans le dossier blog.git/. Le dossier blog.git ressemble alors à ceci :

blog.git/
|_ HEAD/
|_ branches/
|_ config/
|_ description/
|_ hooks/
|  |_ post-receive
|  |_ post-update
|  |_ ...
|_ infos/
|_ objects/
|_ refs/

Le fichier intéressant ici est post-receive du dossier hooks/ car il va nous permettre d’executer un script bash à chaque fois qu’un git push sur le dépôt aura été complété.

Pour nous, il faudra lancer la génération du site avec Jekyll à chaque nouveau git push, le fichier post-receive contiendra alors le script suivant :

GIT_REPO=$HOME/blog.git
TMP_GIT_CLONE=$HOME/tmp/blog
PUBLIC_WWW=/var/www/blog

git clone $GIT_REPO $TMP_GIT_CLONE
bundle exec jekyll build -s $TMP_GIT_CLONE -d $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit

Ici on déclare plusieurs variable en début de script:

• GIT_REPO contient le chemin vers le dépôt Git,
• TMP_GIT_CLONE permet de définir où sera cloné le dépôt
• PUBLIC_WWW contiendra les fichiers du site une fois compilés avec Jekyll

Une fois le dépôt Git cloné dans $TMP_GIT_CLONE, on lance la commande de compilation des fichier bundle exec jekyll build en spécifiant le dossier $TMP_GIT_CLONE comme étant la source et $PUBLIC_WWW comme destination, puis on supprime le dossier $TMP_GIT_CLONE avec la commande rm -Rf $TMP_GIT_CLONE.

Créer le dépôt Git local

Une fois le dépôt distant créé et le fichier post-receive modifié, il ne reste plus qu’à cloné le dépôt sur l’ordinateur avec la commande

git clone https://github.com/nighcrawl/jekyll-blog.git

puis d’y ajouter votre dépôt distant comme remote supplémentaire avec la commande

git remote add deploy ssh://git@mon.vps:/blog.git

Déployer en production

Pour pousser les mises à jour vers le VPS il suffira alors de faire un git push en spécifiant le dépôt distant dans lequel vous souhaitez envoyer vos commits.

Ici le dépôt GitHub s’appelle origin et mon dépôt de production (sur le VPS) s’appelle deploy. La commande de mise à jour du VPS sera alors

git push deploy master

Fin

La méthode de déploiement que j’utilise ici est assez basique et pourra probablement être améliorée, alors n’hésitez pas à la partager, ou mieux me donner votre avis et/ou vos conseils sur Twitter.

Découverte de Jekyll

Je lisais régulièrement le mot Jekyll un peu partout sur le Web, sans trop savoir ce que c’était et sans vraiment m’y intéresser, pour tout dire. Et puis complètement par hasard, je suis tombé sur une série de vidéos YouTube sur la chaine DevTips et puis j’ai vu ce mec, Travis Neilson, se filmer tout au long de refonte de son portfolio, réfléchir à quels outils il souhaitait utiliser pour ce projet, comment il pourrait faire en sorte que tel élément apparaisse à tel moment à l’écran.

Le gars réfléchissait littéralement à ce qu’il voulait faire en même temps qu’il se filmait. J’ai trouvé ça vraiment très geek, mais j’ai bouffé sa série Design + Code my Personal Website in 12 hours en un week-end… Pour son projet il décidait d’utiliser Jekyll comme base de travail.

J’ai ensuite regardé d’autres vidéos et j’ai commencé à m’intéresser un peu plus à Jekyll, me disant que c’était peut-être la solution que je recherchais et je dois dire que depuis que j’ai commencé à jouer avec il y a quelques mois, je pense que c’est tout à fait ce qu’il me fallait.

Migration de WordPress vers Jekyll

La migration de mon contenu vers Jekyll a vraiment été très simple du côté de WordPress : il m’a suffit d’installer le plugin Jekyll Exporter depuis l’admin de mon installation WordPress, de lancer l’export et c’était fait. Le plus long a été de repasser ensuite dans chaque fichier Markdown pour supprimer certaines données du front matter qui n’étaient plus utiles ou mal renseignées, remettre correctement en forme certains bouts de code partagés dans mes articles, ce genre de petit détails.

Par contre, je ne souhaite pas encore héberger mon site sur Github Pages, mais je l’envisage. Peut-être lorsque mon offre d’hébergement chez OVH arrivera proche de son terme. On verra bien.

Je n’expliquerai pas plus comment je suis passé de WordPress à Jekyll, d’autres le font très bien pour moi :

• Nicolas Carlo dans son article Faire son blog avec Jekyll
• Tomomi Imura avec son article How-to: Migrating Blog from WordPress to Jekyll, and Host on Github
• Et bien sur le site de Jekyll