Introdução
Cedar & Common está planejando um dia de atividades no bairro. Seu programa oficial já está disponível, e duas propostas de programação precisam de prévias separadas. O Jenkins consegue gerar builds de ambas as branches, mas seus Pipelines atuais publicam no mesmo lugar. Um build bem-sucedido, por si só, não manterá as duas ideias disponíveis.
Você descobrirá as branches, observará essa colisão, alterará seus Jenkinsfiles e publicará duas prévias utilizáveis. Depois, mudará um horário de encontro e confirmará que sua prévia é atualizada enquanto a outra proposta permanece intacta.
Os pré-requisitos são conhecimentos básicos de entrada de comandos e caminhos no terminal, navegação nas páginas do Jenkins e capacidade de reconhecer um Declarative Pipeline curto. Branches do Git, commits, push, indexação e as novas configurações de Pipeline são explicados antes do uso. O repositório, o gerador Java, o publicador e os plugins do Jenkins estão preparados; você não os instala nem escreve o site. Este é um serviço local de código-fonte e prévias para treinamento em uma única VM, e não o GitHub ou uma plataforma de implantação de produção. A duração é uma estimativa do autor, e não um tempo medido com iniciantes.
Descubra as propostas e seus builds de branch
Nesta etapa, você examinará os programas normais e o código-fonte das propostas, descobrirá seus jobs de branch e observará a colisão na prévia compartilhada. Comece em Preview Desk.
Selecione Open the official program. Confirme Common Ground Day e 09:30. Selecione Explore this plan e confira as três atividades e a ilustração do percurso. Selecione Download the activities para obter um CSV real e Read visitor notes para obter o texto completo. Use a ação Back do navegador para voltar à visão geral e depois Back novamente para voltar ao painel. Abra também Read the courtyard notes e confirme Courtyard Stories. Ambos os programas existentes devem continuar disponíveis durante todo o seu trabalho.
Mude para Source. Este terminal é uma cópia de trabalho do Git: os arquivos que você pode editar pertencem a uma branch selecionada por vez. Uma branch é uma linha de histórico de código-fonte com um nome. Trocar de branch altera os arquivos de trabalho para a versão dessa branch; isso não altera a outra branch. Um commit é uma versão registrada do conteúdo do repositório, identificada por um hash; esse identificador conectará um build do Jenkins ao seu código-fonte.
O terminal abre em /home/labex/project/community-site. pwd exibe o diretório atual. git --no-pager branch --list lista as branches locais, com * marcando a selecionada. --no-pager mantém o resultado diretamente no terminal. Sem essa opção, o Git pode abrir um visualizador interativo; se você vir (END) em vez de um prompt de shell, pressione q para sair do visualizador. Execute:
pwd
git --no-pager branch --list
A lista inclui main, courtyard-notes, garden-plan e river-plan. A seleção preparada é garden-plan. Se você mudar de diretório por engano, recupere o local com cd /home/labex/project/community-site antes de continuar.
cat exibe um arquivo sem alterá-lo. event.properties armazena uma configuração key=value por linha para o título, os detalhes do encontro e as atividades. Leia este pequeno arquivo de dados:
cat event.properties
Ele descreve Garden Gathering, com encontro às 10:00 em Glasshouse gate. A linha meeting_time é um dado usado pelo gerador fornecido, que produz as páginas, o CSV e as notas em conjunto.
git switch seleciona uma branch nesta cópia de trabalho. Compare a segunda proposta e depois volte:
git switch river-plan
cat event.properties
git switch garden-plan
A segunda proposta é Riverside Picnic, com encontro às 14:00 em River steps. Esses são arquivos de código-fonte realmente diferentes, e não uma única página com um marcador de branch diferente.
Seu escopo de edição é o Jenkinsfile das branches das propostas e a alteração de meeting_time em event.properties que será solicitada depois. Mantenha os templates, a imagem do percurso, o gerador e o publicador inalterados. Não edite, exclua, renomeie nem recrie o projeto Jenkins ou os jobs de branch preparados. Preserve todo o histórico do Git e do Jenkins e todos os arquivos compactados de prévia retidos, as branches main e courtyard-notes, o programa oficial e a prévia do pátio. Este exercício não exige Docker nem comandos de administrador.
Neste ponto, identifique qual proposta começa às 10:00 e qual começa às 14:00. Ainda não foi publicada nenhuma prévia das propostas.
Agora execute a descoberta nativa de branches do Jenkins e compare builds bem-sucedidos com seu resultado real de publicação. Mude para Jenkins e abra community-previews em Dashboard.
Este projeto pai preparado é um Multibranch Pipeline. Ele examina um repositório Git em busca de branches que contenham um Jenkinsfile e cria um job filho de Pipeline para cada uma. A origem usa um pequeno serviço Git somente para leitura dentro deste ambiente de treinamento; o origin preparado da cópia de trabalho é onde seus pushes posteriores publicarão alterações de código-fonte. Não são necessários uma conta externa nem credenciais.
Aguarde a página do Jenkins terminar de carregar e selecione Scan Multibranch Pipeline Now. Abra Scan Multibranch Pipeline Log e aguarde Finished: SUCCESS. A varredura descobre garden-plan e river-plan; main e courtyard-notes não contêm Jenkinsfile e não são jobs de propostas. Volte pelo link community-previews na trilha de navegação. Aguarde os dois builds filhos terminarem.
Abra garden-plan, depois seu build numerado e Console Output. Sua saída deve identificar Garden Gathering, 10:00 e a revisão do código-fonte obtida no checkout. Volte por community-previews, abra river-plan e examine o console de seu build numerado. Ele deve identificar Riverside Picnic, 14:00 e sua própria revisão do código-fonte. Ambos devem terminar com SUCCESS. Neste ambiente preparado, uma mensagem da ferramenta Git com Using Default pode aparecer antes de um checkout bem-sucedido; leia a revisão real e o resultado final para avaliar se o checkout foi concluído.
Mude para Source. Leia o Pipeline fornecido:
cat Jenkinsfile
options { skipDefaultCheckout() } desativa o checkout implícito de código-fonte do Declarative Pipeline para que o estágio visível Check out this branch o execute explicitamente. checkout scm usa a revisão específica da branch que forneceu este Jenkinsfile. Não o substitua por um checkout de uma branch fixa.
O estágio Build preview fornecido transforma esse código-fonte obtido no checkout em arquivos reais para visitantes. Archive preview retém preview.zip no Jenkins antes que Publish preview envie os mesmos bytes ao painel local. O bloco post final usa deleteDir() para limpar o workspace desse build. Mantenha esses estágios e a limpeza.
Um bloco environment fornece valores aos estágios. Atualmente, ambas as branches contêm esta mesma configuração:
PREVIEW_KEY = 'shared'
PREVIEW_KEY escolhe o endereço de publicação do painel. A string literal 'shared' envia os dois builds para um único local, embora seus checkouts de código-fonte sejam diferentes. Volte a Preview Desk e atualize a página. Há um cartão de proposta shared, mostrando a branch que publicou por último. Selecione seu link Open preview e compare o título com os dois builds de origem bem-sucedidos. Você não consegue compartilhar duas prévias independentes a partir desse único endereço.
Use a ação Back do navegador para voltar ao painel. O programa oficial e as notas do pátio ainda devem funcionar. Você agora observou por que jobs de branch separados não implicam automaticamente resultados publicados separados.
Dê a cada branch sua própria prévia
Nesta etapa, você alterará e publicará o Jenkinsfile de cada branch e depois gerará os builds das duas prévias independentes. Comece em Source, em /home/labex/project/community-site.
O Jenkins fornece env.BRANCH_NAME em um build Multibranch. É o nome da branch atual, como garden-plan. Substitua o valor compartilhado por essa identidade nativa de branch:
PREVIEW_KEY = "${env.BRANCH_NAME}"
As aspas duplas do Groovy permitem que ${...} insira o valor da variável. Aspas simples ao redor dessa expressão preservariam seus caracteres literais. Os nomes de branch deste exercício já usam letras minúsculas simples e hífens adequados para endereços de prévia; isso não é uma regra geral de sanitização para nomes arbitrários de branch.
Primeiro selecione a proposta do jardim. git status --short mostra alterações ainda não commitadas em formato compacto; M significa um arquivo modificado, e nenhuma saída significa que a cópia de trabalho está limpa. nano é um editor de terminal para o arquivo indicado; ele mantém o controle deste terminal até você salvar e sair.
git switch garden-plan
git status --short
nano Jenkinsfile
nano edita o arquivo indicado neste terminal. Use as teclas de seta para chegar à linha PREVIEW_KEY. Pressione Home para ir ao início dela e depois Ctrl+K uma vez para recortar essa única linha. Digite a linha de substituição completa mostrada acima, incluindo sua indentação, e pressione Enter para manter a linha RECEIVER_URL seguinte separada. Não recorte outras linhas. Salve com Ctrl+O, pressione Enter para confirmar Jenkinsfile e saia com Ctrl+X. Aqui, Ctrl significa manter a tecla Control pressionada, inclusive no macOS.
Examine sua edição antes de salvá-la no histórico do Git. git diff compara o arquivo de trabalho com sua versão commitada. Como antes, --no-pager exibe diretamente no terminal; -- separa as opções do caminho do arquivo. Execute:
git --no-pager diff -- Jenkinsfile
O diff deve mostrar apenas a linha antiga de PREVIEW_KEY removida e a nova adicionada. Os prefixos - e + descrevem texto removido e adicionado; eles não são caracteres a digitar no arquivo. Se o diff incluir uma alteração não intencional, reabra nano Jenkinsfile, corrija-a, salve, saia e examine novamente. Se você vir um erro de arquivo não encontrado, execute pwd e volte ao diretório de trabalho indicado acima.
Um commit registra a alteração de código-fonte preparada na branch selecionada. git add prepara esse arquivo; git commit -m o registra com a mensagem fornecida; git push origin garden-plan publica essa branch no repositório de origem preparado para que o Jenkins possa descobrir o novo commit. Nesses comandos de commit, as aspas duplas mantêm a mensagem de várias palavras unida como um único argumento. Esses comandos alteram o histórico de código-fonte, e não diretamente a prévia em execução:
git add Jenkinsfile
git commit -m "Give the garden plan its own preview"
git push origin garden-plan
Agora aplique a mesma configuração à outra proposta:
git switch river-plan
git status --short
nano Jenkinsfile
Substitua apenas sua linha PREVIEW_KEY usando a mesma operação do nano e a expressão exata entre aspas duplas. Salve e saia. Examine, faça o commit e o push dessa branch:
git --no-pager diff -- Jenkinsfile
git add Jenkinsfile
git commit -m "Give the river plan its own preview"
git push origin river-plan
Se o Git recusar a troca de branch por haver alterações não commitadas, execute git status --short e examine primeiro o diff na branch atual. Conclua ou corrija essa edição pretendida antes de trocar; não descarte arquivos nem redefina o repositório. Se git commit disser que não há nada para commitar depois de você já ter commitado a edição pretendida, examine git --no-pager log -1 --oneline e prossiga com o push da branch. -1 limita essa visualização a um commit; --oneline mostra seu identificador curto e sua mensagem.
Mude para Jenkins, volte a community-previews usando a trilha de navegação e selecione Scan Multibranch Pipeline Now novamente. Não há webhook neste exercício local, portanto apenas enviar o código-fonte por push não solicita uma varredura. Aguarde a varredura e os dois novos builds filhos terminarem com sucesso. Cada console deve mostrar a chave de prévia de sua própria branch. Se um build informar um erro de sintaxe do Groovy, corrija as aspas e as chaves do Jenkinsfile em Source, faça o commit e o push da correção nessa branch e depois execute a varredura novamente. Não edite um job filho gerado em vez de seu código-fonte.
Mude para Preview Desk e atualize a página. Agora devem existir cartões separados garden-plan e river-plan. O cartão compartilhado antigo pode permanecer como o resultado anterior observado. Abra o link Open preview de cada proposta e confira seu título correto, horário de encontro, três atividades, imagem do percurso, CSV e notas para visitantes. Depois de explorar uma proposta, use a ação Back do navegador para voltar à sua visão geral e depois Back novamente para voltar ao painel antes de abrir o outro cartão. Os dois endereços de prévia devem ser diferentes e continuar utilizáveis ao mesmo tempo.
Procure as chaves garden-plan e river-plan acima de seus respectivos títulos e horários de encontro originais. O cartão shared retido mostra a colisão anterior; ele não substitui nenhuma das prévias independentes.
Em Jenkins, abra a página de status do build bem-sucedido mais recente de cada branch e baixe preview.zip em Build Artifacts. Extraia cada ZIP para uma nova pasta diferente e abra index.html. Mantenha os sete arquivos juntos. As páginas e os anexos devem funcionar localmente; um anexo de texto pode abrir diretamente em vez de iniciar outro download. build.json identifica a branch e o commit reais de origem. Essas prévias completas são o resultado; dois rótulos verdes de build, por si só, são insuficientes.
Atualize uma proposta e preserve a outra
Nesta etapa, você alterará o horário de encontro do jardim e usará outra varredura para atualizar apenas a prévia dessa branch. Comece em Jenkins e anote o número do build bem-sucedido mais recente de river-plan. Mantenha sua prévia aberta para comparação.
Mude para Source. Selecione a branch do jardim e edite seu pequeno arquivo de dados:
git switch garden-plan
git status --short
nano event.properties
Altere apenas a linha completa meeting_time de meeting_time=10:00 para:
meeting_time=10:30
Use a mesma operação com as teclas de seta, Home, um Ctrl+K, o texto de substituição e Enter usada para a linha do Pipeline. Salve com Ctrl+O, Enter e saia com Ctrl+X. O gerador lê esse único valor para manter a página, o CSV e as notas consistentes; você não edita os arquivos gerados para visitantes.
Revise e publique essa atualização de código-fonte:
git --no-pager diff -- event.properties
git add event.properties
git commit -m "Move the garden meeting to 10:30"
git push origin garden-plan
O diff deve alterar apenas esse horário de encontro. Se não for o caso, corrija o arquivo antes de fazer o commit. A branch do rio não recebe nenhuma alteração de código-fonte.
Mude para Jenkins, volte a community-previews e selecione Scan Multibranch Pipeline Now. Após a indexação, o job do jardim deve executar um novo build para sua revisão alterada; a branch do rio, que não foi alterada, deve manter o número de build que você anotou. Aguarde o build do jardim terminar com SUCCESS. Abra seu Console Output e relacione o novo commit e 10:30 à alteração de código-fonte.
Se a varredura disser que não há alterações e a prévia do jardim continuar antiga, volte a Source. Confira git status --short e git --no-pager log -1 --oneline, confirme que a alteração pretendida foi commitada em garden-plan e faça o push dessa branch antes de executar outra varredura. Uma edição ou um commit local que não chegou à origem ainda não é código-fonte que o Jenkins possa descobrir. Se um build falhar, leia seu console e corrija o erro de código-fonte indicado por meio de outro commit e push. Não reinicialize a VM nem substitua o gerador fornecido.
Mude para Preview Desk e atualize a página. Abra garden-plan: Garden Gathering agora deve ter encontro às 10:30. Examine Explore this plan, o CSV de atividades baixado e as notas completas para visitantes; o horário de encontro deve ser o mesmo em todos eles. Abra river-plan: Riverside Picnic ainda deve ter encontro às 14:00, com suas atividades originais e anexos funcionais. Seu build.json deve manter o commit de origem e o número de build nativo anteriores. Não execute novamente esse job filho inalterado durante esta atualização final.
Volte a Jenkins e baixe o preview.zip mais recente do jardim. Extraia-o para outra pasta nova e repita as verificações locais de página, imagem, CSV e notas. Ele deve identificar o novo commit do jardim; o pacote do rio baixado anteriormente ainda deve ser utilizável de forma independente.
Por fim, volte a Preview Desk, abra Open the official program e Read the courtyard notes e confirme que ambos os programas completos permanecem intactos. Preserve os históricos originais de branches e builds. Se fizer qualquer outra edição de código-fonte, faça o commit, o push e conclua o build correspondente do Jenkins antes de verificar a conclusão. Você tem duas prévias em execução e evidências de que atualizar uma não sobrescreveu nem gerou novamente o build de sua vizinha.
Resumo
Você usou a descoberta nativa do Multibranch e a revisão de código-fonte por trás de cada Jenkinsfile e depois separou a publicação pela identidade de branch do Jenkins. Ambas as propostas agora têm páginas, imagens e anexos utilizáveis em endereços independentes. Um commit posterior do jardim atualizou apenas sua própria prévia, enquanto o build do rio, o programa oficial e a prévia do pátio permaneceram intactos.
