YAMLDefinición del flujo de trabajo - Amazon CodeCatalyst
Ejemplo de un archivo de definición de flujo de trabajoPautas y convenciones de sintaxisPropiedades de nivel superior

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

YAMLDefinición del flujo de trabajo

La siguiente es la documentación de referencia para el archivo de definición del flujo de trabajo.

Un archivo de definición de flujo de trabajo es un YAML archivo que describe su flujo de trabajo. De forma predeterminada, el archivo se almacena en una ~/.codecatalyst/workflows/ carpeta en la raíz del repositorio de origen. El archivo puede tener la extensión.yml o .yaml, y la extensión debe estar en minúsculas.

Para crear y editar el archivo de definición del flujo de trabajo, puede utilizar un editor como vim o el editor visual de la CodeCatalyst consola. YAML Para obtener más información, consulte Uso de los elementos visuales y de los YAML editores de la CodeCatalyst consola.

nota

La mayoría de las YAML propiedades siguientes tienen los elementos de interfaz de usuario correspondientes en el editor visual. Para buscar un elemento de la interfaz de usuario, utilice Ctrl+F. El elemento aparecerá en la lista con su propiedad asociadaYAML.

Ejemplo de un archivo de definición de flujo de trabajo

El siguiente es un ejemplo de un archivo de definición de flujo de trabajo sencillo. Incluye algunas propiedades de nivel superior, una Triggers sección y una Actions sección con dos acciones: Build yTest. Para obtener más información, consulte Acerca del archivo de definición del flujo de trabajo.

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

Pautas y convenciones de sintaxis

En esta sección se describen las reglas de sintaxis del archivo de definición del flujo de trabajo, así como las convenciones de nomenclatura utilizadas en esta documentación de referencia.

YAMLdirectrices de sintaxis

El archivo de definición del flujo de trabajo está escrito YAML y sigue la especificación YAML 1.1, por lo que todo lo que esté permitido en esa especificación también estará permitido en el flujo de trabajoYAML. Si es la primera vez que lo YAML usas, aquí tienes algunas pautas rápidas para asegurarte de que estás proporcionando un YAML código válido.

  • Distinción entre mayúsculas y minúsculas: el archivo de definición del flujo de trabajo distingue entre mayúsculas y minúsculas, así que asegúrese de utilizar las mayúsculas y minúsculas que se muestran en esta documentación.

  • Caracteres especiales: se recomienda usar comillas o comillas dobles en los valores de las propiedades que incluyan alguno de los siguientes caracteres especiales: { } [],,,*, &#,?,|,-, <, >,,=, !%, @ y : ` ,

    Si no incluye las comillas, es posible que los caracteres especiales enumerados anteriormente se interpreten de forma inesperada.

  • Nombres de propiedades: los nombres de las propiedades (a diferencia de los valores de las propiedades) están limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), guiones (-) y guiones bajos (_). No se permiten espacios. No puede utilizar comillas ni comillas dobles para activar los caracteres especiales y los espacios en los nombres de las propiedades.

    No está permitido:

    'My#Build@action'

    My#Build@action

    My Build Action

    Permitido:

    My-Build-Action_1

  • Códigos de escape: si el valor de su propiedad incluye códigos de escape (por ejemplo, \n o\t), siga estas pautas:

    • Usa comillas simples para devolver el código de escape en forma de cadena. Por ejemplo'my string \n my string', devuelve la cadenamy string \n my string.

    • Use comillas dobles para analizar el código de escape. Por ejemplo"my string \n my new line", devuelve:

      my string
my new line

  • Comentarios: los comentarios del prefacio incluyen. #

    Ejemplo:

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

  • Triple dash (---): No lo use --- en su YAML código. CodeCatalyst ignora todo lo que sigue después de---.

Convenciones de nomenclatura

En esta guía, utilizamos los términos propiedad y sección para referirnos a los elementos principales de un archivo de definición de flujo de trabajo.

  • Una propiedad es cualquier elemento que incluye dos puntos (:). Por ejemplo, en el siguiente fragmento de código, todas las propiedades siguientes son:Name,SchemaVersion, RunMode TriggersType, y. Branches

  • Una sección es cualquier propiedad que tiene subpropiedades. En el siguiente fragmento de código, hay una sección. Triggers

    nota

    En esta guía, las «secciones» a veces se denominan «propiedades» y viceversa, según el contexto.

    Name: MyWorkflow
SchemaVersion: 1.0
RunMode: QUEUED
Triggers:
  - Type: PUSH
    Branches:
      - main

Propiedades de nivel superior

La siguiente es la documentación de referencia para las propiedades de nivel superior del archivo de definición del flujo de trabajo.

# Name
Name: workflow-name
        
# Schema version
SchemaVersion: 1.0
        
# Run mode
RunMode: QUEUED|SUPERSEDED|PARALLEL

# Compute
Compute:  
...
            
# Triggers
Triggers:
...

# Actions
Actions:
...

Name

(Obligatorio)

Nombre del flujo de trabajo. El nombre del flujo de trabajo se muestra en la lista de flujos de trabajo y se menciona en las notificaciones y los registros. El nombre del flujo de trabajo y el nombre del archivo de definición del flujo de trabajo pueden coincidir, o puede asignarles un nombre diferente. Los nombres de los flujos de trabajo no tienen por qué ser únicos. Los nombres de los flujos de trabajo se limitan a caracteres alfanuméricos (a-z, A-Z, 0-9), guiones (-) y guiones bajos (_). No se permiten espacios. No puede usar comillas para habilitar los caracteres especiales y los espacios en los nombres de los flujos de trabajo.

Interfaz de usuario correspondiente: editor visual/propiedades del flujo de trabajo/nombre del flujo de trabajo

SchemaVersion

(Obligatorio)

La versión esquemática de la definición del flujo de trabajo. El único valor válido actualmente es 1.0.

Interfaz de usuario correspondiente: ninguna

RunMode

(Opcional)

Cómo CodeCatalyst gestiona las ejecuciones múltiples. Puede utilizar uno de los siguientes valores:

  • QUEUED— Se ponen en cola varias ejecuciones y se ejecutan una tras otra. Puedes tener hasta 50 carreras en una cola.

  • SUPERSEDED— Se ponen varias carreras en cola y se ejecutan una tras otra. Una cola solo puede tener una ejecución, por lo que si dos corridas terminan juntas en la misma cola, la última reemplaza (reemplaza) a la anterior y esta última se cancela.

  • PARALLEL— Se producen varias corridas simultáneamente.

Si se omite esta propiedad, el valor por defecto esQUEUED.

Para obtener más información, consulte Configuración del comportamiento de puesta en cola de las corridas.

Interfaz de usuario correspondiente: modo editor/Workflow properties/Advanced visual/modo de ejecución

Compute

(Opcional)

El motor informático utilizado para ejecutar las acciones del flujo de trabajo. Puede especificar el procesamiento en el nivel del flujo de trabajo o en el nivel de acción, pero no en ambos. Cuando se especifica en el nivel del flujo de trabajo, la configuración de procesamiento se aplica a todas las acciones definidas en el flujo de trabajo. En el nivel del flujo de trabajo, también puedes ejecutar varias acciones en la misma instancia. Para obtener más información, consulte Compartir el cómputo entre acciones.

Para obtener más información sobre el procesamiento, consulteConfiguración de imágenes de procesamiento y tiempo de ejecución.

Interfaz de usuario correspondiente: ninguna

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

Type

(Compute/Type)

(Obligatorio si Compute está configurado)

El tipo de motor de cómputo. Puede usar uno de los siguientes valores:

  • EC2(editor visual) o EC2 (YAMLeditor)

    Optimizado para ofrecer flexibilidad durante las ejecuciones de acción.

  • Lambda (editor visual) o Lambda (YAMLeditor)

    Velocidades de inicio de acciones optimizadas.

Para obtener más información sobre los tipos de computación, consulte Tipos de procesamiento.

Interfaz de usuario correspondiente: tipo editor/Workflow properties/Advanced visual/informático

Fleet

(Compute/Fleet)

(Opcional)

Especifique la máquina o flota que ejecutará el flujo de trabajo o las acciones del flujo de trabajo. Con las flotas bajo demanda, cuando se inicia una acción, el flujo de trabajo aprovisiona los recursos que necesita y las máquinas se destruyen cuando finaliza la acción. Ejemplos de flotas bajo demanda:Linux.x86-64.Large,. Linux.x86-64.XLarge Para obtener más información sobre las flotas bajo demanda, consulte. Propiedades de la flota bajo demanda

Con las flotas aprovisionadas, puede configurar un conjunto de máquinas dedicadas para ejecutar las acciones de su flujo de trabajo. Estas máquinas permanecen inactivas y listas para procesar las acciones de forma inmediata. Para obtener más información sobre las flotas aprovisionadas, consulte. Propiedades de la flota aprovisionada

Si Fleet se omite, el valor predeterminado es. Linux.x86-64.Large

Para obtener más información sobre las flotas informáticas, consulte. Flotas de computación

Interfaz de usuario correspondiente: flota visual o de editor/Workflow properties/Advanced cómputo

SharedInstance

(Compute/SharedInstance)

(Opcional)

Especifique la capacidad de compartir el cómputo para sus acciones. Con el uso compartido de recursos informáticos, las acciones de un flujo de trabajo se ejecutan en la misma instancia (imagen del entorno de ejecución). Puedes usar uno de los siguientes valores:

  • TRUEsignifica que la imagen del entorno de ejecución se comparte entre las acciones del flujo de trabajo.

  • FALSEsignifica que se inicia una imagen del entorno de ejecución independiente y se utiliza para cada acción de un flujo de trabajo, por lo que no se pueden compartir recursos como artefactos y variables sin una configuración adicional.

Para obtener más información sobre el uso compartido de la computación, consulteCompartir el cómputo entre acciones.

Interfaz de usuario correspondiente: ninguna

Triggers

(Opcional)

Secuencia de uno o más activadores de este flujo de trabajo. Si no se especifica ningún desencadenante, debe iniciar el flujo de trabajo manualmente.

Para obtener más información acerca de los disparadores, consulte Iniciar un flujo de trabajo, ejecutarlo automáticamente mediante activadores.

Interfaz de usuario correspondiente: editor visual/diagrama de flujo de trabajo/activadores

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)

(Obligatorio si está configurado) Triggers

Especifique el tipo de disparador. Puede utilizar uno de los siguientes valores:

  • Push (editor visual) o PUSH (YAMLeditor)

    Un pulsador inicia la ejecución de un flujo de trabajo cuando se envía un cambio a tu repositorio de origen. La ejecución del flujo de trabajo utilizará los archivos de la rama a la que vayas a realizar el envío (es decir, la rama de destino).

  • Pull request (editor visual) o PULLREQUEST (YAMLeditor)

    Un activador de solicitudes de extracción inicia la ejecución de un flujo de trabajo cuando se abre, actualiza o cierra una solicitud de extracción en tu repositorio de origen. La ejecución del flujo de trabajo utilizará los archivos de la rama de la que estás extrayendo (es decir, la rama de origen).

  • Programación (editor visual) o SCHEDULE (YAMLeditor)

    Un activador de programación inicia las ejecuciones del flujo de trabajo según una programación definida por una expresión cron que usted especifique. Se iniciará una ejecución de flujo de trabajo independiente para cada rama del repositorio de origen utilizando los archivos de la rama. (Para limitar las ramas en las que se activa el activador, usa el campo Ramas (editor visual) o la Branches propiedad (YAMLeditor).)

    Al configurar un activador programado, siga estas pautas:

    • Utilice solo un activador de programación por flujo de trabajo.

    • Si ha definido varios flujos de trabajo en su CodeCatalyst espacio, le recomendamos que no programe más de 10 de ellos para que se inicien simultáneamente.

    • Asegúrese de configurar la expresión cron del disparador con el tiempo adecuado entre ejecuciones. Para obtener más información, consulte Expression.

Para ver ejemplos, consulte Ejemplos: desencadenantes en los flujos de trabajo.

Interfaz de usuario correspondiente: editor/workflow diagram/Triggers visual/Tipo de disparador

Events

(Triggers/Events)

(Obligatorio si el disparador Type está configurado enPULLREQUEST)

Especifica el tipo de eventos de solicitud de cambios que iniciarán la ejecución de un flujo de trabajo. Los valores válidos son los siguientes:

  • Se crea una solicitud de extracción (editor visual) o OPEN (YAMLeditor)

    La ejecución del flujo de trabajo se inicia cuando se crea una solicitud de extracción.

  • La solicitud de extracción está cerrada (editor visual) o CLOSED (YAMLeditor)

    La ejecución del flujo de trabajo se inicia cuando se cierra una solicitud de extracción. El comportamiento del CLOSED evento es complicado y se entiende mejor con un ejemplo. Para obtener más información, consulte Ejemplo: un gatillo al que se tira, se ramifica y se produce un evento CLOSED «».

  • Se realiza una nueva revisión a través de pull request (editor visual) o REVISION (YAMLeditor)

    La ejecución del flujo de trabajo se inicia cuando se crea una revisión de una solicitud de extracción. La primera revisión se crea cuando se crea la solicitud de extracción. Después de eso, se crea una nueva revisión cada vez que alguien envía una nueva confirmación a la rama de origen especificada en la solicitud de extracción. Si incluyes el REVISION evento en el activador de la solicitud de cambios, puedes omitirlo, ya que REVISION es un superconjunto de. OPEN OPEN

Puedes especificar varios eventos en el mismo activador de la solicitud de atracción.

Para ver ejemplos, consulte Ejemplos: desencadenantes en los flujos de trabajo.

Interfaz de usuario correspondiente: visual editor/workflow diagram/Triggers o eventos para la solicitud de extracción

Branches

(Triggers/Branches)

(Opcional)

Especifica las ramas del repositorio de origen que monitorea el activador para saber cuándo iniciar la ejecución de un flujo de trabajo. Puedes usar patrones de expresiones regulares para definir los nombres de tus ramas. Por ejemplo, úsalo main.* para hacer coincidir todas las ramas que comiencen por. main

Las ramas que se deben especificar son diferentes en función del tipo de disparador:

  • En el caso de un disparador automático, especifique las ramas a las que va a enviar el mensaje, es decir, las sucursales de destino. Se iniciará una ejecución de flujo de trabajo por cada sucursal coincidente, utilizando los archivos de la sucursal coincidente.

    Ejemplos: main.*, mainline

  • Para activar una solicitud de cambios, especifica las sucursales a las que vas a enviar mensajes, es decir, las sucursales de destino. Se iniciará una ejecución de flujo de trabajo por cada rama coincidente, utilizando el archivo de definición del flujo de trabajo y los archivos fuente de la rama de origen (no de la rama coincidente).

    Ejemplos:main.*,mainline, v1\-.* (coincide con las ramas que comienzan conv1-)

  • Para activar una programación, especifique las ramas que contienen los archivos que desea que utilice la ejecución programada. Se iniciará una ejecución de flujo de trabajo por cada rama coincidente, utilizando el archivo de definición del flujo de trabajo y los archivos fuente de la rama coincidente.

    Ejemplos: main.*, version\-1\.0

nota

Si no especificas las ramas, el activador monitoriza todas las ramas del repositorio de origen e iniciará una ejecución de flujo de trabajo con el archivo de definición del flujo de trabajo y los archivos fuente de:

Para obtener más información sobre las ramas y los activadores, consultePautas de uso para activadores y ramificaciones.

Para obtener más ejemplos, consulte Ejemplos: desencadenantes en los flujos de trabajo.

Interfaz de usuario correspondiente: editor/workflow diagram/Triggers visual/Branches

FilesChanged

(Triggers/FilesChanged)

(Opcional si el disparador Type está configurado enPUSH, oPULLREQUEST. No se admite si el disparador Type está configurado enSCHEDULE.

Especifique los archivos o carpetas del repositorio de origen que supervisa el desencadenador para saber cuándo iniciar la ejecución de un flujo de trabajo. Puede utilizar expresiones regulares para hacer coincidir los nombres o las rutas de los archivos.

Para ver ejemplos, consulte Ejemplos: desencadenantes en los flujos de trabajo.

Interfaz de usuario correspondiente: visualeditor/workflow diagram/Triggers//Archivos cambiados

Expression

(Triggers/Expression)

(Obligatorio si el disparador Type está configurado enSCHEDULE)

Especifique la expresión cron que describe cuándo desea que se ejecute el flujo de trabajo programado.

Las expresiones cron utilizadas CodeCatalyst utilizan la siguiente sintaxis de seis campos, en la que cada campo está separado por un espacio:

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

Ejemplos de expresiones cron

Minutos Horas Días del mes Mes Días de la semana Año Significado

0

0

?

*

MON-FRI

*

Ejecuta un flujo de trabajo a medianoche (UTC+0) de lunes a viernes.

0

2

*

*

?

*

Ejecuta un flujo de trabajo a las 2:00 a.m. (UTC+0) todos los días.

15

22

*

*

?

*

Ejecuta un flujo de trabajo a las 22:15 (UTC+0) todos los días.

0/30

22-2

?

*

SAT-SUN

*

Ejecuta un flujo de trabajo cada 30 minutos de sábado a domingo, entre las 22:00 del día de inicio y las 2:00 del día siguiente (UTC+0).

45

13

L

*

?

2023-2027

Ejecuta un flujo de trabajo a las 13:45 (UTC+0) del último día del mes entre los años 2023 y 2027, ambos inclusive.

Al especificar las expresiones cron CodeCatalyst, asegúrate de seguir estas pautas:

  • Especifique una sola expresión cron por SCHEDULE activador.

  • Escriba la expresión cron entre comillas dobles (") en el editor. YAML

  • Especifique la hora en Hora universal coordinada (). UTC No se admiten otras zonas horarias.

  • Configure al menos 30 minutos entre ejecuciones. No se admite una cadencia más rápida.

  • Especifique el days-of-month o days-of-week campo, pero no ambos. Si especifica un valor o un asterisco (*) en uno de los campos, debe utilizar un signo de interrogación (?) en el otro. El asterisco significa «todos» y el signo de interrogación significa «cualquiera».

Para obtener más ejemplos de expresiones cron e información sobre caracteres comodín?, como, y *L, consulte la referencia sobre expresiones cron en la Guía del usuario de Amazon EventBridge . Las expresiones cron CodeCatalyst funcionan EventBridge y funcionan exactamente de la misma manera.

Para ver ejemplos de activadores de horarios, consulteEjemplos: desencadenantes en los flujos de trabajo.

Interfaz de usuario correspondiente: editor/workflow diagram/Triggers visual/Calendario

Acciones

Secuencia de una o más acciones para este flujo de trabajo. CodeCatalyst admite varios tipos de acciones, como las de creación y prueba, que ofrecen distintos tipos de funciones. Cada tipo de acción tiene:

  • una Identifier propiedad que indica el identificador único y codificado de la acción. Por ejemplo, aws/build@v1 identifica la acción de creación.

  • una Configuration sección que contiene propiedades específicas de la acción.

Para obtener más información sobre cada tipo de acción, consulteTipos de acción. El Tipos de acción tema tiene enlaces a la documentación de cada acción.

La siguiente es la YAML referencia para las acciones y los grupos de acciones del archivo de definición del flujo de trabajo.

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)

(Obligatorio)

Reemplazar action-name con el nombre que desee asignar a la acción. Los nombres de las acciones deben ser únicos en el flujo de trabajo y solo deben incluir caracteres alfanuméricos, guiones y guiones bajos. Para obtener más información sobre las reglas de sintaxis, consulte. YAMLdirectrices de sintaxis

Para obtener más información sobre las prácticas de nomenclatura de las acciones, incluidas las restricciones, consulte laaction-or-gate-name.

Interfaz de usuario correspondiente: editor visual/action-name/Pestaña de configuración/ Nombre de la acción o nombre de visualización de la acción

action-group-name

(Actions/action-group-name)

(Opcional)

Un grupo de acciones contiene una o más acciones. Agrupar las acciones en grupos de acciones le ayuda a mantener el flujo de trabajo organizado y también le permite configurar las dependencias entre los distintos grupos.

Reemplazar action-group-name con el nombre que desee asignar al grupo de acciones. Los nombres de los grupos de acciones deben ser únicos en el flujo de trabajo y solo deben incluir caracteres alfanuméricos, guiones y guiones bajos. Para obtener más información sobre las reglas de sintaxis, consulte. YAMLdirectrices de sintaxis

Para obtener más información sobre los grupos de acciones, consulteAgrupación de acciones en grupos de acciones.

Interfaz de usuario correspondiente: ninguna