Il s'agit du code source d'un site Web hébergé sur https://seagl.org.
Il utilise Jekyll comme générateur de site statique avec GitHub Pages.
Le site est automatiquement rendu chaque fois que le code est transféré vers le référentiel partagé sur GitHub.
Fondamentalement, les étapes pour mettre à jour le site (pour publier un nouvel article de blog, par exemple) sont :
Vous trouverez ci-dessous des instructions pour chacune de ces étapes. Les instructions supposent que quelqu'un avec moins d'expérience git/GitHub/technique effectue le travail. Ceux qui ont plus d’expérience peuvent extrapoler en conséquence. :-)
Bien que vous puissiez probablement travailler directement sur ce référentiel, les meilleures pratiques sont que ce n'est pas le cas. Au lieu de cela, vous pouvez créer ou cloner le dépôt, puis apporter vos modifications sur cette copie. Cela permet de tester avant d'apporter des modifications en direct et réduit le risque qu'une modification mal formatée ou mal formulée s'échappe dans le monde.
Pour créer un fork sur le dépôt :
Voilà ! C'est tout ce qu'il y a à dire.
Si vous ajoutez un nouvel article de blog, veuillez suivre ces règles de nom de fichier :
_posts
.YYYY-MM-DD
. Ceci est très important car cela contrôle l’ordre dans lequel le site Web affiche les articles de blog.--future
lors du test de vos modifications. À l'heure actuelle, il est également nécessaire que vous déclenchiez une reconstruction du site à ou après la date prévue pour que la publication apparaisse. Cela peut être fait avec : git commit -m 'rebuild pages' --allow-empty && git push origin main
ou en apportant une modification réelle au site.-
), puis un titre délimité par un tiret pour le message. Ce titre n'est pas affiché. C'est juste pour nommer le fichier. Veuillez être bref mais descriptif..md
pour indiquer que la publication est composée au format Markdown. (et veuillez rédiger uniquement des messages en utilisant Markdown)Selon ces règles, un article de blog annonçant l'ouverture du CFP 2017 pourrait avoir le nom de fichier :
2017-06-19-CFP-open.md
Veuillez également ajouter les éléments suivants en haut de votre fichier :
---
layout: post
title: 'Example Title'
status: publish
type: post
published: true
categories: news
tags: '2013'
---
Définissez title
sur le titre de votre article de blog et modifiez tags
pour inclure l'année de conférence à laquelle l'article est associé (vide s'il n'y en a pas). Veuillez laisser le reste des valeurs telles quelles.
Pour le contenu réel du fichier, vous pouvez apporter vos modifications soit dans l'interface Web GitHub, soit sur votre ordinateur local.
_posts
).Create a new file
Create a new file
Commit changes
situé sous l'interface d'édition.#
) suivi d'un numéro de problème ( #74
). Cela sera automatiquement lié dans la pull request, ce qui est vraiment pratique.À déterminer (en supposant que ceux qui utilisent git sur leurs machines locales le savent déjà ; ils le rempliront plus tard)
Veuillez tester toutes les modifications localement avant de les transférer vers GitHub.
Le démarrage d'un serveur de développement local rendra votre copie du site disponible à l'adresse http://localhost:4000. Il existe plusieurs façons d'exécuter le serveur. Faites votre choix !
Dépendances :
Configuration unique :
bundle install
Démarrez le serveur :
bundle exec jekyll serve --watch
Pour prévisualiser les publications ultérieures et non publiées, ajoutez --future --unpublished
à la commande ci-dessus.
Dépendances :
docker
par podman
)Configuration unique :
docker build --tag ' seagldev ' ' . '
Démarrez le serveur :
docker run --rm --interactive --tty --publish ' 4000:4000 ' --volume " $PWD :/usr/src/app " ' seagldev '
Pour prévisualiser les publications ultérieures et non publiées, ajoutez --future --unpublished
à la fin de la commande ci-dessus.
Vous pouvez soit envoyer un PR dans l'interface GitHub, soit depuis votre ordinateur local.
Pull requests
.New pull request button
.Create pull request
.#
) suivi d'un numéro de problème ( #74
). Cela sera automatiquement lié dans la pull request, ce qui est vraiment pratique.[Allow edits from maintainers](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
afin que les autres membres de l'équipe puissent apporter des modifications, si nécessaire.Create pull request
.À déterminer (en supposant que ceux qui utilisent git sur leurs machines locales le savent déjà ; ils le rempliront plus tard)
Maintenant, quelqu'un (peut-être vous, si vous disposez de ce niveau d'accès au dépôt) doit examiner puis fusionner votre demande d'extraction.
Une fois votre pull request fusionnée, elle sera mise en ligne sur le site Web.
NOTA BENE : La fusion elle-même ne déclenchera pas de reconstruction du site. Pour reconstruire le site, vous devez pousser un commit vide comme ceci :
git commit --allow-empty -m " Rebuild the site, please " && git push
Ajoutez votre image au répertoire img/posts/
, puis utilisez le Markdown suivant :
![ Example description ] ( /img/posts/example.jpg )
Conseils:
Pour aligner l'image sur le côté, ajoutez la classe align-left
ou align-right
:
![ Example description ] ( /img/posts/example.jpg ) {:.align-left}
Par souci de temps de chargement des pages, redimensionnez les images à une taille raisonnable avant de les utiliser dans une publication.
Les conférences passées sont archivées de manière statique sous forme de collections Jekyll :
archive-conferences
archive-sessions
Pour créer l'archive d'une année donnée, importez d'abord les données du planning—
bundle exec rake import[2020]
-puis éditez les fichiers d'archives à la main si des corrections sont nécessaires.