Introdução
FIELDNOTES tem um teste correto para visitantes, mas seu script local pode continuar após uma falha e publicar outro pacote. Sua tarefa é conectar a decisão à entrega real.
Este ambiente novo inclui as verificações concluídas do primeiro laboratório e o site publicado sem alterações. Você corrigirá um pequeno fluxo Bash, rejeitará uma entrada defeituosa, publicará uma válida e mostrará que edições posteriores nos rascunhos não alteram o pacote salvo. Workstation, Live Website e Candidate Preview estão preparados. É um fluxo local de aprendizagem, não GitHub Actions nem uma barreira de segurança de produção.
Fazer a falha interromper a publicação
Nesta etapa, você passará um mesmo argumento candidato pela verificação e pela publicação. Comece em Live Website. Abra a exposição, Plan your visit e o download do guia. A entrada atual é East gate. Volte ao início por FIELDNOTES.
Mude para Workstation. cat mostra o fluxo fornecido:
cat pipeline.sh
O script inicial verifica e depois tenta publicar o pacote fixo packages/candidate.tar.gz. Linhas independentes continuam mesmo quando a anterior falha. O publicador também recusa um pacote não testado; você ainda precisa fazer o fluxo retornar falha e passar a entrada pretendida às duas etapas.
Bash guarda o primeiro argumento em $1. candidate="$1" o salva em uma variável. "$candidate" expande esse valor como um único argumento, mesmo que o caminho tenha espaços. && só executa o próximo comando quando o anterior termina com estado zero. Zero significa sucesso; um valor diferente de zero significa falha. O último comando executado determina o resultado deste pequeno script.
Substitua todo o script com o método here-document do primeiro laboratório. O último BASH encerra o bloco literal:
cat > pipeline.sh <<'BASH'
#!/bin/bash
candidate="$1"
python3 tools.py check "$candidate" &&
python3 tools.py publish "$candidate"
BASH
#!/bin/bash identifica o interpretador. Você executará explicitamente com bash, por isso não precisa alterar a permissão de execução. Os dois comandos recebem exatamente o mesmo argumento de pacote. Não adicione || true, remova verificações ou substitua o argumento por um pacote correto fixo.
Teste um candidato defeituoso; esta falha é intencional:
bash pipeline.sh packages/wrong.tar.gz
Espere FAIL: Wrong visitor guide content, sem linha Published. Consulte imediatamente o estado: $? é o estado de saída do comando anterior e echo o mostra. Execute isto separadamente, logo após o fluxo:
echo $?
Espere 1. Outro comando entre os dois substituiria esse estado. Em Live Website, recarregue e siga os links de visita e download: a referência saudável permanece disponível. Rejeitar uma publicação deve deixar o serviço funcionando.
Se aparecer um erro de sintaxe Bash, releia o arquivo salvo e restaure a receita mostrada. Um script quebrado não comprova uma barreira eficaz. A próxima etapa demonstrará que ele também aceita uma entrada válida.
Publicar o pacote testado
Nesta etapa, você permitirá que um candidato válido chegue ao site publicado e distinguirá os bytes do pacote salvo de uma cópia de trabalho editável. Comece em Workstation.
O pacote fornecido packages/candidate.tar.gz foi criado a partir de drafts/ na preparação. O fluxo deve usar esse pacote salvo, sem reconstruí-lo a partir dos rascunhos que possam mudar depois.
Primeiro, verifique explicitamente o candidato:
python3 tools.py check packages/candidate.tar.gz
Ele mostra sucesso e um identificador do pacote preservado. Agora simule uma edição comum após o empacotamento. > substitui apenas este arquivo de texto do rascunho; echo imprime o texto entre aspas:
echo 'UNREVIEWED DRAFT: use the West gate' > drafts/downloads/guide.txt
Confirme que o rascunho realmente mudou:
cat drafts/downloads/guide.txt
Ele mostra UNREVIEWED DRAFT: use the West gate. É uma edição intencional somente no rascunho. Não edite nem reconstrua o pacote salvo.
Execute o fluxo corrigido sobre o candidato salvo:
bash pipeline.sh packages/candidate.tar.gz
Espere PASS: visitor checks. Frozen package ..., seguido por Published frozen package ..., com o mesmo identificador. O executor testa uma cópia preservada e publica exatamente seus bytes; recusa bytes sem uma verificação bem-sucedida. O identificador é evidência auxiliar, não substitui a inspeção do site real.
Mude para Live Website, volte ao início por FIELDNOTES e recarregue. Abra Explore the exhibition, Plan your visit e Download visitor guide. A página e o download dizem East gate apesar da edição não revisada do rascunho. Abra também Step-free route e Download access guide; Garden ramp permanece. Confira a ilustração e os estilos.
Volte para Workstation. curl envia uma requisição HTTP; -sS oculta o progresso, mas mostra erros de conexão. 127.0.0.1 significa este ambiente e 8081 é a porta do servidor publicado. Execute essas requisições em Workstation, não no terminal do seu computador:
curl -sS http://127.0.0.1:8081/downloads/guide.txt
O corpo começa com FIELDNOTES Visitor Guide e contém Entrance: East gate. O site usa o pacote salvo, não o rascunho alterado. Se aparecer o texto do rascunho, examine a entrada publicada e execute novamente o fluxo correto sobre o candidato fornecido sem alterações.
Por fim, exercite a rejeição novamente:
bash pipeline.sh packages/missing.tar.gz
Espere a falha 404 intencional e nenhuma publicação. Em Live Website, recarregue e repita o download; o candidato aceito continua utilizável. O fluxo demonstrou as duas decisões. Este exercício protege a publicação local de um site estático; não implementa controle de acesso, assinaturas, CI hospedada nem reversão de migrações de banco de dados.
Resumo
Você usou execução condicional para interromper publicações defeituosas, passou um mesmo pacote pelas duas etapas e publicou exatamente seu conteúdo testado apesar de uma edição posterior do rascunho. Os percursos geral e acessível continuam disponíveis.
