USO.
É o mesmo texto que aws codepipeline get-pipeline help devolve dentro do CLImb.
USO
aws codepipeline get-pipeline --name <esteira>
A planta da esteira (estágios, ações, configuração) e o metadata (ARN,
datas). Só os nomes dos estágios:
... --query pipeline.stages[].name
Cada uma é um pedido de trabalho real; você resolve digitando o comando, e o estado fica salvo pro exercício seguinte.
Confira como a AWS guardou a portal-rh-esteira: estágios, ações e o metadata (ARN e datas).
Pra documentação do time, traga só os nomes dos estágios da portal-rh-esteira, na ordem.
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 completo é grande. Traga só estágio e status de cada um, em texto — o formato que cabe na mensagem do chat.
A auditoria pergunta qual versão do código a última execução levou. Consulte a execução pelo id e veja o artifactRevisions.
O relatório de mudanças só quer o id do commit que a última execução levou.
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.
Rode a esteira e acompanhe até ela parar no estágio Aprovacao. No painel, ache o token do pedido de aprovação.
Depois da aprovação, a esteira seguiu pro deploy. Acompanhe até a execução aprovada terminar.
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.
Aprove o pedido novo da execução repetida (resumo Liberado apos o feriado) e acompanhe até ela chegar na produção.
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.
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ê.
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.
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.
Fim do congelamento. Abra a porta do estágio Deploy e acompanhe a execução que estava esperando chegar na produção.
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.
O time passou a aprovar no próprio pull request, então o estágio de aprovação saiu da esteira. Volte a esteira pra planta original, esteira-portal-rh.json, e confira a versão.
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.
aws s3 mbaws s3 cpaws ec2 run-instancesaws ec2 create-security-groupaws ec2 authorize-security-group-ingressaws iam create-policyaws iam create-useraws iam create-roleaws lambda create-functionaws dynamodb create-tableLer a sintaxe explica. Digitar fixa. No CLImb você roda
aws codepipeline get-pipeline num terminal AWS simulado e vê a saída — inclusive
a mensagem de erro, quando erra a flag.