Temas e CLI › CLI

O CLI no CI e no GitHub

O CLI foi feito para rodar sem ninguém olhando: o token vem de uma variável, o resultado sai em JSON ou em anotações do GitHub, os códigos de saída dizem o que aconteceu, e nenhum comando pergunta nada sem terminal. Este guia mostra o caminho com o GitHub Actions; o mesmo vale para qualquer CI.

No GitHub, há também o caminho sem CI e sem token: o App da Denaryx liga o tema a uma branch, atualiza o tema a cada push, anota o commit e os pull requests e dá a cada pull request uma prévia na loja, com o link num comentário (ver O tema no GitHub). O CI com o CLI continua servindo a quem prefere o próprio workflow, ao GitLab e ao Bitbucket. Não use os dois no mesmo tema: o tema conectado ao App recusa o envio do CLI (409 theme_connected).

O token no CI

1. No painel da loja, em Configurações › Integrações, crie uma integração só para o CI (por exemplo, "GitHub do tema"), com write_themes. Marque publish_themes só se o CI for publicar.
2. Guarde o token como segredo do repositório (no GitHub, Settings › Secrets and variables › Actions), com o nome DENARYX_TOKEN.
3. No workflow, passe o segredo como a variável DENARYX_TOKEN. O CLI não precisa de login.

Com loja no denaryx.json, o CLI confere que o token é daquela loja antes de qualquer gravação. Uma integração por loja, e um token com validade, que se troca sem parar o CI (a integração aceita dois tokens ativos).

Conferir cada pull request

O --formato github escreve as anotações do GitHub Actions: cada problema do verificador aparece na linha do arquivo, no pull request. Não precisa de token: o verificador roda sem rede.

name: Tema

on:
  pull_request:

permissions:
  contents: read

jobs:
  conferir:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npx denaryx@0.5.0 tema check --formato github

Para barrar também os avisos, acrescente --falhar-em aviso.

Enviar a cada push na main

O tema do denaryx.json passa a ser o espelho da branch: o --espelhar apaga na loja o que saiu do repositório. O envio grava no tema em trabalho; a vitrine só muda com a publicação.

name: Enviar o tema

on:
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: tema-${{ github.ref }}
  cancel-in-progress: false

jobs:
  enviar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npx denaryx@0.5.0 tema check --formato github
      - run: npx denaryx@0.5.0 tema push --espelhar --versao "${{ github.sha }}"
        env:
          DENARYX_TOKEN: ${{ secrets.DENARYX_TOKEN }}

Depois do envio, o check --paginas desenha na loja a página de exemplo de cada template, pela prévia do tema, e confere o HTML de cada uma (ver denaryx tema check). Ele precisa do token, e dos dados da loja: é o passo que acha a página que não abre com o produto de verdade.

- run: npx denaryx@0.5.0 tema check --paginas --formato github
  env:
    DENARYX_TOKEN: ${{ secrets.DENARYX_TOKEN }}

• O concurrency põe um envio de cada vez: dois envios ao mesmo tema não se atropelam, mas o segundo acharia conflito.
• O código editado no painel: no CI não há estado guardado, então a pasta é a verdade, e o arquivo editado pelo editor de arquivos do painel é sobrescrito pelo do repositório. Combine com a equipe que o código do tema muda pelo Git. O conteúdo da loja (o que o lojista monta no editor visual) não é código e nunca é tocado pelo envio.
• Conflito (saída 4): só quando alguém grava no tema durante o envio. O que já foi fica; rode de novo.
• Para publicar no mesmo passo, tema push --espelhar --publicar --sim, com publish_themes na integração. O CLI confere o tema antes e não publica com erro.

Um tema por ambiente

Os ambientes do denaryx.json levam o mesmo código para lojas ou temas diferentes: a loja de homologação a cada push, a do cliente na tag.

{
  "loja": "cliente-homologacao",
  "tema": "5b0d6f1e-2c3a-4d5e-8f90-1a2b3c4d5e6f",
  "ambientes": {
    "producao": {
      "loja": "cliente",
      "tema": "9a8b7c6d-5e4f-4a3b-9c2d-1e0f9a8b7c6d"
    }
  }
}

- run: npx denaryx@0.5.0 tema push --espelhar -a producao
  env:
    DENARYX_TOKEN: ${{ secrets.DENARYX_TOKEN_PRODUCAO }}

Outros CIs

O mesmo vale para o GitLab CI, o Bitbucket Pipelines ou qualquer outro: Node 22, a variável DENARYX_TOKEN com o segredo, e os comandos. No GitLab:

tema:
  image: node:22
  script:
    - npx denaryx@0.5.0 tema check
    - npx denaryx@0.5.0 tema push --espelhar
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Ler o resultado num programa

--json dá o resultado de qualquer comando em JSON, na saída padrão; o andamento vai para a saída de erro.

npx denaryx@0.5.0 tema check --json > problemas.json
npx denaryx@0.5.0 tema push --json | jq '.written'

No erro, o JSON traz error.code (estável, em inglês), error.message, error.exit_code e, quando veio da API, o request_id, que é o que o suporte pede.