Praticar de graça

⌨️aws codepipeline get-pipeline-state

USO.

Manual do comando

É o mesmo texto que aws codepipeline get-pipeline-state help devolve dentro do CLImb.

USO
    aws codepipeline get-pipeline-state --name <esteira>

O painel da esteira: cada estágio com a última execução, o status de cada
ação, o errorDetails de quem falhou, o token de aprovação pendente e se a
porta de entrada (inboundTransitionState) está aberta.

Resumo em texto:
    ... --query stageStates[].[stageName,latestExecution.status] --output text

Onde você pratica isto (14 atividades)

Cada uma é um pedido de trabalho real; você resolve digitando o comando, e o estado fica salvo pro exercício seguinte.

Acompanhe a primeira passada

A esteira está rodando desde a criação. Olhe o painel dela — e olhe de novo até os três estágios ficarem Succeeded. Cada olhada avança um estágio.

O painel em uma linha por estágio

O painel completo é grande. Traga só estágio e status de cada um, em texto — o formato que cabe na mensagem do chat.

Rode de novo

O time trocou a máquina de build e quer ver a esteira passar de novo, do começo. Dispare uma execução nova da portal-rh-esteira e acompanhe até o fim.

A esteira esperando a gerente

Rode a esteira e acompanhe até ela parar no estágio Aprovacao. No painel, ache o token do pedido de aprovação.

Chegou na produção?

Depois da aprovação, a esteira seguiu pro deploy. Acompanhe até a execução aprovada terminar.

Hoje não: véspera de feriado

Outra execução chegou na aprovação, mas é véspera de feriado e a gerente não quer deploy hoje. Rode a esteira, acompanhe até a aprovação e rejeite com o resumo Vespera de feriado.

Agora pode

Aprove o pedido novo da execução repetida (resumo Liberado apos o feriado) e acompanhe até ela chegar na produção.

O commit que quebrou o build

Um dev trocou o buildspec da main por um com exit 1 (um teste que sempre falha). Reproduza: crie o buildspec.yml com o texto exit 1, grave na main do portal-rh (mensagem Buildspec novo), rode a esteira e acompanhe até ela falhar no Build.

Retry não pega commit novo

O dev corrigiu: grave o buildspec.yml com version: 0.2 na main (mensagem Conserta buildspec). Aí tente o atalho: repita o estágio Build da execução que falhou e acompanhe. Repare no resultado — e no porquê.

Agora sim: commit novo, execução nova

Retry repete o código velho. O código consertado entra com uma execução nova. Rode a esteira, acompanhe até a aprovação, aprove (resumo Build consertado) e acompanhe até a produção.

A execução espera na porta

Veja o congelamento funcionando: rode a esteira, acompanhe, aprove quando pedir (resumo Pronto pra janeiro) e olhe o painel — a execução fica esperando na porta do Deploy, sem falhar.

Janeiro chegou

Fim do congelamento. Abra a porta do estágio Deploy e acompanhe a execução que estava esperando chegar na produção.

Parada com motivo registrado

Uma execução chegou na aprovação, mas a versão foi cancelada pelo produto. Rode, acompanhe até a aprovação e pare a execução com --abandon e o motivo Versao cancelada pelo produto. Depois confira no histórico que o motivo ficou registrado.

A esteira da intranet antiga

Existe uma planta velha, esteira-intranet.json, da intranet que foi desligada. Crie a esteira, olhe o painel e descubra por que ela falha logo no primeiro estágio. Depois, apague a intranet-esteira.

Outros comandos com página própria

Ler a sintaxe explica. Digitar fixa. No CLImb você roda aws codepipeline get-pipeline-state num terminal AWS simulado e vê a saída — inclusive a mensagem de erro, quando erra a flag.

Praticar no terminal
Todas as lições · Praticar no terminal · Sobre