Mantenha o aviso mais recente publicado

Introdução

Pine & Path está preparando uma caminhada pelo jardim. Um editor pede um início mais tarde; depois, outro altera o ponto de encontro. O Jenkins pode preparar e publicar qualquer um dos avisos, mas uma execução antiga aguardando aprovação pode sobrescrever o anúncio mais recente depois que ele já chegou aos visitantes.

Você verá essa sobrescrita acontecer e depois alterará o Pipeline para que uma nova execução substitua automaticamente uma execução antiga em espera. Seu resultado é um aviso real para visitantes e um pacote de sete arquivos para download, com percurso, programação e notas correspondentes à solicitação mais recente.

Os pré-requisitos são navegação básica nas páginas do Jenkins e capacidade de reconhecer um Declarative Pipeline curto. Parâmetros, pausas para aprovação e a configuração de concorrência são explicados aqui. O Jenkins, dois executores do controlador, as ferramentas de avisos e o Notice Desk local estão preparados. Você não instala software nem escreve o site. Ambas as interfaces funcionam em uma única VM de treinamento; este é um publicador local controlado, e não uma plataforma de implantação de produção. A duração é uma estimativa do autor, e não um tempo medido com iniciantes.

Observe uma aprovação tardia sobrescrever um aviso

Nesta etapa, você publicará o aviso mais recente e depois observará uma execução antiga em espera sobrescrevê-lo. Comece em Notice Desk. Mantenha esta interface aberta; trocar de interface não reinicia um build nem redefine o aviso.

Examine a experiência normal do visitante

O primeiro evento é a caminhada pelo jardim. Selecione seu link View notice. O aviso fornecido começa às 10:00 em Community Gate. Abra Open the route e examine as três paradas. Use a ação Back do navegador para voltar ao aviso. Abra Read visitor notes, leia as instruções de encontro e use Back novamente. Schedule table é um arquivo CSV: uma tabela simples cujos campos são separados por vírgulas. Notice details é JSON: valores com rótulos que descrevem o mesmo evento. Preparation record identifica como esse pacote foi preparado. Neste ponto, ele informa honestamente PROVIDED BASELINE; a preparação do ambiente não executou o job do Jenkins por você.

Use a ação Back do navegador para voltar à página inicial do Notice Desk. Selecione Download notice pack para a caminhada pelo jardim e salve o arquivo ZIP. Um ZIP mantém vários arquivos juntos. Extraia todo o arquivo compactado para uma nova pasta usando a ferramenta de arquivos compactados do seu computador e abra seu index.html. Mantenha os sete arquivos vizinhos juntos. O percurso, a folha de estilo, a programação, as notas, o JSON e o registro de preparação são arquivos locais reais; mover apenas index.html quebrará seus links para arquivos vizinhos. Seu navegador pode abrir um arquivo CSV/texto ou baixá-lo; ambos os comportamentos servem para ler os bytes salvos.

Volte à página inicial do Notice Desk. Examine o aviso separado Seed Swap e seu download. Ele começa às 11:00 em Potting Shed e deve permanecer inalterado. As próximas solicitações dos editores dizem respeito apenas à caminhada pelo jardim.

Selecione Read the editor requests. A solicitação anterior usa o valor de UPDATE later-start: 10:30, ainda em Community Gate. A solicitação mais recente é new-meeting-point: mantenha 10:30, com encontro em Glasshouse Gate. Aqui, “mais recente” significa a solicitação posterior do editor, e não o build que por acaso terminar por último.

Leia o Pipeline preparado

Mude para Jenkins. Abra publish-walk-notice e depois Configure. Encontre a seção Pipeline e seu editor Script. Este é um Declarative Pipeline: o bloco externo pipeline { ... } descreve o trabalho, e pares de chaves agrupam suas configurações e seus estágios.

O job usa agent any, que aloca um executor e um workspace em um nó preparado disponível. Um executor é uma vaga do Jenkins para executar trabalho; um workspace é o diretório de trabalho de uma execução. Este controlador de treinamento tem dois executores, portanto duas execuções desse job podem se sobrepor. Elas têm diretórios de trabalho separados, mas publicam no mesmo aviso do jardim.

O bloco parameters define valores escolhidos para cada build. choice oferece as duas solicitações dos editores como UPDATE. booleanParam faz de HOLD_FOR_REVIEW uma caixa de seleção: marcada significa true, desmarcada significa false. params.HOLD_FOR_REVIEW lê o valor escolhido para essa execução. Uma condição when executa seu estágio apenas quando a expressão é verdadeira.

Os três estágios têm finalidades distintas:

• Prepare notice limpa o workspace da execução com deleteDir(), chama o programa de preparação fornecido com sh e arquiva notice-pack.zip. archiveArtifacts mantém esse arquivo exato com o build nativo. fingerprint: true registra sua identidade de conteúdo e o build associado. Preparar e arquivar não alteram o aviso para visitantes.
• Review notice usa input para pausar uma execução com a caixa marcada antes da publicação. Seu link Proceed permite o próximo estágio; Abort cancela essa execução. Esta é uma pausa intencional, e não uma falha de conexão.
• Publish notice envia o pacote preparado ao Notice Desk local. O bloco post { always { ... } } limpa o workspace quando a execução termina, inclusive em caso de interrupção. Os arquivos nativos arquivados continuam disponíveis após a limpeza do workspace.

Os programas de preparação e publicação fornecidos leem os parâmetros e o arquivo compactado do build real. Mantenha esses programas, todos os estágios, a condição de revisão, o registro de fingerprints e ambas as operações de limpeza. Na próxima etapa, você alterará apenas como as execuções sobrepostas são tratadas. Por enquanto, deixe o Script inalterado. Selecione Save para voltar ao job.

Inicie uma execução antiga e deixe-a em espera

Na página do job publish-walk-notice, selecione Build with Parameters. Selecione later-start em UPDATE e marque HOLD_FOR_REVIEW clicando em seu rótulo ou na caixa de seleção. Selecione Build uma vez.

Abra a execução recém-iniciada em Build History; em um job sem alterações anteriores, ela é #1. Abra Console Output. Aguarde Release this selected notice? com os links Proceed e Abort. Deixe-a em espera. O console já informou a preparação e o arquivamento. O aviso para visitantes compartilhado do job ainda é o inicial, porque Publish notice não foi executado.

Use publish-walk-notice na trilha de navegação no topo para voltar à página do job. Isso navega dentro do Jenkins; é diferente de mudar para a interface Notice Desk. Anote o número da execução antiga para poder voltar ao seu console em espera.

Selecione Build with Parameters novamente. Desta vez, selecione new-meeting-point e deixe HOLD_FOR_REVIEW desmarcado. Selecione Build uma vez. Abra Console Output dessa nova execução e aguarde Finished: SUCCESS. Em um job sem alterações anteriores, ela é #2.

Mude para Notice Desk e recarregue sua página inicial. Abra o aviso do jardim: 10:30 e Glasshouse Gate devem aparecer agora. Abra seu percurso e suas notas para visitantes e confirme o mesmo ponto de encontro. A solicitação mais recente do editor está realmente publicada.

Continue a execução antiga

Mude de volta para Jenkins. Volte ao job, abra a execução antiga anotada e seu Console Output e selecione seu link Proceed. Aguarde Finished: SUCCESS. Se você estiver com um console desatualizado aberto, recarregue o console dessa execução antes de selecionar o link; não inicie outro build apenas para atualizar uma página.

Mude para Notice Desk, recarregue e examine o aviso do jardim novamente. Agora ele informa 10:30 em Community Gate. Esta é a falha esperada: a execução antiga terminou mais tarde e sobrescreveu a solicitação mais recente. Ambas as execuções do Jenkins tiveram sucesso, mas o resultado de negócio ficou desatualizado.

Baixe esse pacote atual para uma pasta diferente. Seu publication.txt nomeia a execução antiga do Jenkins; seu percurso, sua programação e suas notas correspondem à solicitação antiga. Volte ao Jenkins e abra o link Build Artifacts desse build antigo para baixar seu notice-pack.zip nativo. O Notice Desk entregou esse arquivo compactado realmente preparado, em vez de gerar silenciosamente outro aviso.

Se uma execução estiver em espera inesperadamente, examine seus Parameters escolhidos e o console. Você pode selecionar Abort em seu pedido de entrada para cancelar uma execução acidental em espera e depois iniciar novamente com os parâmetros pretendidos. Mantenha todo o histórico de builds. Uma mensagem de falha antes do pedido de entrada é diferente da pausa esperada para aprovação; leia seu console e volte a Configure para restaurar os estágios fornecidos se você os editou por engano.

Autoverificação: você manteve os dois builds genuínos bem-sucedidos, a aprovação real da execução anterior e o resultado desatualizado para visitantes. O aviso separado do Seed Swap e seu download ainda funcionam. Os reparos posteriores não apagarão essas evidências.

Deixe novas execuções substituírem as antigas em espera

Nesta etapa, você impedirá que uma aprovação antiga sobrescreva a solicitação mais recente. Comece em Jenkins, na página do job publish-walk-notice.

Adicione a política de sobreposição do mesmo job

O bloco options de um Pipeline controla o comportamento das execuções. disableConcurrentBuilds(), por si só, faz novas execuções esperarem em uma fila até que a execução atual termine. Isso deixaria a aprovação antiga no controle. Já a configuração abortPrevious: true interrompe uma execução antiga quando uma execução mais nova desse mesmo job começa. true é um valor booleano, e não texto entre aspas. Os dois-pontos passam essa opção nomeada à configuração.

Selecione Configure, encontre Pipeline → Script e insira a linha a seguir diretamente após agent any, dentro do bloco externo pipeline e antes de parameters:

    options { disableConcurrentBuilds(abortPrevious: true) }

O início agora deve ser:

pipeline {
    agent any
    options { disableConcurrentBuilds(abortPrevious: true) }
    parameters {

Esse pequeno trecho mostra a posição; não substitua o Script inteiro pelo trecho. Mantenha os parâmetros, os estágios, o arquivamento e a limpeza existentes. Selecione Save. Salvar altera as execuções futuras; você deve executar um novo par para demonstrar seu efeito.

Observe a substituição automática

Na página do job, selecione Build with Parameters, selecione later-start, marque HOLD_FOR_REVIEW e selecione Build. Abra Console Output da nova execução mais antiga e aguarde o pedido real Proceed / Abort. Em uma sequência sem tentativas adicionais, ela é #3. Deixe-a em espera; não a cancele manualmente nem prossiga com ela.

Volte ao job pela trilha de navegação. Selecione Build with Parameters, selecione new-meeting-point, deixe HOLD_FOR_REVIEW desmarcado e selecione Build. Abra o console dessa execução mais nova e aguarde Finished: SUCCESS. Em uma sequência sem tentativas adicionais, ela é #4.

Abra o console da execução antiga em espera e recarregue-o. Na versão preparada do Jenkins, a execução fica NOT_BUILT, com Superseded by #... nomeando a execução mais nova. O estágio antigo Publish notice foi ignorado, e a limpeza ainda foi executada. Um status cinza, por si só, não basta: leia a causa da substituição e compare o número do build mais novo. A entrada antiga não está mais aguardando sua aprovação. O console histórico ainda pode exibir seu texto anterior de Proceed/Abort; não use esses links antigos após a substituição.

Leia Superseded by #... e o estágio de publicação ignorado e depois compare o resultado final NOT_BUILT.

Aqui, NOT_BUILT não significa que nenhum trabalho aconteceu. A execução antiga preparou e arquivou seu pacote antes da pausa. Abra seus Build Artifacts e confirme que notice-pack.zip ainda pode ser baixado. O que a política impediu foi a publicação posterior desse pacote desatualizado. A limpeza dos workspaces de ambas as execuções deixa esses arquivos arquivados intactos.

Mude para Notice Desk, recarregue e abra o aviso do jardim. Ele deve mostrar 10:30 em Glasshouse Gate. Leia o percurso, as notas e a programação.

Confira 10:30, Glasshouse Gate e a primeira parada do percurso em conjunto. Volte à página inicial e verifique se o Seed Swap ainda começa às 11:00 em Potting Shed.

Pratique o cancelamento de uma pausa acidental para aprovação

Mude para Jenkins. Inicie mais um build later-start com HOLD_FOR_REVIEW marcado. Aguarde o pedido de entrada no console e selecione Abort. Este é um cancelamento manual deliberado, que termina como ABORTED. Ele é diferente da substituição automática que você já observou e não substitui essa evidência. O aviso publicado permanece em Glasshouse Gate porque essa execução nunca publicou.

Inicie um build final new-meeting-point com HOLD_FOR_REVIEW desmarcado e aguarde SUCCESS. Esta é a ação de recuperação se você pausar ou cancelar a solicitação errada por engano: examine a página dos editores, selecione a solicitação mais recente e execute o build sem pausa. Mantenha as execuções antigas; excluir o histórico removeria evidências do comportamento da política.

Se salvar um Script produzir FAILURE com uma mensagem de sintaxe, confira os pares de chaves e certifique-se de que a linha options está dentro de pipeline, e não dentro de stages ou de steps de um estágio. Corrija em Configure, salve e inicie novamente o par pretendido. Não reinicialize a VM nem modifique as ferramentas fornecidas. Tentativas extras com falha podem permanecer no histórico.

Guarde e examine a entrega final

Mude para Notice Desk. Recarregue e baixe o notice pack do jardim. Salve-o em uma nova pasta em vez de misturar arquivos de downloads anteriores. Extraia todo o ZIP e abra index.html. Confirme Glasshouse Gate, 10:30, o percurso ilustrado e as três paradas. Abra Read visitor notes, Schedule table, Notice details e Preparation record. O CSV e o JSON devem corresponder à página; publication.txt nomeia o job e o build finais bem-sucedidos do Jenkins. A pasta completa funciona localmente sem Jenkins nem Notice Desk. Use a ação Back do navegador entre as visualizações de arquivos locais.

Em Jenkins, abra o build bem-sucedido correspondente e Build Artifacts e baixe notice-pack.zip. Seus sete arquivos extraídos devem corresponder ao download do Notice Desk. Os arquivos nativos do Jenkins documentam o que um build preparou; o Notice Desk mostra o que foi realmente publicado.

Autoverificação: a política salva está ativa, uma execução genuína mais nova substituiu automaticamente uma execução antiga pausada na entrada, e os visitantes recebem os arquivos reais da solicitação mais recente. O par de execução pausada e execução mais nova deve ter executado esse Script salvo. Sua execução concluída mais recente deve ser, ela própria, uma publicação bem-sucedida da solicitação mais recente; após uma publicação incorreta ou ignorada, restaure o Script e execute novamente. Se alterar seu comportamento outra vez, demonstre um novo par de execução pausada e execução mais nova. Todo o histórico de builds, os arquivos compactados anteriores, o comportamento de preparação, revisão, publicação e limpeza e o evento sem relação com a alteração permanecem intactos.

Essa configuração afeta a sobreposição em um único job. Ela não pode desfazer uma publicação ocorrida antes da interrupção, coordenar jobs diferentes nem tornar seguro o cancelamento de qualquer implantação de produção. Aqui, a execução antiga pausa antes de sua única etapa de publicação, o que torna o limite claro.

Resumo

Você conectou um resultado real para visitantes ao comportamento das execuções do Jenkins. Reproduziu uma aprovação antiga sobrescrevendo um aviso mais novo e depois usou disableConcurrentBuilds(abortPrevious: true) para fazer novas execuções interromperem execuções antigas em espera do mesmo job. Você distinguiu preparação de publicação, substituição nativa de cancelamento manual e arquivos arquivados de arquivos do workspace.

Seu produto final é o aviso mais recente do jardim com percurso, programação e notas offline correspondentes. O histórico preservado mostra por que seu build bem-sucedido significa que a atualização pretendida realmente chegou aos visitantes.