Gostaria de compartilhar minha jornada na construção de um sistema de gerenciamento de conteúdo autossustentável que não requer um banco de dados de conteúdo no sentido tradicional.

O problema

O conteúdo (postagens de blog e favoritos) deste site é armazenado em um banco de dados Notion:

O problema que eu estava tentando resolver era não precisar implantar o site manualmente após cada marcador adicionado lá. E ainda por cima – mantenha a hospedagem o mais barata possível, porque para mim realmente não importa a rapidez com que os favoritos que adiciono ao meu banco de dados Notion ficam online.

Então, depois de algumas pesquisas, descobri a seguinte configuração:

O sistema consiste em vários componentes:

• A ação “Push to Main” que implanta as alterações
• A ação “Atualizar conteúdo” que baixa o conteúdo da API Notion e confirma as alterações
• A ação “Atualizar conteúdo conforme cronograma” é executada de vez em quando e aciona a ação “Atualizar conteúdo”

Vamos examinar cada um deles de dentro para fora em detalhes.

O fluxo de trabalho “Push to Main”

Não há muito a dizer aqui, configuração bastante padrão – quando há um push para o branch principal, este fluxo de trabalho cria o aplicativo e o implanta nas páginas da Cloudflare usando a CLI do 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 }}

O fluxo de trabalho “Atualizar conteúdo”

Este fluxo de trabalho só pode ser acionado “manualmente”… mas também automaticamente porque você pode acioná-lo usando um token de acesso pessoal do GitHub, também conhecido como PAT. Eu o escrevi inicialmente porque queria implantar alterações no meu telefone. Ele baixa as postagens e os favoritos usando a API Notion e então, se houver alguma alteração na base de código, cria um commit e o envia. Para funcionar corretamente, este fluxo de trabalho deve ser fornecido com um PAT que tenha “acesso de leitura e gravação ao código” do repositório:

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

O fluxo de trabalho “Atualizar conteúdo dentro do cronograma”

Este é bem simples: ele é executado de vez em quando e aciona o fluxo de trabalho acima. Para funcionar corretamente, este fluxo de trabalho deve ser fornecido com um GitHub PAT que tenha “acesso de leitura e gravação às ações” do repositório. No meu caso é um PAT diferente:

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

Conclusão

Para mim, essa configuração provou ser muito boa e flexível. Devido à estrutura modular, a ação “Atualizar Conteúdo” pode ser acionada manualmente – por ex. do meu telefone durante uma viagem. Para mim esta foi mais uma experiência valiosa de melhoria progressiva de um fluxo de trabalho.

Espero que isso seja útil?