Deux façons de déployer un site de pages GitHub public à partir d'un référentiel Hugo privé

Protégez vos brouillons de la vue du public en utilisant des outils de déploiement continu pour publier votre site de pages GitHub public, à partir d'un référentiel privé distinct.

Des outils tels que Travis CI et Netlify offrent des fonctionnalités très intéressantes, comme le déploiement transparent de votre site Pages GitHub lorsque les modifications sont transmises à son référentiel. Avec un générateur de site statique comme Hugo, garder un blog à jour est assez simple.

J'ai utilisé Hugo pour créer mon site pendant des années, mais jusqu'à la semaine dernière, je n'avais jamais connecté mon référentiel Pages à un service de déploiement. Pourquoi? Parce que l'utilisation d'un outil qui a construit mon site avant de le déployer semblait nécessiter d'avoir toute la recette au même endroit - et si vous utilisez des pages GitHub avec la version gratuite de GitHub, cet endroit est public. Cela signifie que toutes mes idées brillantes de trois heures du matin et mes brouillons désordonnés inachevés (et pas drôles) seraient accessibles au public - et aucune commodité continue n'allait me convaincre de le faire.

J'ai donc gardé les choses séparées, avec les coulisses désordonnées d'Hugo dans un référentiel Git local, et le public/dossier généré poussant vers mon référentiel distant GitHub Pages. Chaque fois que je voulais déployer mon site, je devais monter sur mon ordinateur portable et hugoconstruire mon site, puis cd public/ && git add . && git commit… etc etc. Et tout allait bien, à part le sentiment lancinant qu'il y avait une meilleure façon de le faire.

J'ai écrit un autre article il y a quelque temps sur l'utilisation de GitHub et de Working Copy pour apporter des modifications à mes référentiels sur mon iPad chaque fois que je suis en déplacement. Il me semblait que je pouvais tout faire sauf déployer mon site à partir de mon iPad, alors j'ai décidé de changer cela.

Quelques idées brillantes de trois heures du matin et un jeton d'accès révoqué plus tard (oups), je n'ai maintenant pas une mais deux façons de déployer sur mon référentiel GitHub Pages public à partir d'un référentiel GitHub privé entièrement séparé. Dans cet article, je vais vous expliquer comment y parvenir avec Travis CI ou en utilisant Netlify et Make.

Il n'y a rien de piraté à ce sujet - mon référentiel public de pages GitHub a toujours le même aspect que lorsque je l'ai poussé localement depuis mon terminal. Ce n'est que maintenant que je peux profiter de quelques excellents outils de déploiement pour mettre à jour le site chaque fois que je pousse vers mon dépôt privé, que je sois sur mon ordinateur portable ou en déplacement avec mon iPad.

Cet article suppose que vous avez une connaissance pratique des pages Git et GitHub. Sinon, vous voudrez peut-être supprimer certains onglets de navigateur de mes articles sur l'utilisation de GitHub et de la copie de travail et de créer d'abord un site avec Hugo et GitHub Pages.

Faisons le!

Déploiement de pages GitHub privées vers publiques avec Travis CI

Travis CI a la capacité intégrée (♪) de se déployer sur les pages GitHub après une compilation réussie. Ils font un travail décent dans la documentation pour expliquer comment ajouter cette fonctionnalité, surtout si vous avez déjà utilisé Travis CI ... ce que je n'ai pas fait. Ne vous inquiétez pas, j'ai fait le gros du travail pour vous.

  • Travis CI obtient toutes ses instructions à partir d'un fichier de configuration à la racine de votre référentiel appelé .travis.yml
  • Vous devez fournir un jeton d'accès personnel GitHub en tant que variable chiffrée sécurisée, que vous pouvez générer à l'aide travisde la ligne de commande
  • Une fois que votre script a terminé avec succès ce que vous lui avez dit de faire (pas nécessairement ce que vous voulez qu'il fasse mais c'est un tout autre article de blog), Travis déploiera votre répertoire de construction dans un référentiel que vous pouvez spécifier avec la repovariable de configuration.

Configuration du fichier de configuration Travis

Créez un nouveau fichier de configuration pour Travis avec le nom de fichier .travis.yml(notez le début «.»). Ces scripts sont très personnalisables et j'ai eu du mal à trouver un exemple pertinent à utiliser comme point de départ - heureusement, vous n'avez pas ce problème!

Voici mon basique .travis.yml:

git: depth: false env: global: - HUGO_VERSION="0.54.0" matrix: - YOUR_ENCRYPTED_VARIABLE install: - wget -q //github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz - tar xf hugo_${HUGO_VERSION}_Linux-64bit.tar.gz - mv hugo ~/bin/ script: - hugo --gc --minify deploy: provider: pages skip-cleanup: true github-token: $GITHUB_TOKEN keep-history: true local-dir: public repo: gh-username/gh-username.github.io target-branch: master verbose: true on: branch: master

Ce script télécharge et installe Hugo, crée le site avec le ramasse-miettes et minimise les indicateurs, puis déploie le public/répertoire dans le répertoire spécifié repo- dans cet exemple, votre référentiel de pages GitHub public. Vous pouvez en savoir plus sur chacune des deployoptions de configuration ici.

Pour ajouter le jeton d'accès personnel GitHub en tant que variable chiffrée, vous n'avez pas besoin de modifier manuellement votre fichier .travis.yml. Les traviscommandes gem ci-dessous chiffreront et ajouteront la variable pour vous lorsque vous les exécuterez dans votre répertoire de référentiel.

Tout d'abord, installez travisavec sudo gem install travis.

Puis générez votre jeton d'accès personnel GitHub, copiez-le (il n'apparaît qu'une fois!) Et exécutez les commandes ci-dessous dans la racine de votre référentiel, en remplaçant votre jeton par les bisous:

travis login --pro --github-token xxxxxxxxxxxxxxxxxxxxxxxxxxx travis encrypt GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxx --add env.matrix

Votre jeton crypté apparaît comme par magie dans le fichier. Une fois que vous vous êtes engagé .travis.ymldans votre référentiel Hugo privé, Travis CI exécutera le script et si la construction réussit, déploiera votre site sur votre référentiel de pages GitHub public. La magie!

Travis exécutera toujours une compilation chaque fois que vous poussez vers votre référentiel privé. Si vous ne souhaitez pas déclencher ce comportement avec une validation particulière, ajoutez la skipcommande à votre message de validation.

Yo c'est cool mais j'aime Netlify.

Très bien.

Déploiement dans un référentiel séparé avec Netlify et Make

Nous pouvons demander à Netlify de faire nos enchères en utilisant un Makefile, que nous exécuterons avec la commande build de Netlify.

Voici à quoi Makefileressemble notre :

SHELL:=/bin/bash BASEDIR=$(CURDIR) OUTPUTDIR=public .PHONY: all all: clean get_repository build deploy .PHONY: clean clean: @echo "Removing public directory" rm -rf $(BASEDIR)/$(OUTPUTDIR) .PHONY: get_repository get_repository: @echo "Getting public repository" git clone //github.com/gh-username/gh-username.github.io.git public .PHONY: build build: @echo "Generating site" hugo --gc --minify .PHONY: deploy deploy: @echo "Preparing commit" @cd $(OUTPUTDIR) \ && git config user.email "[email protected]" \ && git config user.name "Your Name" \ && git add . \ && git status \ && git commit -m "Deploy via Makefile" \ && git push -f -q //$(GITHUB_TOKEN)@github.com/gh-username/gh-username.github.io.git master @echo "Pushed to remote"

Pour conserver l'historique Git de notre référentiel GitHub Pages séparé, nous allons d'abord le cloner, y créer notre nouveau site Hugo, puis le repousser dans le référentiel Pages. Ce script supprime d'abord tout public/dossier existant pouvant contenir des fichiers ou un historique Git. Il clone ensuite notre référentiel Pages public/, construit notre site Hugo (essentiellement en mettant à jour les fichiers dans public/), puis s'occupe de valider le nouveau site dans le référentiel Pages.

Dans la deploysection, vous remarquerez des lignes commençant par &&. Ce sont des commandes enchaînées. Puisque Make invoque un nouveau sous-shell pour chaque ligne, il recommence à chaque nouvelle ligne de notre répertoire racine. Pour que nous nous cden tenions et éviter d'exécuter nos commandes Git dans le répertoire racine du projet, nous enchaînons les commandes et utilisons la barre oblique inverse pour couper les longues lignes pour plus de lisibilité.

En chaînant nos commandes, nous pouvons configurer notre identité Git, ajouter tous nos fichiers mis à jour et créer un commit pour notre référentiel Pages.

De même que pour l'utilisation de Travis CI, nous devrons transmettre un jeton d'accès personnel GitHub pour pousser vers notre référentiel public de pages GitHub - seul Netlify ne fournit pas un moyen simple de chiffrer le jeton dans notre Makefile.

Au lieu de cela, nous utiliserons les variables d'environnement de construction de Netlify, qui vivent en toute sécurité dans les paramètres de notre site dans l'application Netlify. Nous pouvons ensuite appeler notre variable de jeton dans le Makefile. Nous l'utilisons pour pousser (discrètement, pour éviter d'imprimer le jeton dans les journaux) vers notre référentiel Pages en le passant dans l'URL distante.

Pour éviter d'imprimer le jeton dans les journaux de Netlify, nous supprimons l'écho de recette pour cette ligne avec le @caractère principal .

Avec votre Makefile à la racine de votre référentiel GitHub privé, vous pouvez configurer Netlify pour l'exécuter pour vous.

Configurer Netlify

La configuration de Netlify via l'interface utilisateur Web est simple. Une fois que vous vous êtes connecté avec GitHub, choisissez le référentiel GitHub privé où réside votre site Hugo. La page suivante Netlify vous permet de saisir les paramètres de déploiement:

Vous pouvez spécifier la commande de construction qui exécutera votre Makefile ( make allpour cet exemple). La branche à déployer et le répertoire de publication n'ont pas trop d'importance dans notre cas spécifique, car nous ne nous préoccupons que de pousser vers un référentiel séparé. Vous pouvez entrer la masterbranche de déploiement typique et le publicrépertoire de publication.

Sous «Paramètres de construction avancés», cliquez sur «Nouvelle variable» pour ajouter votre jeton d'accès personnel GitHub en tant que variable d'environnement de construction. Dans notre exemple, le nom de la variable est GITHUB_TOKEN. Cliquez sur «Déployer le site» pour que la magie opère.

Si vous avez déjà configuré votre référentiel avec Netlify, recherchez les paramètres de déploiement continu sous Paramètres> Construire et déployer.

Netlify will build your site each time you push to the private repository. If you don’t want a particular commit to trigger a build, add [skip ci] in your Git commit message.

Same same but different

One effect of using Netlify this way is that your site will be built in two places: one is the separate, public GitHub Pages repository that the Makefile pushes to, and the other is your Netlify site that deploys on their CDN from your linked private GitHub repository. The latter is useful if you’re going to play with Deploy Previews and other Netlify features, but those are outside the scope of this post.

The main point is that your GitHub Pages site is now updated in your public repo. Yay!

Go forth and deploy fearlessly

I hope the effect of this new information is that you feel more able to update your sites, wherever you happen to be. The possibilities are endless — at home on your couch with your laptop, out cafe-hopping with your iPad, or in the middle of a first date on your phone. Endless!