Exemplo de um arquivo de definição de fluxo de trabalho Diretrizes e convenções de sintaxe Propriedades de nível superior

YAMLDefinição de fluxo de trabalho

A seguir está a documentação de referência para o arquivo de definição do fluxo de trabalho.

Um arquivo de definição de fluxo de trabalho é um YAML arquivo que descreve seu fluxo de trabalho. Por padrão, o arquivo é armazenado em uma ~/.codecatalyst/workflows/ pasta na raiz do seu 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 do fluxo de trabalho, você pode usar um editor como o vim ou usar o editor visual ou YAML editor do CodeCatalyst console. Para obter mais informações, consulte Usando o visual e os YAML editores do CodeCatalyst console.

nota

A maioria das YAML propriedades a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface do usuário, use Ctrl+F. O elemento será listado com sua YAML propriedade associada.

Tópicos

Exemplo de um arquivo de definição de fluxo de trabalho
Diretrizes e convenções de sintaxe
Propriedades de nível superior

Exemplo de um arquivo de definição de fluxo de trabalho

Veja a seguir um exemplo de um arquivo simples de definição de fluxo de trabalho. Inclui algumas propriedades de nível superior, uma Triggers seção e uma Actions seção com duas ações: Build e. Test Para obter 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.

YAMLdiretrizes de sintaxe

O arquivo de definição do fluxo de trabalho é gravado YAML e segue a especificação YAML 1.1, portanto, tudo o que é permitido nessa especificação também é permitido no fluxo de trabalhoYAML. Se você é novatoYAML, aqui estão algumas diretrizes rápidas para garantir que você esteja fornecendo um YAML código válido.

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: { } [],,,*,#,,?,|,-,,,,,,=,!,%,,@,:, ` ,

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, A-Z, 0-9), hífens (-) 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: Prefácio os comentários com#.

Exemplo:


Name: MyWorkflow
# This is a comment.
SchemaVersion: 1.0

Triple dash (---): Não use --- em seu YAML código. 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, TriggersType, e. Branches
Uma seção é qualquer propriedade que tenha subpropriedades. No trecho de código a seguir, há uma Triggers seção.

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

A seguir está a documentação de referência para as propriedades de nível superior no 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 registros. O nome do fluxo de trabalho e o nome do arquivo de definição do fluxo de trabalho podem coincidir, ou você pode nomeá-los de forma diferente. Os nomes dos fluxos de trabalho não precisam ser exclusivos. Os nomes dos fluxos de trabalho são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hífens (-) e sublinhados (_). Não são permitidos espaços. Você não pode usar aspas para ativar caracteres especiais e espaços nos nomes dos fluxos 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.

UI correspondente: nenhuma

RunMode

(Optional)

Como CodeCatalyst lida com várias execuções. Você pode usar um dos seguintes valores:

QUEUED— Várias execuções são colocadas em fila e executadas uma após a outra. Você pode 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á (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 obter mais informações, consulte Configurando o comportamento de enfileiramento das execuções.

UI correspondente: modo editor/Workflow properties/Advanced visual/de execução

Compute

(Optional)

O mecanismo de computação usado para executar suas ações de fluxo de trabalho. Você pode especificar a computação no nível do fluxo de trabalho ou no nível da ação, mas não em ambos. Quando especificada no nível do fluxo de trabalho, a configuração computacional se aplica a todas as ações definidas no fluxo de trabalho. No nível do fluxo de trabalho, você também pode executar várias ações na mesma instância. Para obter mais informações, consulte Compartilhamento de computação entre ações.

Para obter mais informações sobre computação, consulteConfigurando imagens de computação e tempo de execução.

UI correspondente: nenhuma


Name: MyWorkflow
SchemaVersion: 1.0
...
Compute:  
  Type: EC2 | Lambda
  Fleet: fleet-name
  SharedInstance: true | false

Type

(Compute/Type)

(Obrigatório se Compute estiver configurado)

O tipo de mecanismo de computação. Você pode usar um dos seguintes valores:

EC2(editor visual) ou EC2 (YAMLeditor)

Otimizado para flexibilidade durante as corridas de ação.
Lambda (editor visual) ou Lambda (YAMLeditor)

Velocidades otimizadas de inicialização da ação.

Para obter informações sobre tipos de dados, consulte Tipos de computação.

UI correspondente: visualeditor/Workflow properties/Advanced/tipo de computação

Fleet

(Compute/Fleet)

(Optional)

Especifique a máquina ou frota que executará seu fluxo de trabalho ou 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 frotas sob demanda:Linux.x86-64.Large,. Linux.x86-64.XLarge Para obter mais informações sobre frotas sob demanda, consulte. Propriedades de frota sob demanda

Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para executar suas ações de fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para obter mais informações sobre frotas provisionadas, consulte. Propriedades da frota provisionada

Se Fleet for omitido, o padrão será. Linux.x86-64.Large

Para obter mais informações sobre frotas de computação, consulte. Frotas de computação

UI correspondente: frota editor/Workflow properties/Advanced visual/computacional

SharedInstance

(Compute/SharedInstance)

(Optional)

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 tempo de execução). Você pode usar um dos seguintes valores:

TRUEsignifica que a imagem do ambiente de tempo de execução é compartilhada entre as ações do fluxo de trabalho.
FALSEsignifica que uma imagem separada do ambiente de tempo de execução é 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 obter mais informações sobre compartilhamento de computação, consulteCompartilhamento de computação entre ações.

UI correspondente: nenhuma

Triggers

(Optional)

Uma sequência de um ou mais gatilhos para esse fluxo de trabalho. Se um gatilho não for especificado, você deverá iniciar manualmente seu fluxo de trabalho.

Para obter mais informações sobre gatilhos, consulte Iniciando um fluxo de trabalho executado automaticamente usando gatilhos.

UI correspondente: editor visual/diagrama de fluxo de trabalho/acionadores


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)

(Obrigatório se Triggers estiver configurado)

Especifique o tipo de gatilho. Você pode usar um dos seguintes valores:

Push (editor visual) ou PUSH (YAMLeditor)

Um gatilho push 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).
Pull request (editor visual) ou PULLREQUEST (YAMLeditor)

Um gatilho de pull request inicia a execução de um fluxo de trabalho quando uma pull request é aberta, atualizada ou fechada em seu repositório de origem. A execução do fluxo de trabalho usará os arquivos na ramificação da qual você está extraindo (ou seja, a ramificação de origem).
Agenda (editor visual) ou SCHEDULE (YAMLeditor)

Um gatilho de agendamento inicia a execução do fluxo de trabalho em um cronograma definido 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 Branches propriedade (YAMLeditor).)

Ao configurar um gatilho de agendamento, siga estas diretrizes:
- Use apenas um gatilho de agendamento por fluxo de trabalho.
- Se você definiu vários fluxos de trabalho em seu CodeCatalyst espaço, recomendamos que você agende no máximo 10 deles para começarem simultaneamente.
- Certifique-se de configurar a expressão cron do gatilho com tempo adequado entre as execuções. Para obter mais informações, consulte Expression.

Para ver exemplos, consulte Exemplos: acionadores em fluxos de trabalho.

UI correspondente: visualeditor/workflow diagram/Triggers/tipo de gatilho

Events

(Triggers/Events)

(Obrigatório se o gatilho Type estiver definido comoPULLREQUEST)

Especifique o tipo de eventos de pull request que iniciarão a execução de um fluxo de trabalho. A seguir estão os valores válidos:

A solicitação pull é criada (editor visual) ou OPEN (YAMLeditor)

A execução do fluxo de trabalho é iniciada quando uma pull request é criada.
A solicitação pull está fechada (editor visual) ou CLOSED (YAMLeditor)

A execução do fluxo de trabalho é iniciada quando uma pull request é fechada. O comportamento do CLOSED evento é complicado e é melhor compreendido por meio de um exemplo. Consulte Exemplo: um gatilho com um puxão, galhos e um evento CLOSED '' Para mais informações.
Uma nova revisão é feita para pull request (editor visual) ou REVISION (YAMLeditor)

A execução do fluxo de trabalho é iniciada quando uma revisão de uma pull request é criada. A primeira revisão é criada quando a pull request é criada. Depois disso, uma nova revisão é criada toda vez que alguém envia um novo commit para a ramificação de origem especificada na pull request. Se você incluir o REVISION evento em seu gatilho de pull request, poderá omitir o OPEN evento, pois REVISION é um superconjunto de. OPEN

Você pode especificar vários eventos no mesmo gatilho de pull request.

Para ver exemplos, consulte Exemplos: acionadores em fluxos de trabalho.

UI correspondente: visualeditor/workflow diagram/Triggers/Eventos para pull request

Branches

(Triggers/Branches)

(Optional)

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 commain.

As ramificações a serem especificadas são diferentes dependendo do tipo de acionador:

Para um gatilho de pressão, 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 pull request, 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 agendamento, especifique as ramificações que contêm os arquivos que você deseja que sua execução programada use. 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:

O galho para o qual você está empurrando (para gatilhos de pressão). Para obter mais informações, consulte Exemplo: um simples gatilho de envio de código.
A ramificação da qual você está retirando (para acionadores de pull request). Para obter mais informações, consulte Exemplo: um simples gatilho de pull request.
Todas as filiais (para acionadores de agendamento). Uma execução de fluxo de trabalho será iniciada por ramificação em seu repositório de origem. Para obter mais informações, consulte Exemplo: um simples gatilho de agendamento.

Para obter mais informações sobre ramificações e gatilhos, consulte. Diretrizes de uso para gatilhos e ramificações

Para obter mais exemplos, consulte Exemplos: acionadores em fluxos de trabalho.

UI correspondente: visualeditor/workflow diagram/Triggers/Branches

FilesChanged

(Triggers/FilesChanged)

(Opcional se o gatilho Type estiver definido comoPUSH, ouPULLREQUEST. Não é suportado se o gatilho Type estiver definido comoSCHEDULE.)

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 combinar nomes ou caminhos de arquivos.

Para ver exemplos, consulte Exemplos: acionadores em fluxos de trabalho.

UI correspondente: visualeditor/workflow diagram/Triggers/Arquivos alterados

Expression

(Triggers/Expression)

(Obrigatório se o gatilho Type estiver definido comoSCHEDULE)

Especifique a expressão cron que descreve quando você deseja que suas execuções de fluxo de trabalho agendadas ocorram.

As expressões Cron CodeCatalyst usam a seguinte sintaxe de seis campos, em que cada campo é separado por um espaço:

minutes hours days-of-month month days-of-week year

Exemplos de expressões cron

Minutos	Horas	Dias do mês	Mês	Dias da semana	Ano	Significado
0	0	?	*	MON-FRI	*	Executa um fluxo de trabalho à meia-noite (UTC+0) de segunda a sexta-feira.
0	2	*	*	?	*	Executa um fluxo de trabalho às 2:00 da manhã (UTC+0) todos os dias.
15	22	*	*	?	*	Executa um fluxo de trabalho às 22h15 (UTC+0) todos os dias.
0/30	22-2	?	*	SAT-SUN	*	Executa um fluxo de trabalho a cada 30 minutos, de sábado a domingo, entre 22h no dia inicial e 2h no 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 em CodeCatalyst, siga estas diretrizes:

Especifique uma única expressão cron por SCHEDULE gatilho.
Coloque a expressão cron entre aspas duplas (") no editor. YAML
Especifique a hora 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 days-of-month ou days-of-week campo, mas não ambos. Se você especificar um valor ou um 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 obter 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 da Amazon EventBridge . As expressões Cron CodeCatalyst funcionam exatamente da mesma maneira. EventBridge

Para obter exemplos de acionadores de agendamento, consulte. Exemplos: acionadores em fluxos de trabalho

UI correspondente: visualeditor/workflow diagram/Triggers/Schedule

Ações

Uma sequência de uma ou mais ações para esse fluxo de trabalho. CodeCatalyst suporta vários tipos de ação, como ações de criação e teste, que oferecem diferentes tipos de funcionalidade. Cada tipo de ação tem:

uma Identifier propriedade que indica o ID exclusivo e codificado da ação. Por exemplo, aws/build@v1 identifica a ação de criação.
uma Configuration seção que contém propriedades específicas da ação.

Para obter mais informações sobre cada tipo de ação, consulteTipos de ação. O Tipos de ação tópico tem links para a documentação de cada ação.

A seguir está a YAML referência 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)

Substituir action-name com um nome que você deseja dar à ação. Os nomes das ações devem ser exclusivos no fluxo de trabalho e devem incluir somente caracteres alfanuméricos, hífens e sublinhados. Para obter mais informações sobre regras de sintaxe, consulteYAMLdiretrizes de sintaxe.

Para obter mais informações sobre práticas de nomenclatura para ações, incluindo restrições, consulte o. action-or-gate-name

UI correspondente: editor visual/action-name/Guia de configuração/ Nome da ação ou Nome de exibição da ação

action-group-name

(Actions/action-group-name)

(Optional)

Um grupo de ações contém uma ou mais ações. O agrupamento de ações em grupos de ações ajuda a manter seu fluxo de trabalho organizado e também permite configurar dependências entre grupos diferentes.

Substituir action-group-name com um nome que você deseja dar ao grupo de ação. Os nomes dos grupos de ação devem ser exclusivos no fluxo de trabalho e devem incluir somente caracteres alfanuméricos, hífens e sublinhados. Para obter mais informações sobre regras de sintaxe, consulteYAMLdiretrizes de sintaxe.

Para obter mais informações sobre grupos de ação, consulteAgrupando ações em grupos de ação.

UI correspondente: nenhuma

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Estados do fluxo de trabalho

Acompanhe e organize o trabalho com problemas