Mise à jour du contenu du site Web dans les délais via GitHub Actions

J'aimerais partager mon parcours dans la création d'un système de gestion de contenu autonome qui ne nécessite pas de base de données de contenu au sens traditionnel.

Le problème

Le contenu (articles de blog et favoris) de ce site Web est stocké dans une base de données Notion :

Le problème que j'essayais de résoudre était de ne pas avoir à déployer le site manuellement après chaque signet que j'y ajoute. Et en plus de cela, gardez l'hébergement aussi bon marché que possible, car pour moi, la rapidité avec laquelle les favoris que j'ajoute à ma base de données Notion finissent en ligne n'a pas vraiment d'importance.

Donc, après quelques recherches, j'ai trouvé la configuration suivante :

Le système se compose de plusieurs éléments :

• L'action « Push to Main » qui déploie les changements
• L'action « Mettre à jour le contenu » qui télécharge le contenu depuis l'API Notion et valide les modifications
• L'action « Mettre à jour le contenu selon le calendrier » s'exécute de temps en temps et déclenche l'action « Mettre à jour le contenu »

Examinons chacun d’eux de l’intérieur en détail.

Le flux de travail « Push to Main »

Il n'y a pas grand chose à dire ici, configuration assez standard, - lorsqu'il y a une poussée vers la branche principale, ce workflow crée l'application et la déploie sur Cloudflare Pages à l'aide de la CLI Wrangler :

name: Push to Main on: push: branches: [main] workflow_dispatch: {} jobs: deploy-cloudflare-pages: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v4 - name: Setup pnpm uses: pnpm/action-setup@v4 - name: Setup Node uses: actions/setup-node@v4 with: node-version-file: .node-version cache: pnpm - name: Install node modules run: | pnpm --version pnpm install --frozen-lockfile - name: Build the App run: | pnpm build - name: Publish Cloudflare Pages env: CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }} CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }} run: | pnpm wrangler pages deploy ./out --project-name ${{ secrets.CLOUDFLARE_PROJECT_NAME }}

Le workflow « Mettre à jour le contenu »

Ce Workflow ne peut être déclenché que « manuellement »… mais aussi automatiquement car vous pouvez le déclencher à l'aide d'un jeton d'accès personnel GitHub, alias PAT. Je l'ai initialement écrit parce que je voulais déployer les modifications depuis mon téléphone. Il télécharge les publications et les favoris à l'aide de l'API Notion, puis - s'il y a des modifications dans la base de code - crée un commit et le pousse. Afin de fonctionner correctement, ce workflow doit être fourni avec un PAT disposant d'un « accès en lecture et en écriture au code » du référentiel :

name: Update Content on: workflow_dispatch: {} jobs: download-content: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v4 with: # A Github Personal Access Token with access to the repository # that has the follwing permissions: # ✅ Read and Write access to code token: ${{ secrets.GITHUB_PAT_CONTENT }} - name: Setup pnpm uses: pnpm/action-setup@v4 - name: Setup Node uses: actions/setup-node@v4 with: node-version-file: .node-version cache: pnpm - name: Install node modules run: | pnpm --version pnpm install --frozen-lockfile - name: Download articles content from Notion env: NOTION_KEY: "${{ secrets.NOTION_KEY }}" NOTION_ARTICLES_DATABASE_ID: "${{ secrets.NOTION_ARTICLES_DATABASE_ID }}" run: | pnpm download-articles - name: Download bookmarks content from Notion env: NOTION_KEY: ${{ secrets.NOTION_KEY }} NOTION_BOOKMARKS_DATABASE_ID: ${{ secrets.NOTION_BOOKMARKS_DATABASE_ID }} run: | pnpm download-bookmarks - name: Configure Git run: | git config --global user.email "${{ secrets.GIT_USER_EMAIL }}" git config --global user.name "${{ secrets.GIT_USER_NAME }}" - name: Check if anything changed id: check-changes run: | if [ -n "$(git status --porcelain)" ]; then echo "There are changes" echo "HAS_CHANGED=true" >> $GITHUB_OUTPUT else echo "There are no changes" echo "HAS_CHANGED=false" >> $GITHUB_OUTPUT fi - name: Commit changes if: steps.check-changes.outputs.HAS_CHANGED == 'true' run: | git add ./src/content git add ./public git commit -m "Automatic content update commit" git push

Le workflow « Mettre à jour le contenu selon le calendrier »

Celui-ci est assez simple : il s'exécute de temps en temps et déclenche le workflow ci-dessus. Pour fonctionner correctement, ce workflow doit être fourni avec un GitHub PAT disposant d'un « accès en lecture et en écriture auxactions» du référentiel. Dans mon cas, c'est un PAT différent :

name: Update Content on Schedule on: schedule: - cron: "13 0,12 * * *" workflow_dispatch: {} jobs: trigger-update-content: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v4 - name: Dispatch the Update Content workflow env: # A Github Personal Access Token with access to the repository # that has the follwing permissions: # ✅ Read and Write access to actions GH_TOKEN: ${{ secrets.GITHUB_PAT_ACTIONS }} run: | gh workflow run "Update Content" --ref main

Conclusion

Pour moi, cette configuration s'est avérée vraiment bonne et flexible. En raison de la structure modulaire, l'action « Mettre à jour le contenu » peut être déclenchée manuellement – par ex. depuis mon téléphone en voyage. Pour moi, c'était une autre expérience précieuse d'amélioration progressive d'un flux de travail.

J'espère que cela vous sera utile ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!