Comment créer un CMS simple avec Cloudflare, GitHub Actions et Metalsmith


Construisons-nous un CMS. Mais plutôt que de créer une interface utilisateur, nous allons l’obtenir gratuitement sous la forme de GitHub lui-même! Nous utiliserons GitHub comme moyen de gérer le contenu de notre générateur de site statique (il pourrait être tout générateur de site statique). Voici l’essentiel: GitHub sera l’endroit où gérer, contrôler la version et stocker les fichiers, et aussi où nous ferons notre édition de contenu. Lorsque des modifications se produisent, une série d’automatisations testera, vérifiera et déploiera finalement notre contenu sur Cloudflare.

Vous pouvez trouver le code terminé pour le projet est disponible sur GitHub. J’alimente mon propre site Web, jonpauluritis.com, de cette façon exacte.

À quoi ressemble la pile complète?

Voici la pile technologique avec laquelle nous travaillerons dans cet article:

  • N’importe quel éditeur de démarques (facultatif, par exemple Typora.io)
  • Un générateur de site statique (par exemple, Metalsmith)
  • Github avec actions Github (CICD et déploiement)
  • Travailleurs Cloudflare

Pourquoi devriez-vous vous soucier de cette configuration? Cette configuration est potentiellement la façon la plus simple, la plus rapide, la moins chère (~ 5 $ / mois) et la plus simple de gérer un site Web (ou un site Jamstack). C’est génial tant du point de vue technique que du point de vue de l’expérience utilisateur. Cette configuration est tellement géniale que je suis littéralement sorti et j’ai acheté des actions dans Microsoft et Cloudflare.

Mais avant de commencer…

Je ne vais pas vous expliquer comment configurer des comptes sur ces services, je suis sûr que vous pouvez le faire vous-même. Voici les comptes que vous devez configurer:

Je recommanderais aussi Typora pour une expérience d’écriture Markdown incroyable, mais les éditeurs Markdown sont une chose très personnelle, alors utilisez l’éditeur qui vous convient.

Structure du projet

Pour vous donner une idée de la direction que nous prenons, voici la structure du projet terminé:

├── build.js
├── .github/workflows
│   ├── deploy.yml
│   └── nodejs.js
├── layouts
│   ├── about.hbs
│   ├── article.hbs
│   ├── index.hbs
│   └── partials
│       └── navigation.hbs
├── package-lock.json
├── package.json
├── public
├── src
│   ├── about.md
│   ├── articles
│   │   ├── post1.md
│   │   └── post2.md
│   └── index.md
├── workers-site
└── wrangler.toml

Étape 1: trucs de ligne de commande

Dans un terminal, changez de répertoire où que vous conserviez ces types de projets et tapez ceci:

$ mkdir cms && cd cms && npm init -y

Cela va créer un nouveau répertoire, y accéder et initialiser l’utilisation de npm.

La prochaine chose que nous voulons faire est de nous tenir sur les épaules des géants. Nous allons utiliser un certain nombre de packages npm qui nous aident à faire des choses, dont la viande utilise le générateur de site statique Forgeron:

$ npm install --save-dev metalsmith metalsmith-markdown metalsmith-layouts metalsmith-collections metalsmith-permalinks handlebars jstransformer-handlebars

Avec Metalsmith, il y a quelques autres bits et bobs utiles. Pourquoi Metalsmith? Parlons de ça.

Étape 2: forgeron

J’essaye des générateurs de sites statiques depuis 2-3 ans maintenant, et je n’ai toujours pas trouvé “celui-là”. Tous les grands noms – comme Eleventy, Gatsby, Hugo, Jekyll, Hexo, et Vuepress – sont totalement badass mais je ne peux pas dépasser la simplicité et l’extensibilité de Metalsmith.

À titre d’exemple, ce code va vous créer un site:

// EXAMPLE... NOT WHAT WE ARE USING FOR THIS TUTORIAL
Metalsmith(__dirname)         
  .source('src')       
  .destination('dest')     
  .use(markdown())             
  .use(layouts())           
  .build((err) => if (err) throw err);

Assez cool non?

Par souci de concision, saisissez ceci dans le terminal et nous échafauderons une structure et des fichiers pour commencer.

Commencez par créer les répertoires:

$ mkdir -p src/articles &&  mkdir -p layouts/partials 

Ensuite, créez le fichier de construction:

$ touch build.js

Ensuite, nous allons créer des fichiers de mise en page:

$ touch layouts/index.hbs && touch layouts/about.hbs && touch layouts/article.hbs && touch layouts/partials/navigation.hbt

Enfin, nous allons configurer nos ressources de contenu:

$ touch src/index.md && touch src/about.md && touch src/articles/post1.md && touch src/articles/post1.md touch src/articles/post2.md

Le dossier du projet devrait ressembler à ceci:

├── build.js
├── layouts
│   ├── about.hbs
│   ├── article.hbs
│   ├── index.hbs
│   └── partials
│       └── navigation.hbs
├── package-lock.json
├── package.json
└── src
    ├── about.md
    ├── articles
    │   ├── post1.md
    │   └── post2.md
    └── index.md

Étape 3: ajoutons du code

Pour économiser de l’espace (et du temps), vous pouvez utiliser les commandes ci-dessous pour créer le contenu de notre site Web fictif. N’hésitez pas à vous lancer dans des «articles» et à créer vos propres articles de blog. La clé est que les publications ont besoin de certaines métadonnées (également appelées «Front Matter») pour pouvoir générer correctement. Les fichiers que vous souhaitez modifier sont index.md, post1.md et post2.md.

Les métadonnées devraient ressembler à ceci:

---
title: 'Post1'
layout: article.hbs 
---
## Post content here....

Ou, si vous êtes paresseux comme moi, utilisez ces commandes de terminal pour ajouter du contenu factice de GitHub Gists à votre site:

$ curl https://gist.githubusercontent.com/jppope/35dd682f962e311241d2f502e3d8fa25/raw/ec9991fb2d5d2c2095ea9d9161f33290e7d9bb9e/index.md > src/index.md
$ curl https://gist.githubusercontent.com/jppope/2f6b3a602a3654b334c4d8df047db846/raw/88d90cec62be6ad0b3ee113ad0e1179dfbbb132b/about.md > src/about.md
$ curl https://gist.githubusercontent.com/jppope/98a31761a9e086604897e115548829c4/raw/6fc1a538e62c237f5de01a926865568926f545e1/post1.md > src/articles/post1.md
$ curl https://gist.githubusercontent.com/jppope/b686802621853a94a8a7695eb2bc4c84/raw/9dc07085d56953a718aeca40a3f71319d14410e7/post2.md > src/articles/post2.md

Ensuite, nous allons créer nos mises en page et mises en page partielles («partielles»). Nous allons utiliser Handlebars.js pour notre langage de modèles dans ce tutoriel, mais vous pouvez utiliser le langage de modèles qui flotte sur votre bateau. Metalsmith peut fonctionner avec à peu près tous, et je n’ai pas d’opinion bien arrêtée sur les modèles de langues.

Créer la disposition d’index



  
   %MINIFYHTML96ac0478f080ea0e902e397aa58d5c4814%  
  
    {{>navigation }}
    
       {{#each articles }}        

{{ title }}

       

{{ description }}

       {{/each }}    
 

Quelques notes:

  • Notre «navigation» n’a pas encore été définie, mais finira par remplacer la zone où {{>navigation }} réside.
  • {{#each }} itérera à travers la «collection» d’articles que le fabricant de métaux générera au cours de son processus de construction.
  • Forgeron a beaucoup des plugins vous pouvez utiliser pour des choses comme les feuilles de style, les balises, etc., mais ce n’est pas le sujet de ce didacticiel, nous vous laissons donc l’explorer.

Créer la page À propos

Ajoutez ce qui suit à votre about.hbs page:



  
   %MINIFYHTML96ac0478f080ea0e902e397aa58d5c4815%  
  
    {{>navigation }}
    
      {{{contents}}}    
 

Créer la disposition des articles



  
   %MINIFYHTML96ac0478f080ea0e902e397aa58d5c4816%  
  
    {{>navigation }}
    
      {{{contents}}}    
 

Vous avez peut-être remarqué qu’il s’agit exactement de la même mise en page que la page À propos. C’est. Je voulais juste vous expliquer comment ajouter des pages supplémentaires afin que vous sachiez comment procéder. Si vous voulez que celui-ci soit différent, allez-y.

Ajouter une navigation

Ajoutez ce qui suit à la layouts/partials/navigation.hbs fichier

Bien sûr, il n’y a pas grand-chose… mais ce n’est vraiment pas censé être un tutoriel Metalsmith / SSG. ¯ _ (ツ) _ / ¯

Étape 4: le fichier de construction

Le cœur et l’âme de Metalsmith est le fichier de construction. Par souci de rigueur, je vais le parcourir ligne par ligne.

On commence par importer les dépendances

Note rapide: Metalsmith a été créé en 2014 et le système de modules prédominant à l’époque était common.js , donc je vais m’en tenir aux instructions require par opposition aux modules ES. Il convient également de noter que la plupart des autres didacticiels utilisent également des instructions require, donc sauter une étape de construction avec Babel rendra la vie un peu moins complexe ici.

// What we use to glue everything together
const Metalsmith = require('metalsmith');


// compile from markdown (you can use targets as well)
const markdown = require('metalsmith-markdown');


// compiles layouts
const layouts = require('metalsmith-layouts');


// used to build collections of articles
const collections = require('metalsmith-collections');


// permalinks to clean up routes
const permalinks = require('metalsmith-permalinks');


// templating
const handlebars = require('handlebars');


// register the navigation
const fs = require('fs');
handlebars.registerPartial('navigation', fs.readFileSync(__dirname + '/layouts/partials/navigation.hbt').toString());


// NOTE: Uncomment if you want a server for development
// const serve = require('metalsmith-serve');
// const watch = require('metalsmith-watch');

Ensuite, nous allons inclure Metalsmith et lui dire où trouver ses cibles de compilation:

// Metalsmith
Metalsmith(__dirname)            
  // where your markdown files are
  .source('src')      
  // where you want the compliled files to be rendered
  .destination('public')

Jusqu’ici tout va bien. Après avoir défini la source et la cible, nous allons configurer le rendu de démarque, le rendu des mises en page et laisser savoir à Metalsmith d’utiliser “Collections”. Ce sont des moyens de regrouper des fichiers. Un exemple simple serait quelque chose comme des «articles de blog», mais cela pourrait vraiment être n’importe quoi, par exemple des recettes, des critiques de whisky, ou autre chose. Dans l’exemple ci-dessus, nous appelons la collection «articles».

 // previous code would go here


  // collections create groups of similar content
  .use(collections({ 
    articles: {
      pattern: 'articles/*.md',
    },
  }))
  // compile from markdown
  .use(markdown())
  // nicer looking links
  .use(permalinks({
    pattern: ':collection/:title'
  }))
  // build layouts using handlebars templates
  // also tell metalsmith where to find the raw input
  .use(layouts({
    engine: 'handlebars',
    directory: './layouts',
    default: 'article.html',
    pattern: ["*/*/*html", "*/*html", "*html"],
    partials: {
      navigation: 'partials/navigation',
    }
  }))


// NOTE: Uncomment if you want a server for development
// .use(serve({
//   port: 8081,
//   verbose: true
// }))
// .use(watch({
//   paths: {
//     "${source}/**/*": true,
//     "layouts/**/*": "**/*",
//   }
// }))

Ensuite, nous ajoutons le plugin de démarquage, afin que nous puissions utiliser le démarquage pour le contenu à compiler en HTML.

À partir de là, nous utilisons le plug-in de mise en page pour envelopper notre contenu brut dans la mise en page que nous définissons dans le dossier des mises en page. Vous pouvez en savoir plus sur les écrous et les boulons de cela sur le site officiel du plugin mais le résultat est que nous pouvons utiliser {{{contents}}} dans un modèle et cela fonctionnera.

Le dernier ajout à notre tout petit script de construction sera la méthode de construction:

// Everything else would be above this
.build(function(err) {
  if (err) {
    console.error(err)
  }
  else {
    console.log('build completed!');
  }
});

En mettant tout ensemble, nous devrions obtenir un script de construction qui ressemble à ceci:

const Metalsmith = require('metalsmith');
const markdown = require('metalsmith-markdown');
const layouts = require('metalsmith-layouts');
const collections = require('metalsmith-collections');
const permalinks = require('metalsmith-permalinks');
const handlebars = require('handlebars');
const fs = require('fs');


// Navigation
handlebars.registerPartial('navigation', fs.readFileSync(__dirname + '/layouts/partials/navigation.hbt').toString());


Metalsmith(__dirname)
  .source('src')
  .destination('public')
  .use(collections({
    articles: {
      pattern: 'articles/*.md',
    },
  }))
  .use(markdown())
  .use(permalinks({
    pattern: ':collection/:title'
  }))
  .use(layouts({
    engine: 'handlebars',
    directory: './layouts',
    default: 'article.html',
    pattern: ["*/*/*html", "*/*html", "*html"],
    partials: {
      navigation: 'partials/navigation',
    }
  }))
  .build(function (err) {
    if (err) {
      console.error(err)
    }
    else {
      console.log('build completed!');
    }
  });

Je suis un aspirant pour simple et propre et, à mon humble avis, cela ne devient pas plus simple ou plus propre qu’une construction Metalsmith. Nous avons juste besoin de faire une mise à jour rapide du package.json fichier et nous serons en mesure de faire un essai:

 "name": "buffaloTraceRoute",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build": "node build.js",
    "test": "echo "No Tests Yet!" "
  },
  "keywords": [],
  "author": "Your Name",
  "license": "ISC",
  "devDependencies": {
    // these should be the current versions
    // also... comments aren't allowed in JSON
  }
}

Si vous voulez voir votre travail pratique, vous pouvez décommenter les parties du fichier de construction qui vous permettront de servir votre projet et de faire des choses comme exécuter npm run build. Assurez-vous simplement de supprimer ce code avant le déploiement.

Travailler avec Cloudflare

Ensuite, nous allons travailler avec Cloudflare pour accéder à leurs employés Cloudflare. C’est là que le coût de 5 $ / mois entre en jeu.

Maintenant, vous vous demandez peut-être: «D’accord, mais pourquoi Cloudflare? Que diriez-vous d’utiliser quelque chose de gratuit comme GutHub Pages ou Netlify? ” C’est une bonne question. Il existe de nombreuses façons de déployer un site statique, alors pourquoi choisir une méthode plutôt qu’une autre?

Eh bien, Cloudflare a quelques avantages:

Vitesse et performances

L’une des principales raisons de passer à un générateur de site statique est d’améliorer les performances de votre site Web. L’utilisation du site Cloudflare Workers peut améliorer vos performances encore plus.

Voici un graphique qui montre Cloudflare par rapport à deux alternatives concurrentes:

Courtoisie de Cloudflare

La raison simple pour laquelle Cloudflare est le plus rapide: un site est déployé sur 190+ centres de données autour du monde. Cela réduit la latence car les utilisateurs recevront les actifs à partir d’un emplacement physiquement plus proche d’eux.

Simplicité

Certes, la configuration initiale de Cloudflare Workers peut être un peu délicate si vous ne savez pas comment configurer les variables d’environnement. Mais après avoir installé les configurations de base de votre ordinateur, le déploiement sur Cloudflare est aussi simple que la publication de wrangler à partir du répertoire du site. Ce didacticiel se concentre sur l’aspect CI / CD du déploiement sur Cloudflare qui est un peu plus impliqué, mais il est incroyablement simple par rapport à la plupart des autres processus de déploiement.

(Il convient de mentionner les pages GitHub, Netlify est également en train de le tuer dans ce domaine. L’expérience des développeurs des trois sociétés est incroyable.)

Plus pour le prix

Alors que Github Pages et Netlify ont tous deux des niveaux gratuits, votre utilisation est (douce) limitée à 100 Go de bande passante par mois. Ne vous méprenez pas, c’est une limite super généreuse. Mais après cela, vous n’avez pas de chance. Les pages GitHub n’offrent rien de plus que cela et Netlify grimpe jusqu’à 45 $ / mois, ce qui rend le prix de 5 $ / mois de Cloudflare très raisonnable.

Un serviceBande passante de niveau gratuitePrix ​​Tier payéDemandes de niveau payant / bande passante
Pages GitHub100 GoN / AN / A
Netlify100 Go45 $~ 150 K / 400 Go
Sites des travailleurs Cloudflareaucun5 $10MM / illimité
Les calculs supposent un site Web moyen de 3 Mo. Cloudflare a des limites supplémentaires sur l’utilisation du processeur. Les pages GitHub ne doivent pas être utilisées pour les sites qui effectuent des transactions par carte de crédit.

Bien sûr, il n’y a pas de niveau gratuit pour Cloudflare, mais 5 $ pour 10 millions de demandes est un vol. Je serais également remise si je ne mentionnais pas que GitHub Pages a eu quelques pannes au cours de la dernière année. C’est tout à fait bien dans mon livre un site de démonstration, mais ce serait une mauvaise nouvelle pour une entreprise.

Cloudflare offre une tonne de fonctionnalités supplémentaires pour celles qui méritent d’être brièvement mentionnées: des certificats SSL gratuits, un routage DNS gratuit (et facile), un nom de domaine de sites de travail personnalisé pour vos projets (qui est idéal pour le transfert), des environnements illimités (par exemple, le transfert) et l’enregistrement d’un nom de domaine au prix coûtant (par opposition au prix de majoration imposé par d’autres bureaux d’enregistrement).

Déploiement sur Cloudflare

Cloudflare fournit d’excellents tutoriels pour savoir comment utiliser leur produit Cloudflare Workers. Nous allons couvrir les faits saillants ici.

Tout d’abord, assurez-vous que la CLI Cloudflare, Wrangler, est installée:

$ npm i @cloudflare/wrangler -g

Ensuite, nous allons ajouter des sites Cloudflare au projet, comme ceci:

wrangler init --site cms 

En supposant que je n’ai pas gâché et oublié une étape, voici ce que nous devrions avoir dans le terminal à ce stade:

⬇️ Installing cargo-generate...
🔧   Creating project called `workers-site`...
✨   Done! New project created /Users//Code/cms/workers-site
✨  Succesfully scaffolded workers site
✨  Succesfully created a `wrangler.toml`

Il devrait également y avoir un dossier généré à la racine du projet appelé /workers-site ainsi qu’un fichier de configuration appelé wrangler.toml – c’est là que réside la magie.

name = "cms"
type = "webpack"
account_id = ""
workers_dev = true
route = ""
zone_id = ""


[site]
bucket = ""
entry-point = "workers-site"

Vous avez peut-être déjà deviné ce qui vient ensuite… nous devons ajouter quelques informations au fichier de configuration! La première paire clé / valeur que nous allons mettre à jour est la bucket propriété.

bucket = "./public"

Ensuite, nous devons obtenir l’ID de compte et l’ID de zone (c’est-à-dire l’itinéraire pour votre nom de domaine). Vous pouvez les trouver dans votre compte Cloudflare tout au long du bas du tableau de bord de votre domaine:

Arrêtez! Avant d’aller plus loin, n’oubliez pas de cliquer sur le bouton “Obtenir votre token API” pour récupérer le dernier élément de configuration dont nous aurons besoin. Enregistrez-le sur un bloc-notes ou quelque part à portée de main, car nous en aurons besoin pour la section suivante.

Phew! Bien, tLa tâche suivante consiste à ajouter l’ID de compte et l’ID de zone que nous venons de saisir dans le fichier .toml:

name = "buffalo-traceroute"
type = "webpack"
account_id = "d7313702f333457f84f3c648e9d652ff" # Fake... use your account_id
workers_dev = true
# route = "example.com/*" 
# zone_id = "805b078ca1294617aead2a1d2a1830b9" # Fake... use your zone_id


[site]
bucket = "./public"
entry-point = "workers-site"
(Again, those IDs are fake.)

Encore une fois, ces identifiants sont faux. Vous pouvez être invité à configurer des informations d’identification sur votre ordinateur. Si tel est le cas, exécutez wrangler config dans le terminal.

Actions GitHub

La dernière pièce du puzzle consiste à configurer GitHub pour effectuer des déploiements automatiques pour nous. Après avoir fait des incursions précédentes dans les configurations CI / CD, j’étais prêt pour le pire sur celui-ci mais, étonnamment, les actions GitHub sont très simples pour ce type de configuration.

Donc comment ça fonctionne?

Tout d’abord, assurons-nous que le compte GitHub a Actions GitHub activées. Il est techniquement en version bêta actuellement, mais je n’ai rencontré aucun problème avec cela jusqu’à présent.

Ensuite, nous devons créer un référentiel dans GitHub et y télécharger notre code. Commencez par accéder à GitHub et créez un référentiel.

Ce didacticiel n’est pas destiné à couvrir les points les plus fins de Git et / ou GitHub, mais il existe une excellente introduction. Ou copiez et collez les commandes suivantes dans le répertoire racine du projet:

# run commands one after the other
$ git init
$ touch .gitignore && echo 'node_modules' > .gitignore
$ git add .
$ git commit -m 'first commit'
$ git remote add origin https://github.com/{username}/{repo name}
$ git push -u origin master

Cette devrait ajoutez le projet à GitHub. Je dis ça avec un peu d’hésitation mais c’est là que tout a tendance à exploser pour moi. Par exemple, mettez trop de commandes dans le terminal et soudainement GitHub a une panne, ou le terminal ne peut pas localiser le chemin pour Python. Faites preuve de prudence!

En supposant que nous ayons dépassé cette partie, notre prochaine tâche consiste à activer les actions Github et à créer un répertoire appelé .github/workflows à la racine du répertoire du projet. (GitHub peut également le faire automatiquement en ajoutant le workflow «nœud» lors de l’activation des actions. Au moment de la rédaction, l’ajout d’un workflow d’actions GitHub fait partie de l’interface utilisateur de GitHub.)

Une fois que nous avons le répertoire dans la racine du projet, nous pouvons ajouter les deux derniers fichiers. Chaque fichier va gérer un workflow différent:

  1. Un workflow pour vérifier que les mises à jour peuvent être fusionnées (c’est-à-dire le «CI» dans CI / CD)
  2. Un flux de travail pour déployer les modifications une fois qu’elles ont été fusionnées dans le maître (c’est-à-dire le «CD» dans CI / CD)
# integration.yml
name: Integration


on:
  pull_request:
    branches: [ master ]


jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [10.x, 12.x]
    steps:
    - uses: actions/[email protected]
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/[email protected]
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test
      env:
        CI: true

Il s’agit d’un flux de travail simple. Si simple, en fait, que je l’ai copié directement à partir des documents officiels de GitHub Actions et que je l’ai à peine modifié. Voyons ce qui se passe réellement là-dedans:

  1. on: Exécuter ce flux de travail uniquement lorsqu’une demande d’extraction est créée pour la branche principale
  2. jobs: Exécutez les étapes ci-dessous pour les environnements à deux nœuds (par exemple, Node 10 et Node 12 – Node 12 est actuellement la version recommandée). Cela va se construire, si un script de construction est défini. Il exécutera également des tests si un script de test est défini.

Le deuxième fichier est notre script de déploiement et est un peu plus impliqué.

# deploy.yml
name: Deploy


on:
  push:
    branches:
      - master


jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    strategy:
      matrix:
        node-version: [10.x]


    steps:
      - uses: actions/[email protected]
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/[email protected]
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - uses: actions/[email protected]
      - name: Build site
        run: "npm run build"
      - name: Publish
        uses: cloudflare/[email protected]
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}

Important! Vous vous souvenez du jeton API Cloudflare que j’ai mentionné plus tôt? Il est maintenant temps de l’utiliser. Accédez aux paramètres du projet et ajouter un secret. Nommez le secret CF_API_TOKEN et ajoutez le jeton d’API.

Voyons ce qui se passe dans ce script:

  1. on: Exécutez les étapes lorsque le code est fusionné dans la branche principale
  2. steps: Utilisez Nodejs pour installer toutes les dépendances, utilisez Nodejs pour créer le site, puis utilisez Cloudflare Wrangler pour publier le site

Voici un bref résumé de ce à quoi le projet devrait ressembler avant d’exécuter une build (sans node_modules):

├── build.js
├── dist
│   └── worker.js
├── layouts
│   ├── about.hbs
│   ├── article.hbs
│   ├── index.hbs
│   └── partials
│       └── navigation.hbs
├── package-lock.json
├── package.json
├── public
├── src
│   ├── about.md
│   ├── articles
│   │   ├── post1.md
│   │   └── post2.md
│   └── index.md
├── workers-site
│   ├── index.js
│   ├── package-lock.json
│   ├── package.json
│   └── worker
│       └── script.js
└── wrangler.toml

Un CMS basé sur GitHub

D’accord, je l’ai fait jusqu’ici… On m’a promis un CMS? Où est la base de données et mon interface graphique à laquelle je me connecte et tout ça?

Ne vous inquiétez pas, vous êtes à la ligne d’arrivée! GitHub est votre CMS maintenant et voici comment cela fonctionne:

  1. Écrivez un fichier de démarque (avec le début).
  2. Ouvrez GitHub et accédez au référentiel du projet.
  3. Cliquez dans le répertoire «Articles» et téléchargez le nouvel article. GitHub vous demandera si une nouvelle branche doit être créée avec une demande de pull. La réponse est Oui.
  4. Une fois l’intégration vérifiée, la demande d’extraction peut être fusionnée, ce qui déclenche le déploiement.
  5. Asseyez-vous, détendez-vous et attendez 10 secondes… le contenu est déployé dans 164 centres de données du monde entier.

Félicitations! Vous avez maintenant un CMS minimal basé sur Git que pratiquement tout le monde peut utiliser.

Notes de dépannage

  • Les mises en page de forgeron peuvent parfois être un peu délicates. Essayez d’ajouter cette ligne de débogage avant l’étape de génération pour la faire sortir quelque chose d’utile: DEBUG=metalsmith-layouts npm run build
  • Parfois, les actions Github nécessitaient que j’ajoute node_modules au commit pour qu’il puisse se déployer… c’était étrange pour moi (et pas une pratique recommandée) mais cela a corrigé le déploiement.
  • S’il vous plaît laissez-moi savoir si vous rencontrez des problèmes et nous pouvons l’ajouter à cette liste!
Close Menu