Definição do YAML do fluxo de trabalho
Veja a seguir a documentação de referência do arquivo de definição do fluxo de trabalho.
Arquivo de definição de fluxo de trabalho é um arquivo YAML que descreve o fluxo de trabalho. Por padrão, o arquivo é armazenado em uma pasta ~/.codecatalyst/workflows/
na raiz do repositório de origem. O arquivo pode ter uma extensão .yml ou .yaml, e a extensão deve estar em minúsculas.
Para criar e editar o arquivo de definição de fluxo de trabalho, use um editor, como o vim, ou use o editor visual ou o editor YAML do console do CodeCatalyst. Para ter mais informações, consulte Usar os editores visual e YAML do console do CodeCatalyst.
nota
A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use Ctrl+F. O elemento será listado com a propriedade YAML associada.
Tópicos
Exemplo de um arquivo de definição de fluxo de trabalho
Veja a seguir um exemplo de um arquivo de definição de fluxo de trabalho simples. Inclui algumas propriedades de nível superior, uma seção Triggers
e uma seção Actions
com duas ações: Build
e Test
. Para ter mais informações, consulte Sobre o arquivo de definição do fluxo de trabalho.
Name: MyWorkflow
SchemaVersion: 1.0
RunMode: QUEUED
Triggers:
- Type: PUSH
Branches:
- main
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: docker build -t MyApp:latest .
Test:
Identifier: aws/managed-test@v1
DependsOn:
- Build
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
Diretrizes e convenções de sintaxe
Esta seção descreve as regras de sintaxe para o arquivo de definição do fluxo de trabalho, bem como as convenções de nomenclatura usadas nesta documentação de referência.
Diretrizes de sintaxe do YAML
O arquivo de definição do fluxo de trabalho é escrito em YAML e segue a especificação YAML 1.1
-
Diferenciação entre maiúsculas e minúsculas: o arquivo de definição do fluxo de trabalho diferencia maiúsculas de minúsculas, portanto, certifique-se de usar as maiúsculas e minúsculas mostradas nesta documentação.
-
Caracteres especiais: recomendamos o uso de aspas ou aspas duplas em torno dos valores das propriedades que incluam qualquer um dos seguintes caracteres especiais:
{
,}
,[
,]
, &,*
,#
,?
,|
,-
, < , >,=
,!
,%
,@
,:
,`
e,
Se você não incluir as aspas, os caracteres especiais listados anteriormente poderão ser interpretados de forma inesperada.
-
Nomes de propriedades: os nomes das propriedades (em oposição aos valores das propriedades) são limitados a caracteres alfanuméricos (a-z, 0-9), hifens (-) e sublinhados (_). Não são permitidos espaços. Você não pode usar aspas ou aspas duplas para ativar caracteres especiais e espaços nos nomes das propriedades.
Não permitido:
'My#Build@action'
My#Build@action
My Build Action
Permitido:
My-Build-Action_1
-
Códigos de escape: se o valor da sua propriedade incluir códigos de escape (por exemplo,
\n
ou\t
), siga estas diretrizes:-
Use aspas simples para retornar o código de escape como uma string. Por exemplo,
'my string \n my string'
, retorna a stringmy string \n my string
. -
Use aspas duplas para analisar o código de escape. Por exemplo,
"my string \n my new line"
, retorna:my string my new line
-
-
Comentários: prefacie os comentários com
#
.Exemplo:
Name: MyWorkflow # This is a comment. SchemaVersion: 1.0
-
Traço triplo (
---
): não use---
em seu código YAML. O CodeCatalyst ignora tudo depois do---
.
Convenções de nomenclatura
Neste guia, usamos os termos propriedade e seção para nos referirmos aos itens principais em um arquivo de definição de fluxo de trabalho.
-
Uma propriedade é qualquer item que inclua dois pontos (
:
). Por exemplo, no trecho de código a seguir, todas as seguintes são propriedades:Name
,SchemaVersion
,RunMode
,Triggers
,Type
eBranches
. -
Uma seção é qualquer propriedade que tenha subpropriedades. No trecho de código a seguir, há uma seção
Triggers
.nota
Neste guia, as “seções” às vezes são chamadas de “propriedades” e vice-versa, dependendo do contexto.
Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main
Propriedades de nível superior
Veja a seguir a documentação de referência das propriedades de nível superior do arquivo de definição do fluxo de trabalho.
# Name
Name: workflow-name
# Schema version
SchemaVersion: 1.0
# Run mode
RunMode: QUEUED|SUPERSEDED|PARALLEL
# Compute
Compute:
...
# Triggers
Triggers:
...
# Actions
Actions:
...
Name
(Obrigatório)
O nome do fluxo de trabalho. O nome do fluxo de trabalho é mostrado na lista de fluxos de trabalho e mencionado nas notificações e nos logs. O nome do fluxo de trabalho e o nome do arquivo de definição do fluxo de trabalho podem corresponder, ou você pode nomeá-los de forma diferente. Os nomes de fluxos de trabalho não precisam ser exclusivos. Os nomes de fluxos de trabalho são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (_). Não são permitidos espaços. Você não pode usar aspas para habilitar caracteres especiais e espaços nos nomes de fluxo de trabalho.
UI correspondente: editor visual/propriedades do fluxo de trabalho/nome do fluxo de trabalho
SchemaVersion
(Obrigatório)
A versão do esquema da definição do fluxo de trabalho. Atualmente, o único valor válido é 1.0
.
Interface de usuário correspondente: nenhuma
RunMode
(Opcional)
Como o CodeCatalyst lida com várias execuções. É possível usar um dos seguintes valores:
-
QUEUED
– Várias execuções são colocadas em fila e executadas uma após a outra. É possível ter até 50 execuções em uma fila. -
SUPERSEDED
– Várias execuções são colocadas em fila e executadas uma após a outra. Uma fila só pode ter uma execução, portanto, se duas execuções terminarem juntas na mesma fila, a execução posterior substituirá a execução anterior e a execução anterior será cancelada. -
PARALLEL
– Várias execuções ocorrem simultaneamente.
Se essa propriedade for omitida, o padrão será QUEUED
.
Para ter mais informações, consulte Configurar o comportamento de enfileiramento das execuções.
UI correspondente: editor visual/propriedades do fluxo de trabalho/Avançado/Modo de execução
Compute
(Opcional)
O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para ter mais informações, consulte Compartilhamento de computação entre ações.
Para ter mais informações sobre computação, consulte Configuração de imagens de computação e runtime.
Interface de usuário correspondente: nenhuma
Name: MyWorkflow
SchemaVersion: 1.0
...
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
SharedInstance: true | false
Type
(Compute/Type)
(Necessário se Compute
estiver definido)
O tipo do mecanismo de computação. É possível usar um dos seguintes valores:
-
EC2 (editor visual) ou
EC2
(editor YAML)Otimizado para flexibilidade durante as execuções de ação.
-
Lambda (editor visual) ou
Lambda
(editor YAML)Velocidades otimizadas de inicialização da ação.
Para obter informações sobre tipos de dados, consulte Tipos de computação.
UI correspondente: editor visual/propriedades do fluxo de trabalho/Avançado/Tipo de computação
Fleet
(Compute/Fleet)
(Opcional)
Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: Linux.x86-64.Large
, Linux.x86-64.XLarge
. Para ter mais informações sobre frotas sob demanda, consulte Propriedades da frota sob demanda.
Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte Propriedades da frota provisionada.
Se Fleet
for omitido, o padrão será Linux.x86-64.Large
.
Para ter mais informações sobre frotas de computação, consulte Frotas de computação.
UI correspondente: editor visual/propriedades do fluxo de trabalho/Avançado/Frota de computação
SharedInstance
(Compute/SharedInstance)
(Opcional)
Especifique o recurso de compartilhamento de computação para suas ações. Com o compartilhamento de computação, as ações em um fluxo de trabalho são executadas na mesma instância (imagem do ambiente de runtime). É possível usar um dos seguintes valores:
-
TRUE
significa que a imagem do ambiente de runtime é compartilhada entre as ações do fluxo de trabalho. -
FALSE
significa que uma imagem separada do ambiente de runtime é iniciada e usada para cada ação em um fluxo de trabalho, portanto, você não pode compartilhar recursos como artefatos e variáveis sem configuração adicional.
Para ter mais informações sobre compartilhamento de computação, consulte Compartilhamento de computação entre ações.
Interface de usuário correspondente: nenhuma
Triggers
(Opcional)
Uma sequência de um ou mais gatilhos para esse fluxo de trabalho. Se um gatilho não for especificado, inicie manualmente seu fluxo de trabalho.
Para ter mais informações sobre gatilhos, consulte Início da execução automática de um fluxo de trabalho usando gatilhos.
UI correspondente: editor visual/diagrama de fluxo de trabalho/Gatilhos
Name: MyWorkflow
SchemaVersion: 1.0
...
Triggers:
- Type: PUSH
Branches:
- branch-name
FilesChanged:
- folder1/file
- folder2/
- Type: PULLREQUEST
Events:
- OPEN
- CLOSED
- REVISION
Branches:
- branch-name
FilesChanged:
- file1.txt
- Type: SCHEDULE
# Run the workflow at 10:15 am (UTC+0) every Saturday
Expression: "15 10 ? * 7 *"
Branches:
- branch-name
Type
(Triggers/Type)
(Necessário se Triggers
estiver definido)
Especifique o tipo de gatilho. É possível usar um dos seguintes valores:
-
Envio (editor visual) ou
PUSH
(editor YAML)Um gatilho de envio inicia a execução de um fluxo de trabalho quando uma alteração é enviada para seu repositório de origem. A execução do fluxo de trabalho usará os arquivos na ramificação para a qual você está enviando (ou seja, a ramificação de destino).
-
Solicitação pull (editor visual) ou
PULLREQUEST
(editor YAML)Um gatilho de solicitação pull inicia a execução de um fluxo de trabalho quando uma solicitação pull é aberta, atualizada ou fechada no seu repositório de origem. A execução do fluxo de trabalho usará os arquivos na ramificação da a qual você está extraindo (ou seja, a ramificação de origem).
-
Programação (editor visual) ou
SCHEDULE
(editor YAML)Um gatilho de programação inicia a execução do fluxo de trabalho em uma programação definida por uma expressão cron especificada por você. Uma execução de fluxo de trabalho separada será iniciada para cada ramificação em seu repositório de origem usando os arquivos da ramificação. (Para limitar as ramificações nas quais o gatilho é ativado, use o campo Ramificações (editor visual) ou a propriedade
Branches
(editor YAML).)Ao configurar um gatilho de programação, siga estas instruções:
-
Use apenas um gatilho de programação por fluxo de trabalho.
-
Se você definiu vários fluxos de trabalho em seu espaço do CodeCatalyst, recomendamos que você agende no máximo 10 deles para iniciar simultaneamente.
-
Certifique-se de configurar a expressão cron do gatilho com tempo adequado entre as execuções. Para ter mais informações, consulte Expression.
-
Para ver exemplos, consulte Exemplos: gatilhos em fluxos de trabalho.
UI correspondente: editor visual/diagrama de fluxo de trabalho/Gatilhos/Tipo de gatilho
Events
(Triggers/Events)
(Obrigatório se o gatilho Type
estiver definido como PULLREQUEST
)
Especifique o tipo de eventos de solicitação pull que iniciarão a execução de um fluxo de trabalho. Os valores válidos são os seguintes:
-
A solicitação pull é criada (editor visual) ou
OPEN
(editor YAML)A execução do fluxo de trabalho é iniciada quando uma solicitação pull é criada.
-
A solicitação pull é fechada (editor visual) ou
CLOSED
(editor YAML)A execução do fluxo de trabalho é iniciada quando uma solicitação pull é fechada. O comportamento do evento
CLOSED
é complicado e é melhor compreendido por meio de um exemplo. Consulte Exemplo: um gatilho com uma extração, ramificações e um evento “FECHADO” Para mais informações. -
Uma nova revisão é feita para solicitação pull (editor visual) ou
REVISION
(editor YAML)A execução do fluxo de trabalho é iniciada quando uma revisão da solicitação pull é criada. A primeira revisão é criada quando a solicitação pull é criada. Depois disso, uma nova revisão é criada sempre que alguém envia uma nova confirmação para a ramificação de origem especificada na solicitação pull. Se você incluir o evento
REVISION
em seu gatilho de solicitação pull, poderá omitir o eventoOPEN
, poisREVISION
é um superconjunto deOPEN
.
Você pode especificar vários eventos no mesmo gatilho de solicitação pull.
Para ver exemplos, consulte Exemplos: gatilhos em fluxos de trabalho.
UI correspondente: editor visual/diagrama de fluxo de trabalho/Gatilhos/Eventos para solicitação pull
Branches
(Triggers/Branches)
(Opcional)
Especifique as ramificações em seu repositório de origem que o acionador monitora para saber quando iniciar a execução de um fluxo de trabalho. Você pode usar padrões regex para definir os nomes das ramificações. Por exemplo, use main.*
para combinar todas as ramificações que começam com main
.
As ramificações a serem especificadas são diferentes dependendo do tipo de gatilho:
-
Para um gatilho de envio, especifique as ramificações para as quais você está enviando, ou seja, as ramificações de destino. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando os arquivos na ramificação correspondente.
Exemplos:
main.*
,mainline
-
Para um gatilho de solicitação pull, especifique as ramificações para as quais você está enviando, ou seja, as ramificações de destino. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando o arquivo de definição do fluxo de trabalho e os arquivos de origem na ramificação de origem (não a ramificação correspondente).
Exemplos:
main.*
,mainline
,v1\-.*
(corresponde às ramificações que começam comv1-
) -
Para um gatilho de programação, especifique as ramificações que contêm os arquivos que devem ser usados pela sua execução programada. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando o arquivo de definição do fluxo de trabalho e os arquivos de origem na ramificação correspondente.
Exemplos:
main.*
,version\-1\.0
nota
Se você não especificar ramificações, o gatilho monitorará todas as ramificações em seu repositório de origem e iniciará a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e os arquivos de origem em:
-
A ramificação para a qual você está enviando (para gatilhos de envio). Para ter mais informações, consulte Exemplo: um simples gatilho de envio de código.
-
A ramificação da qual você está extraindo (para gatilhos de solicitação pull). Para ter mais informações, consulte Exemplo: um simples gatilho de solicitação pull.
-
Todas as ramificações (para gatilhos de programação). Uma execução de fluxo de trabalho será iniciada por ramificação em seu repositório de origem. Para ter mais informações, consulte Exemplo: um gatilho de programação simples.
Para ter mais informações sobre ramificações e gatilhos, consulte Diretrizes para o uso de gatilhos e ramificações.
Para obter mais exemplos, consulte Exemplos: gatilhos em fluxos de trabalho.
UI correspondente: editor visual/diagrama de fluxo de trabalho/Gatilhos/Ramificações
FilesChanged
(Triggers/FilesChanged)
(Opcional se o gatilho Type
estiver definido como PUSH
, ou PULLREQUEST
. Não compatível se o gatilho Type
estiver definido como SCHEDULE
.)
Especifique os arquivos ou pastas em seu repositório de origem que o acionador monitora para saber quando iniciar a execução de um fluxo de trabalho. Você pode usar expressões regulares para corresponder nomes ou caminhos de arquivos.
Para ver exemplos, consulte Exemplos: gatilhos em fluxos de trabalho.
UI correspondente: editor visual/diagrama de fluxo de trabalho/Gatilhos/Arquivos alterados
Expression
(Triggers/Expression)
(Obrigatório se o gatilho Type
estiver definido como SCHEDULE
)
Especifique a expressão cron que descreve quando você deseja que suas execuções de fluxo de trabalho programadas ocorram.
As expressões Cron no CodeCatalyst usam a seguinte sintaxe de seis campos, em que cada campo é separado por um espaço:
minutos
horas
dias do mês
mês
dias da semana
ano
Exemplos de expressões cron
Minutos | Horas | Dias do mês | Mês | Dias da semana | Ano | Significado |
---|---|---|---|---|---|---|
0 |
0 |
? |
* |
SEG-SEX |
* |
Executada um fluxo de trabalho à meia-noite (UTC+0) de segunda a sexta. |
0 |
2 |
* |
* |
? |
* |
Executada um fluxo de trabalho às 2h (UTC+0) todos os dias. |
15 |
22 |
* |
* |
? |
* |
Executada um fluxo de trabalho às 22h15 (UTC+0) todos os dias. |
0/30 |
22-2 |
? |
* |
SÁB-DOM |
* |
Executa um fluxo de trabalho a cada 30 minutos de sábado a domingo, entre 22h do dia inicial e 2h do dia seguinte (UTC+0). |
45 |
13 |
L |
* |
? |
2023-2027 |
Executa um fluxo de trabalho às 13h45 (UTC+0) no último dia do mês entre os anos de 2023 e 2027, inclusive. |
Ao especificar expressões cron no CodeCatalyst, siga estas diretrizes:
-
Especifique uma única expressão cron por gatilho
SCHEDULE
. -
Coloque a expressão cron entre aspas duplas (
"
) no editor YAML. -
Especifique o horário em Tempo Universal Coordenado (UTC). Outros fusos horários não são suportados.
-
Configure pelo menos 30 minutos entre as execuções. Não há suporte para uma cadência mais rápida.
-
Especifique o campo
dias do mês
oudias da semana
, mas não ambos. Se você especificar um valor ou asterisco (*
) em um dos campos, deverá usar um ponto de interrogação (?
) no outro. O asterisco significa “tudo” e o ponto de interrogação significa “qualquer”.
Para ver mais exemplos de expressões cron e informações sobre curingas, como ?
, *
e L
, consulte a Referência de expressões cron no Guia do usuário do Amazon EventBridge. As expressões cron no EventBridge e no CodeCatalyst funcionam exatamente da mesma maneira.
Para ver exemplos de gatilhos de programação, consulte Exemplos: gatilhos em fluxos de trabalho.
UI correspondente: editor visual/diagrama de fluxo de trabalho/Gatilhos/Programação
Ações
Uma sequência de uma ou mais ações para esse fluxo de trabalho. O CodeCatalyst é compatível com vários tipos de ação, como ações de compilação e teste, que oferecem diferentes tipos de funcionalidade. Cada tipo de ação tem:
-
uma propriedade
Identifier
que indica o ID exclusivo e de codificação rígida da ação. Por exemplo,aws/build@v1
identifica a ação de criação. -
uma seção
Configuration
que contém propriedades específicas da ação.
Para ter mais informações sobre cada tipo de ação, consulte Tipos de ação. O tópico Tipos de ação tem links para a documentação de cada ação.
Veja a seguir a referência YAML para ações e grupos de ações no arquivo de definição do fluxo de trabalho.
Name: MyWorkflow
SchemaVersion: 1.0
...
Actions:
action-or-gate-name:
Identifier: identifier
Configuration:
...
#Action groups
action-group-name:
Actions:
...
action-or-gate-name
(Actions/action-or-gate-name
)
(Obrigatório)
Substitua action-name
pelo nome que você deseja dar à ação. Os nomes das ações devem ser exclusivos no fluxo de trabalho e incluir apenas caracteres alfanuméricos, hifens e sublinhados. Para ter mais informações sobre as regras de sintaxe, consulte Diretrizes de sintaxe do YAML.
Para ter mais informações sobre práticas de nomenclatura para ações, inclusive restrições, consulte action-or-gate-name.
UI correspondente: editor visual/action-name
/guia Configuração/Nome da ação ou Nome de exibição da ação
action-group-name
(Actions/action-group-name
)
(Opcional)
Um grupo de ações contém uma ou mais ações. O agrupamento de ações em grupos ajuda a manter o fluxo de trabalho organizado e também permite configurar dependências entre grupos diferentes.
Substitua action-group-name
pelo nome que você deseja dar ao grupo de ações. Os nomes de grupos das ações devem ser exclusivos no fluxo de trabalho e incluir apenas caracteres alfanuméricos, hifens e sublinhados. Para ter mais informações sobre as regras de sintaxe, consulte Diretrizes de sintaxe do YAML.
Para ter mais informações sobre os grupos de ações, consulte Agrupar ações em grupos de ações.
Interface de usuário correspondente: nenhuma