Amazon ya no CodeCatalyst está abierto a nuevos clientes. Los clientes existentes pueden seguir utilizando el servicio con normalidad. Para obtener más información, consulte [Cómo migrar desde CodeCatalyst](migration.md). 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. # Definición de flujo de trabajo en YAML Esta es la documentación de referencia para el archivo de definición de flujo de trabajo. Un *archivo de definición de flujo de trabajo* es un archivo YAML que describe su flujo de trabajo. De forma predeterminada, el archivo se almacena en una carpeta `~/.codecatalyst/workflows/` en el directorio raíz del [repositorio de código fuente](source-repositories.md). 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, puedes usar un editor como vim, o puedes usar el editor visual o el editor CodeCatalyst YAML de la consola. Para obtener más información, consulte [Uso de los CodeCatalyst editores visuales y YAML de la consola](workflow.md#workflow.editors). **nota** La mayoría de las propiedades de YAML que se muestran a continuación tienen elementos de interfaz de usuario correspondientes en el editor visual. Para buscar un elemento de la interfaz de usuario, use **Ctrl\$1F**. El elemento aparecerá en la lista con su propiedad de YAML asociada. **Topics** + [Ejemplo de un archivo de definición de flujo de trabajo](#workflow.anatomy) + [Pautas y convenciones de sintaxis](#workflow.terms.syntax.conv) + [Propiedades de nivel superior](#workflow.top.level) ## Ejemplo de un archivo de definición de flujo de trabajo A continuación, se muestra un ejemplo de archivo de definición de flujo de trabajo simple. Incluye algunas propiedades de nivel superior, una sección `Triggers` y una sección `Actions` con dos acciones: `Build` y `Test`. Para obtener más información, consulte [Acerca del archivo de definición del flujo de trabajo](workflow.md#workflow.example). ``` 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 que se utilizan en esta documentación de referencia. ### Directrices de sintaxis de YAML El archivo de definición de flujo de trabajo está escrito en YAML y sigue la [especificación YAML 1.1](https://yaml.org/spec/), por lo que todo lo que esté permitido según esa especificación también lo estará en el YAML del flujo de trabajo. Si es principiante en el uso de YAML, aquí tiene algunas pautas rápidas para asegurarse de estar generando un código de YAML válido. + **Distingue entre mayúsculas y minúsculas**: el archivo de definición de flujo de trabajo distingue entre mayúsculas y minúsculas, así que asegúrese de utilizar las expresiones según constan en esta documentación. + **Caracteres especiales**: le recomendamos que utilice comillas simples o dobles en torno a los valores de las propiedades que incluyan alguno de estos caracteres especiales: `{`, `}` , `[` , `]` , &, `*` , `#` , `?` , `|` , `-` , < , >, `=` , `!` , `%` , `@` , `:` , ``` y `,`. Si no incluye las comillas, es posible que los caracteres especiales enumerados 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 (\$1). No se permiten espacios. No puede utilizar comillas ni comillas dobles para habilitar los caracteres especiales y los espacios en los nombres de las propiedades. No 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: + Use comillas simples para devolver el código de escape en forma de cadena. Por ejemplo, `'my string \n my string'` devuelve la cadena `my 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**: especifique `#` delante de los comentarios. Ejemplo: ``` Name: MyWorkflow # This is a comment. SchemaVersion: 1.0 ``` + **Triple guión (`---`)**: no lo utilices `---` en tu código YAML. CodeCatalyst ignora todo lo que sigue a. `---` ### 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 incluya dos puntos (`:`). Por ejemplo, en el siguiente fragmento de código, todos estos elementos son propiedades: `Name`, `SchemaVersion`, `RunMode`, `Triggers`, `Type` y `Branches`. + Una *sección* es cualquier propiedad que tenga 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 Esta es la documentación de referencia para las propiedades de nivel superior en el archivo de definición de 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. Puede que el nombre del flujo de trabajo y el nombre del archivo de definición de flujo de trabajo coincidan, o también puede asignarles nombres diferentes. Los nombres de los flujos de trabajo no tienen por qué ser únicos. Los nombres de los flujos de trabajo están limitados a caracteres alfanuméricos (a-z, A-Z y 0-9), guiones (-) y guiones bajos (\$1). No se permiten espacios. No puede utilizar comillas para permitir caracteres especiales ni espacios en los nombres de los flujos de trabajo. **Interfaz de usuario correspondiente: editor/Workflow propiedades visuales/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`: las ejecuciones múltiples se ponen en cola y se ejecutan una tras otra. Se pueden tener hasta 50 ejecuciones en una cola. + `SUPERSEDED`: las ejecuciones múltiples se ponen en cola y se ejecutan una tras otra. Una cola solo puede tener una ejecución, por lo que si dos ejecuciones terminan juntas en la misma cola, la última se superpone (reemplaza) a la anterior y esta se cancela. + `PARALLEL`: se producen varias ejecuciones simultáneamente. Si esta propiedad se omite, el valor predeterminado es `QUEUED`. Para obtener más información, consulte [Configuración del comportamiento de puesta en cola de las ejecuciones](workflows-configure-runs.md). **Interfaz de usuario correspondiente: editor/Workflow propiedades visuales/Avanzado/Modo de ejecución** ### Compute (Opcional) El motor de computación utilizado para ejecutar las acciones del flujo de trabajo. Puede especificar el motor de computación en el nivel del flujo de trabajo o en el nivel de acción, pero no en ambos. Cuando se especifica en el nivel de flujo de trabajo, la configuración del motor de computación se aplica a todas las acciones definidas en el flujo de trabajo. En el nivel de flujo de trabajo, también puede ejecutar varias acciones en la misma instancia. Para obtener más información, consulte [Uso compartido de recursos de computación entre acciones](compute-sharing.md). Para obtener más información acerca de la computación, consulte [Configuración de imágenes de computación y tiempo de ejecución](workflows-working-compute.md). 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 computación. Puede utilizar uno de los siguientes valores: + **EC2** (editor visual) o `EC2` (editor de YAML) Optimizado para ofrecer flexibilidad durante las ejecuciones de acciones. + **Lambda** (editor visual) o `Lambda` (editor de YAML) Velocidades de inicio de acciones optimizadas. Para obtener más información sobre los tipos de computación, consulte [Tipos de computación](workflows-working-compute.md#compute.types). **Interfaz de usuario correspondiente: editor/Workflow propiedades visuales/avanzada/tipo de cálculo** #### Fleet (Compute/**Fleet**) (Opcional) Especifique la máquina o la 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 las flotas bajo demanda](workflows-working-compute.md#compute.on-demand). Con las flotas aprovisionadas, configura un conjunto de máquinas dedicadas para ejecutar las acciones del flujo de trabajo. Estas máquinas permanecen inactivas, listas para procesar acciones de forma inmediata. Para obtener más información sobre las flotas aprovisionadas, consulte [Propiedades de flotas aprovisionadas](workflows-working-compute.md#compute.provisioned-fleets). Si `Fleet` se omite, el valor predeterminado es `Linux.x86-64.Large`. Para obtener más información acerca de las flotas de computación, consulte [Flotas de computación](workflows-working-compute.md#compute.fleets). **Interfaz de usuario correspondiente: propiedades visuales/Avanzada/Flota de cómputo editor/Workflow ** #### SharedInstance (Compute/**SharedInstance**) (Opcional) Especifique la capacidad de uso compartido de la computación para sus acciones. Con el uso compartido de la computación, las acciones de un flujo de trabajo se ejecutan en la misma instancia (imagen del entorno del tiempo de ejecución). Puede utilizar uno de los siguientes valores: + `TRUE` significa que la imagen del entorno del tiempo de ejecución se comparte entre las acciones del flujo de trabajo. + `FALSE` significa que se inicia una imagen del entorno del tiempo 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 acerca del uso compartido de la computación, consulte [Uso compartido de recursos de computación entre acciones](compute-sharing.md). Interfaz de usuario correspondiente: *ninguna* ### Triggers (Opcional) Secuencia de uno o más desencadenadores de este flujo de trabajo. Si no se especifica ningún desencadenador, debe iniciar el flujo de trabajo manualmente. Para obtener más información acerca de los desencadenadores, consulte [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md). **Interfaz de usuario correspondiente: editor/workflow diagrama visual/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 `Triggers` está configurado) Especifique el tipo de desencadenador. Puede utilizar uno de los siguientes valores: + **Insertar** (editor visual) o `PUSH` (editor de YAML) Un desencadenador de inserción inicia la ejecución de un flujo de trabajo cuando se envía un cambio al repositorio de código fuente. La ejecución del flujo de trabajo utilizará los archivos de la ramificación *a* la que realiza la inserción (es decir, la ramificación de destino). + **Solicitud de extracción** (editor visual) o `PULLREQUEST` (editor de YAML) Un desencadenador de este tipo inicia la ejecución de un flujo de trabajo cuando se abre, actualiza o cierra una solicitud de extracción en el repositorio de código fuente. La ejecución del flujo de trabajo utilizará los archivos de la ramificación *desde* la que realiza la extracción (es decir, la ramificación de origen). + **Programación** (editor visual) o `SCHEDULE` (editor de YAML) Un desencadenador de tipo programación inicia las ejecuciones del flujo de trabajo según una programación definida por una expresión cron que especifique. Se iniciará una ejecución de flujo de trabajo independiente para cada ramificación del repositorio de código fuente utilizando los archivos de la ramificación. (Para limitar las ramificaciones en las que se activa el desencadenador, use el campo **Ramificaciones** (editor visual) o la propiedad `Branches` (editor de YAML)). Cuando configure un desencadenador de programación, siga estas directrices: + Utilice solo un desencadenador 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 desencadenador con el tiempo adecuado entre ejecuciones. Para obtener más información, consulte [Expression](#workflow.triggers.expression). Para ver ejemplos, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md). **Interfaz de usuario correspondiente: editor/workflow diagrama visual/activadores/tipo de activador** #### Events (Triggers/**Events**) (Obligatorio si el `Type` de desencadenador está configurado como `PULLREQUEST`) Especifica el tipo de eventos de solicitud de extracción que iniciarán la ejecución de un flujo de trabajo. Los siguientes valores son los válidos: + **Se crea una solicitud de extracción** (editor visual) o `OPEN` (editor de YAML) 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` (editor de YAML) La ejecución del flujo de trabajo se inicia cuando se cierra una solicitud de extracción. El comportamiento del evento `CLOSED` es complejo y se entiende mejor con un ejemplo. Para obtener más información, consulte [Ejemplo: Desencadenador con una extracción, ramificaciones y un evento CLOSED](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close). + **Se realiza una nueva revisión para la solicitud de extracción** (editor visual) o `REVISION` (editor de YAML) 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 se crea una nueva revisión cada vez que alguien envía una nueva confirmación a la ramificación de origen especificada en la solicitud de extracción. Si incluye el evento `REVISION` en el desencadenador de la solicitud de extracción, puede omitir el evento `OPEN`, ya que `REVISION` es un superconjunto de `OPEN`. Puede especificar varios eventos en el mismo desencadenador de la solicitud de extracción. Para ver ejemplos, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md). **Interfaz de usuario correspondiente: diagrama editor/workflow visual/activadores/eventos para la solicitud de extracción** #### Branches (Triggers/**Branches**) (Opcional) Especifica las ramificaciones del repositorio de código fuente que supervisa el desencadenador para saber cuándo iniciar la ejecución de un flujo de trabajo. Puede usar patrones de expresiones regulares para definir los nombres de las ramificaciones. Por ejemplo, use `main.*` para hacer coincidir todas las ramificaciones que comiencen por `main`. Las ramificaciones que se deben especificar son diferentes en función del tipo de desencadenador: + En el caso de un desencadenador de inserción, especifique las ramificaciones *en* las que va a realizar la inserción, es decir, las ramificaciones de *destino*. Se iniciará una ejecución de flujo de trabajo por cada ramificación coincidente, utilizando los archivos de la ramificación coincidente. Ejemplos: `main.*`, `mainline` + En el caso de un desencadenador de solicitud de extracción, especifique las ramificaciones *en* las que va a realizar la inserción, es decir, las ramificaciones de *destino*. Se iniciará una ejecución de flujo de trabajo por cada ramificación coincidente, utilizando el archivo de definición del flujo de trabajo y los archivos de origen de la ramificación de **origen** (*no* de la ramificación coincidente). Ejemplos: `main.*`, `mainline`, `v1\-.*` (busca coincidencias con las ramificaciones que comiencen por `v1-`) + Para un desencadenador de programación, especifique las ramificaciones que contengan los archivos que quiera que utilice la ejecución programada. Se iniciará una ejecución de flujo de trabajo por cada ramificación coincidente, utilizando el archivo de definición del flujo de trabajo y los archivos de origen en la ramificación coincidente. Ejemplos: `main.*`, `version\-1\.0` **nota** Si *no* especifica ninguna ramificación, el activador supervisa todas las ramificaciones del repositorio de código fuente e iniciará una ejecución de flujo de trabajo con el archivo de definición del flujo de trabajo y los archivos de código fuente en: La ramificación *en* la que realiza la inserción (para desencadenadores de inserción). Para obtener más información, consulte [Ejemplo: Desencadenador de inserción de código sencillo](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple). La ramificación *desde* la que realiza la extracción (para desencadenadores de solicitudes de extracción). Para obtener más información, consulte [Ejemplo: Desencadenador de solicitud de extracción sencillo](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple). Todas las ramificaciones (para desencadenadores de programación). Se iniciará una ejecución de flujo de trabajo por cada ramificación del repositorio de código fuente. Para obtener más información, consulte [Ejemplo: Desencadenador de programación sencillo](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple). Para obtener más información acerca de las ramificaciones y los desencadenadores, consulte [Directrices de uso para activadores y ramificaciones](workflows-add-trigger-considerations.md). Para obtener más ejemplos, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md). **Interfaz de usuario correspondiente: visual/Branches editor/workflow diagram/Triggers** #### FilesChanged (Triggers/**FilesChanged**) (Opcional si el desencadenador `Type` está configurado como `PUSH` o `PULLREQUEST`. No se admite si el desencadenador `Type` está configurado como `SCHEDULE`). Especifica los archivos o carpetas del repositorio de código fuente 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: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md). **Interfaz de usuario correspondiente: editor/workflow diagrama visual/activadores/archivos modificados** #### Expression (Triggers/**Expression**) (Obligatorio si el `Type` de desencadenador está configurado como `SCHEDULE`) Especifique la expresión cron que describe cuándo desea que se ejecuten sus flujos de trabajo programados. Las expresiones cron 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 | ? | \$1 | MON-FRI | \$1 | Ejecuta un flujo de trabajo a medianoche (UTC\$10) cada día de lunes a viernes. | | 0 | 2 | \$1 | \$1 | ? | \$1 | Ejecuta un flujo de trabajo a las 2:00 h (UTC\$10) todos los días. | | 15 | 22 | \$1 | \$1 | ? | \$1 | Ejecuta un flujo de trabajo a las 22:15 h (UTC\$10) todos los días. | | 0/30 | 22-2 | ? | \$1 | SAT-SUN | \$1 | Ejecuta un flujo de trabajo cada 30 minutos de sábado a domingo, entre las 22:00 h del día de inicio y las 2:00 h del día siguiente (UTC\$10). | | 45 | 13 | L | \$1 | ? | 2023-2027 | Ejecuta un flujo de trabajo a las 13:45 (UTC\$10) del último día del mes entre los años 2023 y 2027, ambos inclusive. | Al especificar las expresiones cron CodeCatalyst, asegúrese de seguir estas pautas: + Especifique una sola expresión cron por desencadenador `SCHEDULE`. + Escriba la expresión cron entre comillas dobles (`"`) en el editor de YAML. + Especifique la hora en tiempo universal coordinado (UTC). El resto de zonas horarias no son compatibles. + Configure al menos 30 minutos entre ejecuciones. Una cadencia más rápida no es compatible. + Especifique el *days-of-week* campo *days-of-month* o, 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](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) la Guía del usuario de *Amazon EventBridge *. Las expresiones cron CodeCatalyst funcionan exactamente de EventBridge la misma manera. Para ver ejemplos de desencadenadores de programación, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md). **Interfaz de usuario correspondiente: editor/workflow diagram/Triggers visual/horario** ### 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 propiedad `Identifier` que indica el ID único y codificado de la acción. Por ejemplo, `aws/build@v1` identifica la acción de creación. + Una sección `Configuration` que contiene propiedades específicas de la acción. Para obtener más información sobre cada tipo de acción, consulte [Tipos de acción](workflows-actions.md#workflows-actions-types). El tema [Tipos de acción](workflows-actions.md#workflows-actions-types) tiene enlaces a la documentación de cada acción. A continuación consta la referencia de YAML 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) *action-name*Sustitúyalo por 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 contener caracteres alfanuméricos, guiones y guiones bajos. Para obtener más información acerca de las reglas de sintaxis, consulte [Directrices de sintaxis de YAML](#workflow.syntax.conv). Para obtener más información sobre las prácticas de nomenclatura de las acciones, incluidas las restricciones, consulte la [action-or-gate-name](#workflow.actions.name). **Interfaz de usuario correspondiente: editor visual/ pestaña de *action-name* configuración/ Nombre de la acción o **Nombre de la acción para mostrar**** #### 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. *action-group-name*Sustitúyalo por 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 contener caracteres alfanuméricos, guiones y guiones bajos. Para obtener más información acerca de las reglas de sintaxis, consulte [Directrices de sintaxis de YAML](#workflow.syntax.conv). Para obtener más información sobre los grupos de acciones, consulte [Agrupación de acciones en grupos de acciones](workflows-group-actions.md). Interfaz de usuario correspondiente: *ninguna*