doc-locale/fr-fr/user/project/pages/_index.md
{{< details >}}
{{< /details >}}
GitLab Pages publie des sites web statiques directement depuis un dépôt dans GitLab.
Ces sites web :
Pour publier un site web avec Pages, utilisez tout générateur de site statique comme Gatsby, Jekyll, Hugo, Middleman, Harp, Hexo ou Brunch. Pages prend également en charge les sites web écrits directement en HTML, CSS, JavaScript et Wasm bruts. Le traitement dynamique côté serveur (comme .php et .asp) n'est pas pris en charge. Pour en savoir plus, consultez Sites web statiques vs dynamiques.
Pour créer un site web GitLab Pages :
| Document | Description |
|---|---|
Utiliser l'interface utilisateur GitLab pour créer un fichier .gitlab-ci.yml simple | Ajouter un site Pages à un projet existant. Utilisez l'interface utilisateur pour configurer un fichier .gitlab-ci.yml simple. |
Créer un fichier .gitlab-ci.yml de zéro | Ajouter un site Pages à un projet existant. Apprenez à créer et configurer votre propre fichier CI. |
Utiliser un modèle .gitlab-ci.yml | Ajouter un site Pages à un projet existant. Utilisez un fichier de modèle CI pré-rempli. |
| Dupliquer un projet d'exemple | Créer un nouveau projet avec Pages déjà configuré en dupliquant un projet d'exemple. |
| Utiliser un modèle de projet | Créer un nouveau projet avec Pages déjà configuré en utilisant un modèle. |
Pour mettre à jour un site web GitLab Pages :
| Document | Description |
|---|---|
| Noms de domaine, URLs et URLs de base GitLab Pages | En savoir plus sur les domaines par défaut de GitLab Pages. |
| Explorer GitLab Pages | Prérequis, aspects techniques, options de configuration spécifiques à GitLab CI/CD, contrôle d'accès, pages 404 personnalisées, limitations et FAQ. |
| Domaines personnalisés et certificats SSL/TLS | Domaines et sous-domaines personnalisés, enregistrements DNS et certificats SSL/TLS. |
| Intégration Let's Encrypt | Sécurisez vos sites Pages avec les certificats Let's Encrypt, qui sont automatiquement obtenus et renouvelés par GitLab. |
| Redirections | Configurez des redirections HTTP pour transférer une page vers une autre. |
Pour plus d'informations, consultez :
| Document | Description |
|---|---|
| Sites web statiques vs dynamiques | Aperçu des sites statiques versus dynamiques. |
| Générateurs de sites statiques modernes | Aperçu des SSG. |
| Créer n'importe quel site SSG avec GitLab Pages | Utiliser des SSG pour GitLab Pages. |
Pour utiliser GitLab Pages, vous devez créer un projet dans GitLab afin d'y téléverser les fichiers de votre site web. Ces projets peuvent être publics, internes ou privés.
Par défaut, GitLab déploie votre site web depuis un dossier spécifique appelé public dans votre dépôt. Vous pouvez également définir un dossier personnalisé à déployer avec Pages. Lorsque vous créez un nouveau projet dans GitLab, un dépôt devient automatiquement disponible.
Pour déployer votre site, GitLab utilise son outil intégré appelé GitLab CI/CD pour construire votre site et le publier sur le serveur GitLab Pages. La séquence de scripts que GitLab CI/CD exécute pour accomplir cette tâche est créée à partir d'un fichier nommé .gitlab-ci.yml, que vous pouvez créer et modifier. Un job défini par l'utilisateur avec la propriété pages: true dans le fichier de configuration indique à GitLab que vous déployez un site web GitLab Pages.
Vous pouvez utiliser le domaine par défaut de GitLab Pages, *.gitlab.io, ou votre propre domaine (example.com). Dans ce cas, vous devez être administrateur auprès du registraire de votre domaine (ou panneau de contrôle) pour le configurer avec Pages.
Si vous utilisez le domaine par défaut de GitLab Pages (.gitlab.io), votre site web est automatiquement sécurisé et disponible via HTTPS. Si vous utilisez votre propre domaine personnalisé, vous pouvez éventuellement le sécuriser avec des certificats SSL/TLS.
Si vous utilisez GitLab.com, votre site web est accessible publiquement sur internet. Pour restreindre l'accès à votre site web, activez le contrôle d'accès GitLab Pages.
Si vous utilisez une instance GitLab Self-Managed, vos sites web sont publiés sur votre propre serveur, selon les paramètres Pages choisis par votre administrateur système, qui peut les rendre publics ou internes.
Ces exemples de sites web GitLab Pages vous permettent d'apprendre des techniques avancées à utiliser et à adapter selon vos besoins :
Si vous exécutez une instance GitLab Self-Managed, suivez les étapes d'administration pour configurer Pages.
<i class="fa-youtube-play" aria-hidden="true"></i> Regardez un tutoriel vidéo sur la prise en main de l'administration de GitLab Pages.
Pour configurer GitLab Pages sur des instances déployées avec Helm chart (Kubernetes), utilisez l'une ou l'autre des options suivantes :
. {#namespaces-that-contain-}Si votre nom d'utilisateur est example, votre site web GitLab Pages est situé à l'adresse example.gitlab.io. GitLab autorise les noms d'utilisateur à contenir un ., donc un utilisateur nommé bar.example pourrait créer un site web GitLab Pages bar.example.gitlab.io qui est effectivement un sous-domaine de votre site web example.gitlab.io. Soyez prudent si vous utilisez JavaScript pour définir des cookies pour votre site web. La méthode sûre pour définir manuellement des cookies avec JavaScript est de ne pas spécifier le domain du tout :
// Safe: This cookie is only visible to example.gitlab.io
document.cookie = "key=value";
// Unsafe: This cookie is visible to example.gitlab.io and its subdomains,
// regardless of the presence of the leading dot.
document.cookie = "key=value;domain=.example.gitlab.io";
document.cookie = "key=value;domain=example.gitlab.io";
Ce problème n'affecte pas les utilisateurs disposant d'un domaine personnalisé, ni ceux qui ne définissent pas de cookies manuellement avec JavaScript.
Par défaut, chaque projet d'un groupe partage le même domaine, par exemple group.gitlab.io. Cela signifie que les cookies sont également partagés pour tous les projets d'un groupe.
Pour que chaque projet utilise des cookies différents, activez la fonctionnalité domaines uniques de Pages pour votre projet.
{{< history >}}
pages_unique_domain. Désactivé par défaut.{{< /history >}}
Par défaut, chaque nouveau projet utilise des domaines uniques Pages pour éviter que les projets d'un même groupe ne partagent des cookies.
Le mainteneur du projet peut désactiver cette fonctionnalité sur :
Pour des exemples d'URLs, consultez Noms de domaine par défaut GitLab Pages.
{{< history >}}
{{< /history >}}
Lorsque vous utilisez GitLab Pages avec des domaines personnalisés, vous pouvez rediriger toutes les requêtes vers GitLab Pages vers un domaine principal. Lorsque le domaine principal est sélectionné, les utilisateurs reçoivent un statut 308 Permanent Redirect qui redirige le navigateur vers le domaine principal sélectionné. Les navigateurs peuvent mettre en cache cette redirection.
Prérequis :
{{< history >}}
{{< /history >}}
Vous pouvez configurer vos déploiements Pages pour qu'ils soient automatiquement supprimés après un certain délai en spécifiant une durée dans pages.expire_in :
create-pages:
stage: deploy
script:
- ...
pages: # specifies that this is a Pages job and publishes the default public directory
expire_in: 1 week
Les déploiements expirés sont arrêtés par un cron job qui s'exécute toutes les 10 minutes. Les déploiements arrêtés sont ensuite supprimés par un autre cron job qui s'exécute également toutes les 10 minutes. Pour le récupérer, suivez les étapes décrites dans Récupérer un déploiement arrêté.
Un déploiement arrêté ou supprimé n'est plus disponible sur le web. Une page d'erreur 404 Non trouvé s'affiche à son URL, jusqu'à ce qu'un autre déploiement soit créé avec la même configuration d'URL.
L'exemple YAML précédent utilise des noms de job définis par l'utilisateur.
Prérequis :
Pour récupérer un déploiement arrêté qui n'a pas encore été supprimé :
Pour supprimer un déploiement :
Lorsque vous sélectionnez Supprimer, votre déploiement est arrêté immédiatement. Les déploiements arrêtés sont supprimés par un cron job s'exécutant toutes les 10 minutes.
Pour restaurer un déploiement arrêté qui n'a pas encore été supprimé, consultez Récupérer un déploiement arrêté.
{{< history >}}
customizable_pages_job_name, désactivé par défaut.customizable_pages_job_name a été supprimé.{{< /history >}}
Pour déclencher un déploiement Pages depuis n'importe quel job, incluez la propriété pages dans la définition du job. Il peut s'agir soit d'un booléen défini à true, soit d'un hash.
Par exemple, en utilisant true :
deploy-my-pages-site:
stage: deploy
script:
- npm run build
pages: true # specifies that this is a Pages job and publishes the default public directory
Par exemple, en utilisant un hash :
deploy-pages-review-app:
stage: deploy
script:
- npm run build
pages: # specifies that this is a Pages job and publishes the default public directory
path_prefix: '_staging'
Si la propriété pages d'un job nommé pages est définie à false, aucun déploiement n'est déclenché :
pages:
pages: false
[!warning] Si vous avez plusieurs jobs Pages dans votre pipeline avec la même valeur pour
path_prefix, le dernier à se terminer est déployé avec Pages.
Pour créer plusieurs déploiements pour votre projet en même temps, par exemple pour créer des environnements éphémères, consultez la documentation sur les déploiements parallèles.