O que acontece depois que uma mudança sobe

Uma mudança no ipe.rest chega aos visitantes por meio de um workflow curto no GitHub. Ele copia o site, verifica, publica e avisa os buscadores sobre o que é novo. A maioria das execuções termina em menos de 40 segundos.

A última entrada descreveu como as páginas são construídas. Esta começa onde aquela termina, quando uma mudança chega à branch main do nosso repositório. Os números são de 10 de novembro de 2026: o arquivo do workflow, uma compilação local do site e as últimas oito execuções no GitHub.

Copiar

O site é feito de arquivos simples, então o primeiro passo é uma cópia. O workflow baixa o repositório e copia tudo, exceto o que os visitantes não precisam: os scripts, os testes, o próprio workflow, os dados de controle de versão e quaisquer arquivos Markdown. Dos 586 arquivos do repositório, 329 vão para a pasta do site, cerca de 10 MB.

Verificar

Depois, sete testes rodam sobre essa pasta, não sobre o repositório. Eles procuram os arquivos de que um visitante precisa, como o arquivo robots, o mapa do site, o service worker e as páginas iniciais; as pastas que não devem estar lá, como scripts e tests; e a página 404, que deve estar marcada como noindex e ter um link para a página inicial. Uma falha interrompe o workflow aqui. Nada é publicado, e a versão anterior continua no ar.

Publicar

Em seguida a pasta é enviada e entregue ao GitHub Pages, que a serve. Só um deploy roda por vez: se uma mudança mais nova chega enquanto outro está em andamento, a execução mais antiga é cancelada. Não há no meio nenhum servidor nosso nem banco de dados. Quando a versão do service worker muda, o navegador de um visitante instala um cache novo e apaga os antigos em uma visita posterior.

Avisar

Depois de publicar, o workflow envia ao IndexNow, um protocolo que Bing, Naver, Yandex e outros buscadores aceitam, os endereços das páginas cuja data no mapa do site é hoje no horário da Coreia. A chave de que ele precisa é um arquivo de texto público na raiz do site. Esta etapa pode falhar: se falhar, o deploy ainda conta como um sucesso.

Como foi até agora

Das últimas oito execuções, sete tiveram sucesso e uma falhou; a seguinte, 22 segundos depois, teve sucesso. Cinco das sete execuções bem-sucedidas levaram menos de 40 segundos, e a mais lenta levou 2 minutos e 18 segundos. Medimos do início de uma execução até sua última atualização, então leia os tempos como aproximados.

O que uma execução verde não diz

Uma execução aprovada diz que os arquivos chegaram e que sete verificações passaram. Não diz que uma página fica bem numa tela pequena de celular, e o IndexNow apenas informa os buscadores; ele não promete nada sobre quando, ou se, eles vão listar uma página.

ipe(); // copy, check, publish, tell

O workflow é curto de propósito. Menos etapas deixam menos lugares onde um site tranquilo pode quebrar.