Afficher/cacher Sommaire
GitLab Pages
Qu’est-ce que nous allons accomplir avec ce how-to ?
Dans ce mode d’emploi, nous vous apprendrons comment faire votre premier cas d’utilisation de GitLab Pages avec un exemple simple en html - similaire à la façon dont cette page a été créée. Les utilisations des Pages GitLab sont beaucoup plus étendues que ce qui sera couvert ici. Si vous cherchez des exemples de projets, voir ci-dessous.
Ce tutoriel suppose que vous avez une clé SSH sur votre machine et que vous comprenez comment utiliser Git avec GitLab.
Étape 1.) Créer un projet dans GitLab
Créer un projet
- Connectez-vous à votre profil
- Créez un projet avec un nom génial.
- Sauvegardez votre projet génial
Si vous avez besoin d’une aide plus concise pour accomplir cette étape, consultez cet article.
Étape 2.) Coder les choses
Faire un site HTML de base
Cette étape peut être complétée par un bref aperçu HTML.
- Créez un dossier sur votre ordinateur et placez-y un répertoire nommé public.
- Télécharger le plan HTML ici. Ou faites les vôtres.
- Sauvegardez le contour HTML et placez-le dans votre dossier local/public.
- Si vous décidez que vous voulez CSS - assurez-vous de mettre tout le contenu dans votre répertoire public.
Vous pouvez également utiliser un générateur de site statique qui utilise un framework pré-construit dans la langue de votre choix.
Étape 3.) Configurez votre fichier YAML (.yml)
Votre fichier YAML est ce qui désigne vos cycles de construction et vos environnements.
Avec de nombreux SSG, vous pouvez trouver un fichier.yml prédéfini sur lequel vous devrez peut-être modifier légèrement si vous utilisez un environnement comme docker et l’ordre que vous aimeriez qu’il soit construit à travers vos environnements.
L’exemple que GitLab utilise dans sa documentation YAML touche à un Ruby SSG, appelé Jekyll. Pour l’exemple ici, le fichier.yml aura l’air similaire mais utilisera l’image légère de Linux Alpine pour construire. Vous remarquerez peut-être aussi que ce mode d’emploi ne couvre pas les “runners” partagés ou spécifiques. C’est parce qu’il y a déjà quelques runners partagés et votre build les utilisera automatiquement ; cependant, vous êtes plus que bienvenu pour faire un runner spécifique à utiliser pour votre projet seul.
N’hésitez pas à télécharger le fichier.yml à partir de l’exemple de repo ici, ou suivez les instructions ci-dessous.
- Créez un nom de fichier .gitlab-ci.yml et enregistrez-le à la racine de votre dossier local.
- Commencez par lister le type d’image que vous utilisez, dans ce cas vous voulez la dernière version de alpine : image : alpine:latest
- Vous pouvez désigner votre runner pour construire à partir de n’importe quelle branche, mais dans cet exemple, vous ne voudrez que pousser vers la branche par défaut (master) à déployer sur votre site web. Pour ce faire, nous devons ajouter quelques lignes supplémentaires à notre fichier.yml, en disant au Runner de n’exécuter que le travail appelé pages (tout ce qui se trouve dans le répertoire public) sur la branche maître seulement - ce qui en résulte :
- C’est tout ce dont vous avez besoin pour commencer ! Si vous construisez un exemple plus complexe, jetez un coup d’oeil à cet article qui énumère toutes les variables de construction. Ces variables ont déjà subi quelques changements, il est donc bon de mettre un signet. ;)
Étape 5.) Poussez vos actifs - regardez comment ils se construisent !
Maintenant que nous avons tout composé, nous sommes prêts à affecter tous les actifs que nous avons à notre projet GitLab.
Dès que vous suivez les ensembles ci-dessous pour tout pousser en même temps, vous allez aussi pousser automatiquement votre code à travers le pipeline et le faire construire par un runner partagé déjà configuré.
Les étapes suivantes décrivent comment faire avancer un projet existant. Si vous savez comment faire, n’hésitez pas à sauter. :)
cd existing_folder
git init
git remote add origin git@gitlab.com:USERNAME/NAME_OF_REPO.git
git add .
git commit
git push -u origin master
Si vous obtenez une erreur en poussant, soit vous n’avez pas de clé SSH, soit vous avez un jeton d’accès personnel correctement configuré. Si vous savez que votre clé SSH est correctement configurée et que cela a échoué, il est probable que vous avez indiqué votre distant comme une adresse HTTPS au lieu de SSH. Apprenez comment changer l’adresse de votre distant ici.
Maintenant, si vous visitez votre projet sur gitlab.com, vous pouvez voir si votre construction a été corrigée par l’état du pipeline en notant “passed” au-dessus de vos fichiers dans la vue du projet.
Étape 6.) Visitez votre site
Maintenant vient la partie amusante ! Voyons à quoi ressemble notre page.
Vous pouvez visiter votre site en naviguant vers : https://USERNAME.pages.gitlab.com/NAME_OF_YOUR_PROJECT ou en suivant les instructions ci-dessous.
- Naviguez jusqu’aux paramètres de vos projets.
- Sélectionnez Pages dans le sous-menu.
- Cliquez sur le lien vers votre page, situé au milieu de l’écran.
Annexe
Fichier .gitlab-ci.yml
image: alpine:latest
pages:
stage: deploy
script:
- echo 'Nothing to do...'
artifacts:
paths:
- public
only:
- master
test:
script:
- echo "This command runs on any branch casue I didn't specify 'only'. Also notice how the jobs are done differently."
- echo "You can run more then one too, and it could just be a script that you run that does all the things."