# Sintaxis del flujo de trabajo para Acciones de GitHub Un flujo de trabajo es un proceso automatizado configurable formado por uno o más trabajos. Debes crear un archivo YAML para definir tu configuración de flujo de trabajo. ## Acerca de la sintaxis de YAML para flujos de trabajo Los archivos de flujo de trabajo usan la sintaxis de YAML y deben tener una extensión de archivo `.yml` o `.yaml`. Si no tienes experiencia con YAML y quieres obtener más información, consulta [Aprende YAML en Y minutos](https://learnxinyminutes.com/docs/yaml/). Debe almacenar los archivos de flujo de trabajo en el directorio `.github/workflows` del repositorio. ## `name` El nombre del flujo de trabajo. GitHub muestra los nombres de los flujos de trabajo en la pestaña "Acciones" del repositorio. Si omite `name`, GitHub muestra la ruta de acceso del archivo de flujo de trabajo relativa a la raíz del repositorio. ## `run-name` Nombre de las ejecuciones de flujo de trabajo generadas a partir del flujo de trabajo. GitHub muestra el nombre de ejecución del flujo de trabajo en la lista de ejecuciones de flujo de trabajo en la pestaña "Acciones" del repositorio. Si `run-name` se omite o solo es espacio en blanco, el nombre de ejecución se establece en información específica del evento para la ejecución del flujo de trabajo. Por ejemplo, para un flujo de trabajo que desencadena un evento `push` o `pull_request`, se establece como mensaje de confirmación o como título de la solicitud de cambios. Este valor puede incluir expresiones y puede hacer referencia a los contextos [`github`](/es/actions/learn-github-actions/contexts#github-context) y [`inputs`](/es/actions/learn-github-actions/contexts#inputs-context). ### Ejemplo de `run-name` ```yaml run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }} ``` ## `on` Para desencadenar automáticamente un flujo de trabajo, use `on` para definir qué eventos pueden hacer que se ejecute el flujo de trabajo. Para obtener una lista de eventos disponibles, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/using-workflows/events-that-trigger-workflows). Puedes definir eventos sencillos o múltiples que puedan activar un flujo de trabajo o configurar una programación. También puedes restringir la ejecución de un flujo de trabajo para que solo ocurra para archivos, etiquetas o cambios de rama específicos. Estas opciones se describen en las secciones siguientes. ### Utilizar un evento simple Por ejemplo, un flujo de trabajo con el siguiente valor de `on` se ejecutará cuando se realice una subida a cualquier rama en el repositorio del flujo de trabajo: ```yaml on: push ``` ### Utilizar eventos múltiples Puedes especificar eventos sencillos o múltiples. Por ejemplo, un flujo de trabajo con el siguiente valor de `on` se ejecutará cuando se realice una inserción en cualquier rama del repositorio o cuando alguien lo bifurque: ```yaml on: [push, fork] ``` Si especificas eventos múltiples, únicamente uno de ellos necesitará ocurrir para que se active tu flujo de trabajo. Si ocurren eventos múltiples de activación para tu flujo de trabajo al mismo tiempo, se activarán las ejecuciones de flujo de trabajo múltiples. ### Utilizar tipos de actividad Algunos eventos tienen tipos de actividad que te proporcionan más control sobre cuándo debería ejecutarse tu flujo de trabajo. Use `on..types` para definir el tipo de actividad de evento que desencadenará una ejecución de flujo de trabajo. Por ejemplo, el evento `issue_comment` tiene los tipos de actividad `created`, `edited` y `deleted`. Si el flujo de trabajo desencadena el evento `label`, se ejecutará cada vez que se cree, edite o elimine una etiqueta. Si especifica el tipo de actividad `created` para el evento `label`, el flujo de trabajo se ejecutará cuando se cree una etiqueta pero no cuando se edite o elimine. ```yaml on: label: types: - created ``` Si especificas tipos de actividad múltiples, solo uno de ellos necesitará ocurrir para que se active tu flujo de trabajo. Si ocurren tipos de actividad de eventos activadores múltiples al mismo tiempo para tu flujo de trabajo, se activarán ejecuciones de flujo de trabajo múltiples. Por ejemplo, el siguiente flujo de trabajo se activa cuando se abre o etiqueta una propuesta. Si se abre una propuesta con dos etiquetas, iniciarán tres ejecuciones de flujo de trabajo: una para el evento de la propuesta abierta y dos para los eventos etiquetados de las dos propuestas. ```yaml on: issues: types: - opened - labeled ``` Para más información sobre cada evento y sus tipos de actividad, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/using-workflows/events-that-trigger-workflows). ### Utilizar filtros Algunos eventos tienen filtros que te dan más control sobre qué flujo de trabajo debería ejecutarse. Por ejemplo, el evento `push` tiene un filtro `branches` que hace que el flujo de trabajo solo se ejecute cuando se realice una inserción en una rama que coincida con el filtro `branches`, en lugar de cuando se produzca cualquier inserción. ```yaml on: push: branches: - main - 'releases/**' ``` ### Utilizar los tipos de actividad y filtros con eventos múltiples Si especificas los tipos de actividad o filtros para un evento y tu flujo de trabajo activa eventos múltiples, deberás configurar cada uno de ellos por separado. Debe agregar dos puntos (`:`) a todos los eventos, incluidos aquellos sin configuración. Por ejemplo, un flujo de trabajo con el valor `on` siguiente se ejecutará cuando: * Se crea una etiqueta * Se hace una inserción a la rama `main` en el repositorio. * Se hace una subida a la rama habilitada por GitHub Pages ```yaml on: label: types: - created push: branches: - main page_build: ``` ## `on..types` Usa `on..types` para definir el tipo de actividad que desencadenará una ejecución de flujo de trabajo. La mayoría de los eventos GitHub son activados por más de un tipo de actividad. Por ejemplo, `label` se desencadena cuando una etiqueta es `created`, `edited` o `deleted`. La palabra clave `types` te permite reducir la actividad que hace que se ejecute el flujo de trabajo. Cuando solo un tipo de actividad desencadena un evento de webhook, la palabra clave `types` no es necesaria. Puedes usar una matriz de eventos `types`. Para más información sobre cada evento y sus tipos de actividad, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/using-workflows/events-that-trigger-workflows#available-events). ```yaml on: label: types: [created, edited] ``` ## `on..` Al usar los eventos `pull_request` y `pull_request_target`, puede configurar un flujo de trabajo a fin de que solo se ejecute para las solicitudes de incorporación de cambios destinadas a ramas específicas. Use el filtro `branches` cuando quiera incluir patrones de nombre de rama, o bien cuando quiera incluirlos y excluirlos. Use el filtro `branches-ignore` cuando solo quiera excluir patrones de nombre de rama. No puede usar los filtros `branches` y `branches-ignore` para el mismo evento de un flujo de trabajo. Si defines `branches`/`branches-ignore` y [`paths`/`paths-ignore`](/es/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), el flujo de trabajo solo se ejecutará cuando se cumplan ambos filtros. Las palabras clave `branches` y `branches-ignore` aceptan patrones globales que usan caracteres como `*`, `**`, `+`, `?` y `!`, entre otros, para que coincidan con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quiere una coincidencia literal, necesita escapar a cada uno de estos caracteres especiales con `\`. Para más información sobre los patrones globales, consulta [Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet). ### Ejemplo: Incluir ramas Los patrones definidos en `branches` se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutará siempre que exista un evento `pull_request` para una solicitud de incorporación de cambios destinada a: * Una rama denominada `main` (`refs/heads/main`) * Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`) * Una rama cuyo nombre comienza por `releases/`, como `releases/10` (`refs/heads/releases/10`) ```yaml on: pull_request: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' ``` Si se omite un flujo de trabajo debido al filtrado de ramas, al [filtrado de rutas de acceso](/es/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) o a un [mensaje de confirmación](/es/actions/managing-workflow-runs/skipping-workflow-runs), las comprobaciones asociadas a ese flujo de trabajo permanecerán en estado "Pendiente". Se bloqueará la fusión mediante combinación de una solicitud de incorporación de cambios que requiera esas comprobaciones para realizarse correctamente. ### Ejemplo: Excluir ramas Cuando un patrón coincide con el patrón `branches-ignore`, el flujo de trabajo no se ejecutará. Los patrones definidos en `branches-ignore` se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutará siempre que haya un evento de `pull_request` a menos de que la solicitud de incorporación de cambios esté destinada a: * Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`) * Una rama cuyo nombre coincide con `releases/**-alpha`, como `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) ```yaml on: pull_request: # Sequence of patterns matched against refs/heads branches-ignore: - 'mona/octocat' - 'releases/**-alpha' ``` ### Ejemplo: Incluir y excluir ramas No puede usar `branches` y `branches-ignore` para filtrar el mismo evento en un único flujo de trabajo. Si quiere tanto incluir como excluir patrones de rama para un solo evento, utilice el filtro `branches` junto con el carácter `!` para indicar qué ramas deberían excluirse. Si define una rama con el carácter `!`, también tendrá que definir al menos otra sin el carácter `!`. Si solo quiere excluir ramas, use `branches-ignore` en su lugar. El orden en que defines los patrones importa. * Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva hará que se excluya la referencia de Git. * Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git. El flujo de trabajo siguiente se ejecutará en eventos `pull_request` para las solicitudes de incorporación de cambios que tienen como destino `releases/10` o `releases/beta/mona`, pero no para las que tienen como destino `releases/10-alpha` o `releases/beta/3-alpha` porque el patrón negativo `!releases/**-alpha` sigue el patrón positivo. ```yaml on: pull_request: branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on.push.` Al usar el evento `push`, puede configurar un flujo de trabajo para que se ejecute en ramas o etiquetas específicas. Use el filtro `branches` cuando quiera incluir patrones de nombre de rama, o bien cuando quiera incluirlos y excluirlos. Use el filtro `branches-ignore` cuando solo quiera excluir patrones de nombre de rama. No puede usar los filtros `branches` y `branches-ignore` para el mismo evento de un flujo de trabajo. Use el filtro `tags` cuando quiera incluir los patrones de nombre de etiqueta, o bien cuando quiera incluirlos y excluirlos. Use el filtro `tags-ignore` cuando solo quiera excluir patrones de nombre de etiqueta. No puede usar los filtros `tags` y `tags-ignore` para el mismo evento de un flujo de trabajo. Si defines solo `tags`/`tags-ignore` o solo `branches`/`branches-ignore`, el flujo de trabajo no se ejecutará para los eventos que afecten a la referencia de Git indefinida. Si no defines `tags`/`tags-ignore` ni `branches`/`branches-ignore`, el flujo de trabajo se ejecutará para eventos que afecten a ramas o etiquetas. Si defines `branches`/`branches-ignore` y [`paths`/`paths-ignore`](/es/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), el flujo de trabajo solo se ejecutará cuando se cumplan ambos filtros. Las palabras clave `branches`, `branches-ignore`, `tags` y `tags-ignore` aceptan patrones globales que usan caracteres como `*`, `**`, `+`, `?`, `!` y otros para que coincidan con más de un nombre de rama o etiqueta. Si un nombre contiene cualquiera de estos caracteres y quiere una coincidencia literal, necesita *escapar* a cada uno de estos caracteres especiales con `\`. Para más información sobre los patrones globales, consulta [Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet). ### Ejemplo: Incluye ramas y etiquetas Los patrones definidos en `branches` y `tags` se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que hubiera un evento `push` para: * Una rama denominada `main` (`refs/heads/main`) * Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`) * Una rama cuyo nombre comienza por `releases/`, como `releases/10` (`refs/heads/releases/10`) * Una etiqueta denominada `v2` (`refs/tags/v2`) * Una etiqueta cuyo nombre comienza por `v1.`, como `v1.9.1` (`refs/tags/v1.9.1`) ```yaml on: push: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' # Sequence of patterns matched against refs/tags tags: - v2 - v1.* ``` ### Ejemplo: Excluir ramas y etiquetas Cuando un patrón coincide con el patrón `branches-ignore` o `tags-ignore`, el flujo de trabajo no se ejecutará. Los patrones definidos en `branches` y `tags` se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutará siempre que haya un evento `push`, a menos que el evento `push` sea para: * Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`) * Una rama cuyo nombre coincide con `releases/**-alpha`, como `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) * Una etiqueta denominada `v2` (`refs/tags/v2`) * Una etiqueta cuyo nombre comienza por `v1.`, como `v1.9` (`refs/tags/v1.9`) ```yaml on: push: # Sequence of patterns matched against refs/heads branches-ignore: - 'mona/octocat' - 'releases/**-alpha' # Sequence of patterns matched against refs/tags tags-ignore: - v2 - v1.* ``` ### Ejemplo: incluir y excluir ramas y etiquetas No puede usar `branches` y `branches-ignore` para filtrar el mismo evento en un único flujo de trabajo. Del mismo modo, no puede usar `tags` y `tags-ignore` para filtrar el mismo evento en un único flujo de trabajo. Si quiere tanto incluir como excluir patrones de rama o etiqueta para un solo evento, use el filtro `branches` o `tags` junto con el carácter `!` para indicar qué ramas o etiquetas se deberían excluir. Si define una rama con el carácter `!`, también tendrá que definir al menos otra sin el carácter `!`. Si solo quiere excluir ramas, use `branches-ignore` en su lugar. Del mismo modo, si define una etiqueta con el carácter `!`, también tendrá que definir al menos otra sin el carácter `!`. Si solo quiere excluir etiquetas, use `tags-ignore` en su lugar. El orden en que defines los patrones importa. * Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva hará que se excluya la referencia de Git. * Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git. El siguiente flujo de trabajo se ejecutará en inserciones en `releases/10` o `releases/beta/mona`, pero no en `releases/10-alpha` o `releases/beta/3-alpha`, porque el patrón `!releases/**-alpha` negativo sigue el patrón positivo. ```yaml on: push: branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on..` Al usar los eventos `push` y `pull_request`, puedes configurar un flujo de trabajo para su ejecución en función de las rutas de acceso de archivo que se cambien. Los filtros de ruta no se evalúan para subidas de etiquetas. Usa el filtro `paths` cuando quieras incluir patrones de ruta de acceso de archivos o cuando quieras tanto incluirlos como excluirlos. Usa el filtro `paths-ignore` cuando solo quieras excluir patrones de ruta de acceso de archivos. No puede usar los filtros `paths` y `paths-ignore` para el mismo evento de un flujo de trabajo. Si quieres tanto incluir como excluir patrones de ruta de acceso para un solo evento, usa el filtro `paths` junto con el carácter `!` para indicar qué rutas de acceso se deben excluir. > \[!NOTE] > El orden en que defines los patrones `paths` importa: > > * El tener una coincidencia de patrón negativo (con el prefijo `!`) después de una coincidencia positiva hará que se excluya la ruta de acceso. > * Un patrón de coincidencia positiva luego de una coincidencia negativa excluirá nuevamente la ruta. Si define `branches`/`branches-ignore` y `paths`/`paths-ignore`, el flujo de trabajo solo se ejecutará cuando se cumplan los dos filtros. Las palabras clave `paths` y `paths-ignore` aceptan patrones globales que usan los caracteres comodín `*` y `**` para coincidir con más de un nombre de ruta de acceso. Para obtener más información, consulta e[Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet). ### Ejemplo: Incluyendo rutas de acceso Si al menos una ruta de acceso coincide con un patrón en el filtro `paths`, se ejecuta el flujo de trabajo. Por ejemplo, el flujo de trabajo siguiente se ejecutaría cada vez que envíes cambios de un archivo JavaScript (`.js`). ```yaml on: push: paths: - '**.js' ``` Si se omite un flujo de trabajo debido al filtrado de rutas de acceso, al [filtrado de ramas](/es/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) o a un [mensaje de confirmación](/es/actions/managing-workflow-runs/skipping-workflow-runs), las comprobaciones asociadas a ese flujo de trabajo permanecerán en estado "Pendiente". Se bloqueará la fusión mediante combinación de una solicitud de incorporación de cambios que requiera esas comprobaciones para realizarse correctamente. ### Ejemplo: Exclusión de rutas de acceso Cuando todos los nombres de ruta de acceso coincidan con los patrones de `paths-ignore`, el flujo de trabajo no se ejecutará. Si alguno de los nombres de ruta de acceso no coincide con los patrones de `paths-ignore`, aunque algunos nombres de ruta coincidan con estos, el flujo de trabajo se ejecutará. Un flujo de trabajo con el siguiente filtro de ruta de acceso solo se ejecutará en los eventos `push` que incluyan al menos un archivo externo al directorio `docs` en la raíz del repositorio. ```yaml on: push: paths-ignore: - 'docs/**' ``` ### Ejemplo: Inclusión y exclusión de rutas de acceso No puede usar `paths` y `paths-ignore` para filtrar el mismo evento en un único flujo de trabajo. Si quieres tanto incluir como excluir patrones de ruta de acceso para un solo evento, usa el filtro `paths` junto con el carácter `!` para indicar qué rutas de acceso se deben excluir. Si defines una ruta de acceso con el carácter `!`, también debes definir al menos una ruta de acceso sin el carácter `!`. Si solo quieres excluir rutas de acceso, usa `paths-ignore` en su lugar. El orden en que defines los patrones `paths` importa: * El tener una coincidencia de patrón negativo (con el prefijo `!`) después de una coincidencia positiva hará que se excluya la ruta de acceso. * Un patrón de coincidencia positiva luego de una coincidencia negativa excluirá nuevamente la ruta. Este ejemplo se ejecuta cada vez que el evento `push` incluye un archivo en el directorio `sub-project` o sus subdirectorios, a menos que el archivo esté en el directorio `sub-project/docs`. Por ejemplo, una inserción que haya cambiado `sub-project/index.js` o `sub-project/src/index.js` desencadenará una ejecución de flujo de trabajo, pero una inserción que solo cambie `sub-project/docs/readme.md` no lo hará. ```yaml on: push: paths: - 'sub-project/**' - '!sub-project/docs/**' ``` ### Comparaciones de diferencias de Git > \[!NOTE] > Si inserta más de 1000 confirmaciones o si GitHub no genera las diferencias debido a que se agota el tiempo de espera, el flujo de trabajo siempre se ejecutará. El filtro determina si un flujo de trabajo debe ejecutarse al evaluar los archivos modificados y ejecutarlos en comparación con la lista de `paths-ignore` o `paths`. Si no hay archivos modificados, no se ejecutará el flujo de trabajo. GitHub genera la lista de archivos modificados usando diferencias de dos puntos para las subidas y de tres puntos para las solicitudes de extracción: * **Solicitudes de incorporación de cambios:** las diferencias de tres puntos son una comparación entre la versión más reciente de la rama de tema y la confirmación en la que la rama de tema se sincronizó por última vez con la rama base. * **Inserción en ramas existentes:** una diferencia de dos puntos compara los SHA base y principal directamente entre sí. * **Inserción en ramas nuevas:** una diferencia de dos puntos comparada con el elemento primario del antecesor de la confirmación insertada más profunda. > \[!NOTE] > Los diffs se limitan a 300 archivos. Si hay archivos que cambiaron y no se empataron en los primeros 300 archivos que devuelve el filtro, el flujo de trabajo no se ejecutará. Puede que necesites crear filtros más específicos para que el flujo de trabajo se ejecute automáticamente. Para más información, consulta [Acerca de comparar ramas en solicitudes de extracción](/es/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests). ## `on.schedule` Puede usar `on.schedule` para definir una programación de tiempo para los flujos de trabajo. Use la [sintaxis cron POSIX](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) para programar flujos de trabajo que se ejecuten en momentos específicos. De forma predeterminada, los flujos de trabajo programados se ejecutan en UTC. Opcionalmente, puede especificar una zona horaria mediante una [cadena de zona horaria de IANA](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) para la programación con reconocimiento de zona horaria. Los flujos de trabajo programados se ejecutan en el commit más reciente de la rama predeterminada. El intervalo más corto en el que puedes ejecutar flujos de trabajo programados es una vez cada 5 minutos. > \[!NOTE] > Para las programaciones que se establecen `timezone` en una zona horaria que observa el horario de verano, durante las transiciones de adelanto del horario de verano, los flujos de trabajo programados en horas saltadas avanzan a la próxima hora válida. Por ejemplo, un horario de 2:30 a. m. se adelanta a las 3:00 a. m. La sintaxis de cron tiene cinco campos separados por un espacio, y cada campo representa una unidad de tiempo. ```text ┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of the month (1 - 31) │ │ │ ┌───────────── month (1 - 12 or JAN-DEC) │ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT) │ │ │ │ │ * * * * * ``` Puedes usar estos operadores en cualquiera de los cinco campos: | Operador | Descripción | Ejemplo | | -------------------------------------------------------------------------------------------------------- | -------------------------------- | ------- | | \* | Cualquier valor | | | `15 * * * *` se ejecuta en el minuto 15 de cada hora de cada día. | | | | , | Separador de la lista de valores | | | `2,10 4,5 * * *` se ejecuta en los minutos 2 y 10 de la 4ª y 5ª hora de cada día. | | | | - | Rango de valores | | | `30 4-6 * * *` se ejecuta en el minuto 30 de la 4ª, 5ª y 6ª hora. | | | | / | Valores del paso | | | `20/15 * * * *` se ejecuta cada 15 minutos a partir del minuto 20 hasta el 59 (los minutos 20, 35 y 50). | | | Este ejemplo desencadena el flujo de trabajo para que se ejecute a las 5:30 a.m. en la zona horaria America/New\_York de lunes a viernes. ```yaml on: schedule: - cron: '30 5 * * 1-5' timezone: "America/New_York" ``` Varios eventos `schedule` pueden desencadenar un único flujo de trabajo. Accede al evento `schedule` que ha desencadenado el flujo de trabajo mediante el contexto `github.event.schedule`. En este ejemplo se desencadena el flujo de trabajo para que se ejecute a las 5:30 UTC de lunes a jueves, y a las 17:30 UTC los martes y los jueves, pero omite el paso `Not on Monday or Wednesday` para el lunes y el miércoles. ```yaml on: schedule: - cron: '30 5 * * 1,3' - cron: '30 5,17 * * 2,4' jobs: test_schedule: runs-on: ubuntu-latest steps: - name: Not on Monday or Wednesday if: github.event.schedule != '30 5 * * 1,3' run: echo "This step will be skipped on Monday and Wednesday" - name: Every time run: echo "This step will always run" ``` Para más información sobre los eventos `schedule`, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule). ## `on.workflow_call` Use `on.workflow_call` para definir las entradas y salidas de un flujo de trabajo reutilizable. También puedes mapear los secretos que están disponibles para el flujo de trabajo llamado. Para más información sobre los flujos de trabajo reutilizables, consulta [Reutilización de flujos de trabajo](/es/actions/using-workflows/reusing-workflows). ## `on.workflow_call.inputs` Al usar la palabra clave `workflow_call`, puede especificar opcionalmente las entradas que se pasan al flujo de trabajo llamado desde el flujo de trabajo que realiza la llamada. Para obtener más información sobre la palabra clave `workflow_call`, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/using-workflows/events-that-trigger-workflows#workflow-reuse-events). Además de los parámetros de entrada estándar que están disponibles, `on.workflow_call.inputs` necesita un parámetro `type`. Para más información, vea [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype). Si no se establece un parámetro `default`, el valor predeterminado de la entrada es `false` para un valor booleano, `0` para un número y `""` para una cadena. Dentro del flujo de trabajo llamado, puede usar el contexto `inputs` para hacer referencia a una entrada. Para más información, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts#inputs-context). Si un flujo de trabajo llamante pasa una entrada que no se especifica en el flujo llamado, dará un error como resultado. ### Ejemplo de `on.workflow_call.inputs` ```yaml on: workflow_call: inputs: username: description: 'A username passed from the caller workflow' default: 'john-doe' required: false type: string jobs: print-username: runs-on: ubuntu-latest steps: - name: Print the input name to STDOUT run: echo The username is ${{ inputs.username }} ``` Para más información, consulta [Reutilización de flujos de trabajo](/es/actions/using-workflows/reusing-workflows). ## `on.workflow_call.inputs..type` Obligatorio si se define la entrada para la palabra clave `on.workflow_call`. El valor de este parámetro es una secuencia que especifica el tipo de datos de la entrada. Debe ser uno de los siguientes: `boolean`, `number` o `string`. ## `on.workflow_call.outputs` Un mapa de salidas para un flujo de trabajo llamado. Las salidas de flujo de trabajo llamadas se encuentran disponibles en todos los jobs en línea descendente en el flujo de trabajo llamante. Cada salida tiene un identificador, un valor `description,` opcional y un valor `value.`. `value` se debe establecer en el valor de una salida de un trabajo dentro del flujo de trabajo llamado. En el ejemplo siguiente, se definen dos salidas para este flujo de trabajo reutilizable: `workflow_output1` y `workflow_output2`. Se asignan a las salidas `job_output1` y `job_output2`, las dos de un trabajo denominado `my_job`. ### Ejemplo de `on.workflow_call.outputs` ```yaml on: workflow_call: # Map the workflow outputs to job outputs outputs: workflow_output1: description: "The first job output" value: ${{ jobs.my_job.outputs.job_output1 }} workflow_output2: description: "The second job output" value: ${{ jobs.my_job.outputs.job_output2 }} ``` Para obtener información sobre cómo hacer referencia a una salida de trabajo, vea [`jobs..outputs`](#jobsjob_idoutputs). Para más información, consulta [Reutilización de flujos de trabajo](/es/actions/using-workflows/reusing-workflows). ## `on.workflow_call.secrets` Un mapa de los secretos que pueden utilizarse en el flujo de trabajo llamado. Dentro del flujo de trabajo llamado, puede usar el contexto `secrets` para hacer referencia a un secreto. > \[!NOTE] > Si vas a pasar el secreto a un flujo de trabajo reutilizable anidado, deberás usar [`jobs..secrets`](#jobsjob_idsecrets) de nuevo para pasar el secreto. Para más información, consulta [Reutilización de flujos de trabajo](/es/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows). Si un flujo de trabajo llamante pasa un secreto que no se especifica en el flujo de trabajo llamado, esto da un error como resultado. ### Ejemplo de `on.workflow_call.secrets` ```yaml on: workflow_call: secrets: access-token: description: 'A token passed from the caller workflow' required: false jobs: pass-secret-to-action: runs-on: ubuntu-latest steps: # passing the secret to an action - name: Pass the received secret to an action uses: ./.github/actions/my-action with: token: ${{ secrets.access-token }} # passing the secret to a nested reusable workflow pass-secret-to-workflow: uses: ./.github/workflows/my-workflow secrets: token: ${{ secrets.access-token }} ``` ## `on.workflow_call.secrets.` Un identificador de secuencia para asociar con el secreto. ## `on.workflow_call.secrets..required` Un booleano que especifica si el secreto debe suministrarse. ## `on.workflow_run.` Cuando utilice el evento `workflow_run`, puede especificar qué ramas debe ejecutar el flujo de trabajo activador para que se active tu flujo. Los filtros `branches` y `branches-ignore` aceptan patrones globales que usan caracteres como `*`, `**`, `+`, `?` y `!`, entre otros, para que coincidan con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quiere una coincidencia literal, necesita *escapar* a cada uno de estos caracteres especiales con `\`. Para más información sobre los patrones globales, consulta [Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet). Por ejemplo, un flujo de trabajo con el siguiente activador solo se ejecutará cuando el flujo de trabajo `Build` se ejecute en una rama cuyo nombre empiece por `releases/`: ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' ``` Un flujo de trabajo con el siguiente activador solo se ejecutará cuando el flujo de trabajo `Build` se ejecute en una rama cuyo nombre empiece por `canary`: ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches-ignore: - "canary" ``` No puede usar los filtros `branches` y `branches-ignore` para el mismo evento de un flujo de trabajo. Si quiere tanto incluir como excluir patrones de rama para un solo evento, utilice el filtro `branches` junto con el carácter `!` para indicar qué ramas deberían excluirse. El orden en que defines los patrones importa. * El tener una coincidencia de patrón negativo (con prefijo `!`) después de una coincidencia positiva hará que se excluya la rama. * El tener un patrón de coincidencia positivo después de una coincidencia negativa hará que se incluya la rama nuevamente. Por ejemplo, un flujo de trabajo con el siguiente activador se ejecutará cuando el flujo de trabajo `Build` se ejecute en una cuyo nombre sea `releases/10` o `releases/beta/mona`, pero no `releases/10-alpha`, `releases/beta/3-alpha` ni `main`. ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on.workflow_dispatch` Cuando se usa el evento `workflow_dispatch`, puede especificar opcionalmente entradas que se pasan al flujo de trabajo. Este desencadenador solo recibe eventos cuando el archivo de flujo de trabajo está en la rama predeterminada. ## `on.workflow_dispatch.inputs` El flujo de trabajo desencadenado recibe las entradas en el contexto `inputs`. Para más información, consulta [Contextos](/es/actions/learn-github-actions/contexts#inputs-context). > \[!NOTE] > > * El flujo de trabajo también recibirá las entradas en el contexto `github.event.inputs`. La información de los contextos `inputs` y `github.event.inputs` son idénticos, salvo que el contexto `inputs` conserva los valores booleanos como tales en lugar de convertirlos en cadenas. El tipo `choice` se resuelve en una cadena y es una única opción seleccionable. > * El número máximo de propiedades de nivel superior para `inputs` es 25 . > * La carga máxima de `inputs` es de 65 535 caracteres. ### Ejemplo de `on.workflow_dispatch.inputs` ```yaml on: workflow_dispatch: inputs: logLevel: description: 'Log level' required: true default: 'warning' type: choice options: - info - warning - debug print_tags: description: 'True to print to STDOUT' required: true type: boolean tags: description: 'Test scenario tags' required: true type: string environment: description: 'Environment to run tests against' type: environment required: true jobs: print-tag: runs-on: ubuntu-latest if: ${{ inputs.print_tags }} steps: - name: Print the input tag to STDOUT run: echo The tags are ${{ inputs.tags }} ``` ## `on.workflow_dispatch.inputs..required` Valor booleano que especifica si la entrada debe suministrarse. ## `on.workflow_dispatch.inputs..type` El valor de este parámetro es una secuencia que especifica el tipo de datos de la entrada. Debe ser uno de los siguientes: `boolean`, `choice`, `number`, `environment` o `string`. ## `permissions` Puede usar `permissions` para modificar los permisos predeterminados concedidos a `GITHUB_TOKEN` si se agrega o elimina el acceso según sea necesario, de forma que solo se permita el acceso mínimo necesario. Para más información, consulta [Uso de GITHUB\_TOKEN para la autenticación en flujos de trabajo](/es/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token). Puede utilizar `permissions` ya sea como una clave de nivel superior, para aplicarlos a todos los trabajos en el flujo de trabajo, o en los trabajos específicos. Cuando agrega la clave `permissions` en un trabajo específico, todas las acciones y comandos de ejecución dentro de este que utilicen `GITHUB_TOKEN` obtendrán los derechos de acceso que especifique. Para obtener más información, vea [`jobs..permissions`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions). Los propietarios de una organización pueden restringir el acceso de escritura para `GITHUB_TOKEN` en el nivel de repositorio. Para obtener más información, consulta [Deshabilitación o limitación de Acciones de GitHub para su organización](/es/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization). Cuando el evento [`pull_request_target`](/es/actions/using-workflows/events-that-trigger-workflows#pull_request_target) desencadena un flujo de trabajo, se concede a `GITHUB_TOKEN` permiso de repositorio de lectura y escritura, incluso cuando se desencadena desde una bifurcación pública. Para más información, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/using-workflows/events-that-trigger-workflows#pull_request_target). En cada uno de los permisos disponibles, que se muestran en la tabla siguiente, puedes asignar uno de los niveles de acceso: `read` (si corresponde), `write` o `none`. `write` incluye `read`. Si especifica el acceso para cualquiera de estos permisos, todos los que no se especifiquen se establecen en `none`. Los permisos y detalles disponibles de lo que cada uno permite que una acción haga: | Permiso | Permite una acción con `GITHUB_TOKEN` | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | Trabajar con Acciones de GitHub. Por ejemplo, `actions: write` permite que una acción cancele la ejecución de un flujo de trabajo. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). | | | | | `artifact-metadata` | Trabajar con metadatos de artefactos. Por ejemplo, `artifact-metadata: write` permite que una acción cree registros de almacenamiento para un artefacto de construcción. Para más información, consulta [Puntos de conexión de api REST para metadatos de artefacto](/es/rest/orgs/artifact-metadata?apiVersion=2022-11-28). | | | | | | | | `attestations` | Trabajar con atestaciones de artefactos. Por ejemplo, `attestations: write` permite que una acción genere una certificación de artefacto para una compilación. Para obtener más información, consulta [Uso de atestaciones de artefactos para establecer la procedencia de las compilaciones](/es/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds). | | | | | `checks` | Trabajar con ejecuciones de comprobación y conjuntos de comprobación. Por ejemplo, `checks: write` permite que una acción cree un ciclo de comprobación. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). | | | | | `code-quality` | Trabajar con calidad de código. Por ejemplo, `code-quality: write` permite que una acción cargue informes de cobertura de código. Para más información, consulta [Acerca de la calidad del código de GitHub](/es/code-security/concepts/about-code-quality). | | | | | `contents` | Trabajar con los contenidos del repositorio. Por ejemplo, `contents: read` permite que una acción enumere las confirmaciones, mientras que `contents: write` permita que la acción cree una versión. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). | | `deployments` | Trabajar con implementaciones. Por ejemplo, `deployments: write` permite que una acción cree una implementación. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). | | `discussions` | Trabajar con las discusiones de GitHub. Por ejemplo, `discussions: write` permite que una acción cierre o elimine una discusión. Para más información, consulta [Utilizar la API de GraphQL para los debates](/es/graphql/guides/using-the-graphql-api-for-discussions). | | | | | `id-token` | Capture un token de OpenID Connect (OIDC). Esto requiere el valor `id-token: write`. Para obtener más información, consulta [OpenID Connect](/es/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc). | | | | | `issues` | Resolver problemas. Por ejemplo, `issues: write` permite que una acción agregue un comentario a un problema. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). | | | | | `models` | Genere respuestas de inferencia de IA con GitHub Models. Por ejemplo, `models: read` permite que una acción use la GitHub Models API de inferencia. Consulta [Creación de prototipos con modelos de IA](/es/github-models/prototyping-with-ai-models). | | | | | `packages` | Trabajar con paquetes de GitHub. Por ejemplo, `packages: write` permite que una acción cargue y publique paquetes en GitHub Packages. Para más información, consulta [Acerca de los permisos para los Paquetes de GitHub](/es/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). | | `pages` | Trabajar con GitHub Pages. Por ejemplo, `pages: write` permite que una acción solicite una compilación de GitHub Pages. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). | | `pull-requests` | Trabajar con solicitudes de incorporación de cambios. Por ejemplo, `pull-requests: write` permite que una acción agregue una etiqueta a una solicitud de incorporación de cambios. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). | | `security-events` | Trabaja con alertas de escaneo de código de GitHub. Por ejemplo, `security-events: read` permite que una acción enumere las alertas de escaneo de código para el repositorio, mientras que `security-events: write` permite que una acción actualice el estado de una alerta de escaneo de código. Para obtener más información, consulte [Permisos de repositorio para "Alertas de análisis de código".](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

| | Para las alertas de Dependabot, utilice el `vulnerability-alerts` permiso. Las alertas de escaneo de secretos no se pueden leer con este permiso y requieren una aplicación de GitHub o un personal access token. Para obtener más información, consulte [Permisos de repositorio para "Alertas de examen de secretos"](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) en "Permisos necesarios para aplicaciones de GitHub". | | | `statuses` | Trabajar con estados de confirmación. Por ejemplo, `statuses:read` permite que una acción enumere los estados de confirmación de una referencia determinada. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). | | | | | `vulnerability-alerts` | Lea Las alertas de Dependabot. Por ejemplo, `vulnerability-alerts: read` permite que una acción enumere las alertas de Dependabot para el repositorio. Solo `read` y `none` son compatibles; `write` no es válido. Cuando `write-all` se usa o `read-all` , `vulnerability-alerts` se incluye automáticamente como `read`. Para obtener más información, consulte [Permisos de repositorio para "Alertas de Dependabot".](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) | | | | ### Definición del acceso para los ámbitos de `GITHUB_TOKEN` Para definir el acceso que `GITHUB_TOKEN` permitirá, especifica `read`, `write` o `none` como valor de los permisos disponibles en la clave `permissions`. ```yaml permissions: actions: read|write|none artifact-metadata: read|write|none attestations: read|write|none checks: read|write|none code-quality: read|write|none contents: read|write|none deployments: read|write|none id-token: write|none issues: read|write|none models: read|none discussions: read|write|none packages: read|write|none pages: read|write|none pull-requests: read|write|none security-events: read|write|none statuses: read|write|none vulnerability-alerts: read|none ``` Si especifica el acceso para cualquiera de estos permisos, todos los que no se especifiquen se establecen en `none`. Puedes utilizar la siguiente sintaxis para definir un acceso `read-all` o `write-all` para todos los permisos disponibles: ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` Puedes utilizar la siguiente sintaxis para inhabilitar los permisos para todos los permisos disponibles: ```yaml permissions: {} ``` #### Cambio de los permisos en un repositorio bifurcado Puede usar la clave `permissions` a fin de agregar y quitar permisos de lectura para repositorios bifurcados, pero normalmente no se puede conceder acceso de escritura. La excepción a este comportamiento es cuando un usuario administrador ha seleccionado la opción **Enviar tokens a flujos de trabajo desde solicitudes de incorporación de cambios** en la configuración de GitHub Actions. Para más información, consulta [Administración de la configuración de GitHub Actions para un repositorio](/es/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks). ## Cómo se calculan los permisos para una tarea de flujo de trabajo Los permisos para `GITHUB_TOKEN` se establecen inicialmente con los valores predeterminados para la empresa, organización o repositorio. Si lo predeterminado se configura para los permisos restringidos en cualquiera de estos niveles, esto aplicará a los repositorios relevantes. Por ejemplo, si eliges las restricciones predeterminadas a nivel organizacional, entonces todos los repositorios de la organización utilizarán estos permisos restringidos como los predeterminados. Entonces, los permisos se ajustarán basándose en cualquier configuración dentro del archivo de flujo de trabajo, primero a nivel de flujo de trabajo y luego a nivel de las tareas. Por último, si el flujo de trabajo se ha activado por un evento de solicitud de extracción distinto de `pull_request_target` procedente de un repositorio bifurcado, y la configuración **Enviar tokens de escritura a flujos de trabajo desde solicitudes de extracción** no está seleccionada, los permisos se ajustan para cambiar cualquier permiso de escritura a solo lectura. ### Configuración de los permisos de `GITHUB_TOKEN` para todas las tareas de un flujo de trabajo Puede especificar `permissions` en el nivel superior de un flujo de trabajo para que el valor se aplique a todos los trabajos del flujo de trabajo. #### Ejemplo: establecimiento de los permisos de `GITHUB_TOKEN` para un flujo de trabajo completo En este ejemplo se muestran los permisos que se están configurando para `GITHUB_TOKEN` que aplicará a todos los trabajos en el flujo de trabajo. Se otorga acceso de lectura a todos los permisos. ```yaml name: "My workflow" on: [ push ] permissions: read-all jobs: ... ``` ### Uso de la clave `permissions` para repositorios bifurcados Puedes usar la clave `permissions` a fin de agregar y quitar permisos `read` para repositorios bifurcados, pero normalmente no puedes conceder acceso `write`. La excepción a este comportamiento se da cuando un usuario administrador ha seleccionado la opción **Enviar tokens de escritura a flujos de trabajo desde solicitudes de extracción** en la configuración GitHub Actions. Para más información, consulta [Administración de la configuración de GitHub Actions para un repositorio](/es/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks). ### Permisos para ejecuciones de flujo de trabajo desencadenadas por Dependabot Las ejecuciones de flujos de trabajo que las solicitudes de incorporación de cambios de Dependabot desencadenan se ejecutan como si fueran de un repositorio bifurcado y, por lo tanto, usan un elemento `GITHUB_TOKEN` de solo lectura. Estas ejecuciones de flujo de trabajo no pueden acceder a ningún secreto. Para obtener información sobre las estrategias para mantener estos flujos de trabajo seguros, consulta [Referencia de uso seguro](/es/actions/security-guides/security-hardening-for-github-actions). ## `env` Objeto `map` de variables de entorno disponibles para los pasos de todos los trabajos del flujo de trabajo. También puedes configurar variables que solo estén disponibles para los pasos de un único trabajo o para un solo paso en particular. Para más información, vea [`jobs..env`](#jobsjob_idenv) y [`jobs..steps[*].env`](#jobsjob_idstepsenv). Las variables del mapa `env` no se pueden definir en relación a otras variables del mapa. Cuando se define más de una variable de entorno con el mismo nombre, GitHub utiliza la más específica. Por ejemplo, una variable de entorno definida en un paso anulará aquellas variables de entorno de los trabajos y flujos de trabajo con el mismo nombre, mientras ejecuta el paso. Una variable de entorno definida para un trabajo anulará aquella de un flujo de trabajo si tienen el mismo nombre, mientras se ejecuta el trabajo. ### Ejemplo de `env` ```yaml env: SERVER: production ``` ## `defaults` Use `defaults` para crear un `map` de configuración predeterminada que se aplicará a todos los trabajos en el flujo de trabajo. También puedes configurar los ajustes predeterminados que solo estén disponibles para un job. Para obtener más información, vea [`jobs..defaults`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaults). Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ## `defaults.run` Puedes usar `defaults.run` para proporcionar las opciones `shell` y `working-directory` predeterminadas para todos los pasos de [`run`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) de un flujo de trabajo. También puedes establecer opciones predeterminadas para `run` que solo están disponibles para un trabajo. Para más información, vea [`jobs..defaults.run`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun). No puedes utilizar contextos o expresiones en esta palabra clave. Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ### Ejemplo: Configurar el directorio de trabajo y shell predeterminados ```yaml defaults: run: shell: bash working-directory: ./scripts ``` ## `defaults.run.shell` Usa `shell` para definir `shell` para un paso. Esta palabra clave puede hacer referencia a varios contextos. Para más información, consulta [Contextos](/es/actions/learn-github-actions/contexts#context-availability). | Plataforma compatible | Parámetro `shell` | Descripción | Comando ejecutado interamente | | --------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- | | Linux/macOS | unspecified | El shell predeterminado en plataformas que no son de Windows. Ten en cuenta que esto ejecuta un comando diferente a cuando `bash` se especifica explícitamente. Si `bash` no se encuentra en la ruta de acceso, se trata como `sh`. | `bash -e {0}` | | Todo | `bash` | El shell predeterminado en plataformas que no son de Windows con una reserva en `sh`. Al especificar un bash shell en Windows, se usa el bash shell incluido con Git para Windows. | `bash --noprofile --norc -eo pipefail {0}` | | Todo | `pwsh` | Powershell Core. GitHub agrega la extensión `.ps1` al nombre del script. | `pwsh -command ". '{0}'"` | | Todo | `python` | Ejecuta el comando python. | `python {0}` | | Linux/macOS | `sh` | El comportamiento de reserva para plataformas que no son Windows si no se proporciona un shell y `bash` no se encuentra en la ruta. | `sh -e {0}` | | Windows | `cmd` | GitHub agrega la extensión `.cmd` al nombre del script y lo sustituye por `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Este es el shell predeterminado que se usa en Windows. Powershell Core. GitHub agrega la extensión `.ps1` al nombre del script. Si el ejecutor autohospedado de Windows no tiene *PowerShell Core* instalado, en su lugar se usa *PowerShell Desktop*. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | El PowerShell Desktop. GitHub agrega la extensión `.ps1` al nombre del script. | `powershell -command ". '{0}'"`. | Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ## `defaults.run.working-directory` Usa `working-directory` para definir el directorio de trabajo para `shell` para un paso. Esta palabra clave puede hacer referencia a varios contextos. Para más información, consulta [Contextos](/es/actions/learn-github-actions/contexts#context-availability). > \[!TIP] > Asegúrate de que la asignación de `working-directory` exista en el ejecutor antes de ejecutar el shell en él. > Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ## `concurrency` Utilice `concurrency` para asegurarse de que solo se ejecute al mismo tiempo un trabajo o flujo de trabajo que use el mismo grupo de concurrencia. Un grupo de concurrencia puede ser cualquier secuencia o expresión. La expresión solo puede usar el contextos [`github`](/es/actions/learn-github-actions/contexts#github-context), [`inputs`](/es/actions/learn-github-actions/contexts#inputs-context) y [`vars`](/es/actions/learn-github-actions/contexts#vars-context). Para más información sobre las expresiones, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions). También puede especificar `concurrency` en el nivel de trabajo. Para más información, vea [`jobs..concurrency`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency). Esto significa que en cualquier momento puede haber como máximo un trabajo o flujo de trabajo en ejecución en un grupo de concurrencia. Cuando un trabajo o flujo de trabajo concurrente se pone en cola, si otro trabajo o flujo de trabajo que utilicen el mismo grupo de simultaneidad en el repositorio se encuentra en curso, el trabajo o flujo de trabajo en cola se mostrará como `pending`. De forma predeterminada, cualquier trabajo o flujo de trabajo `pending` existente en el mismo grupo de simultaneidad se cancelará y el nuevo trabajo o flujo de trabajo en cola ocupará su lugar. Para cancelar también cualquier trabajo o flujo de trabajo actualmente en ejecución en el mismo grupo de simultaneidad, especifica `cancel-in-progress: true`. Para cancelar condicionalmente los trabajos o flujos de trabajo en ejecución actualmente en el mismo grupo de simultaneidad, puede especificar `cancel-in-progress` como una expresión con cualquiera de los contextos de expresión permitidos. Para permitir que más de un `pending` trabajo o ejecución de flujo de trabajo esperen en el mismo grupo de simultaneidad, use la propiedad opcional `queue`. La `queue` propiedad acepta los siguientes valores: * `single` (valor predeterminado): Como máximo, una tarea o ejecución de flujo de trabajo puede estar `pending` en el grupo de concurrencia. Cuando se pone en cola un nuevo trabajo o ejecución de flujo de trabajo, se cancela y reemplaza cualquier trabajo o flujo de trabajo existente `pending` que se ejecute en el mismo grupo. * `max`: hasta 100 trabajos o tareas de flujo de trabajo pueden incluirse en el grupo de concurrencia. Cuando la cola está llena, se cancelan los trabajos o ejecuciones de flujo de trabajo adicionales. La combinación de `queue: max` y `cancel-in-progress: true` no está permitida y producirá un error de validación de flujo de trabajo. > \[!NOTE] > > * El nombre de grupo de simultaneidad no distingue mayúsculas de minúsculas. Por ejemplo, `prod` y `Prod` se tratarán como el mismo grupo de simultaneidad. > * Los trabajos o ejecuciones de flujo de trabajo en el mismo grupo de concurrencia se procesan en el orden primero en entrar, primero en salir (FIFO) según el momento en que cada uno comenzó a esperar en el grupo de concurrencia, no en el momento en que se envió cada flujo de trabajo. Dado que la hora de inicio real de un trabajo o ejecución puede variar, no se garantiza la ordenación. ### Ejemplos: Utilizar la simultaneidad y el comportamiento predeterminado El comportamiento predeterminado de GitHub Actions es permitir que varios trabajos o ejecuciones de flujos de trabajo se ejecuten al mismo tiempo. La `concurrency` palabra clave permite controlar la simultaneidad de las ejecuciones de flujo de trabajo. Por ejemplo, puedes usar la `concurrency` palabra clave inmediatamente después de donde se definen las condiciones del gatillo para limitar la simultaneidad de ejecuciones de flujo de trabajo completas para una rama específica: ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` También puede limitar la simultaneidad de los trabajos dentro de un flujo de trabajo usando la `concurrency` palabra clave en el nivel de trabajo: ```yaml on: push: branches: - main jobs: job-1: runs-on: ubuntu-latest concurrency: group: example-group cancel-in-progress: true ``` ### Ejemplo: Grupos de concurrencia Los grupos de simultaneidad proporcionan un método para administrar y limitar las ejecuciones de flujos de trabajo o trabajos que comparten la misma clave de simultaneidad. La `concurrency` tecla se usa para agrupar flujos de trabajo o trabajos en un grupo de concurrencia. Al definir una `concurrency` clave, GitHub Actions garantiza que solo se ejecute un flujo de trabajo o trabajo con esa clave en un momento dado. Si una nueva ejecución de flujo de trabajo o trabajo comienza con la misma `concurrency` clave, GitHub Actions cancelará cualquier flujo de trabajo o trabajo que ya se ejecute con esa clave. La `concurrency` clave puede ser una cadena codificada de forma rígida o puede ser una expresión dinámica que incluya variables de contexto. Es posible definir condiciones de simultaneidad en el flujo de trabajo para que el flujo de trabajo o el trabajo formen parte de un grupo de simultaneidad. Esto significa que cuando se inicia una ejecución o un trabajo, GitHub cancelará las ejecuciones o trabajos que ya estén en curso en el mismo grupo de concurrencia. Esto resulta útil en escenarios en los que desea evitar ejecuciones paralelas para un determinado conjunto de flujos de trabajo o trabajos, como los que se usan para las implementaciones en un entorno de ensayo, con el fin de evitar acciones que puedan provocar conflictos o consumir más recursos de los necesarios. En este ejemplo, `job-1` forma parte de un grupo de simultaneidad denominado `staging_environment`. Esto significa que si se desencadena una nueva ejecución de `job-1`, se cancelarán las ejecuciones del mismo trabajo en el grupo de simultaneidad `staging_environment` que ya están en curso. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` Alternativamente, el uso de una expresión dinámica como `concurrency: ci-${{ github.ref }}` en el flujo de trabajo significa que el flujo de trabajo o el trabajo formarían parte de un grupo de simultaneidad denominado `ci-` seguido de la referencia de la rama o etiqueta que desencadenó el flujo de trabajo. En este ejemplo, si se inserta un nuevo compromiso en la rama principal mientras una ejecución anterior sigue en curso, se cancelará la ejecución anterior y se iniciará la nueva: ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Ejemplo: Poner en cola varias ejecuciones pendientes De forma predeterminada, solo un trabajo o ejecución de flujo de trabajo puede estar `pending` en un grupo de concurrencia a la vez. Para permitir que varias ejecuciones se pongan en cola en lugar de cancelarse, establezca `queue: max`. Con `queue: max`, hasta 100 trabajos o ejecuciones de flujo de trabajo pueden esperar en el grupo de simultaneidad; cuando la cola está llena, se cancelan las ejecuciones adicionales. Por ejemplo, el siguiente flujo de trabajo encola las implementaciones en el entorno `production`, procesándolas una a una en orden, según el momento en que cada ejecución comenzó a esperar en el grupo de concurrencia. ```yaml on: push: branches: - main concurrency: group: production-deploy queue: max ``` Tenga en cuenta que `queue: max` no se puede combinar con `cancel-in-progress: true`, porque las dos opciones describen comportamientos conflictivos para manejar las ejecuciones en curso. ### Ejemplo: Utilizar la concurrencia para cancelar cualquier tarea o ejecución en curso Para usar la concurrencia para cancelar cualquier trabajo en curso o ejecución en GitHub Actions, puede usar la clave `concurrency` con la opción `cancel-in-progress` establecida en `true`. ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Tenga en cuenta que en este ejemplo, sin definir un grupo de simultaneidad determinado, GitHub Actions cancelará *cualquier* ejecución en curso del trabajo o flujo de trabajo. ### Ejemplo: Utilizar un valor de respaldo Si compilas el nombre de grupo con una propiedad que solo se defina para eventos específicos, puedes utilizar un valor de segunda opción. Por ejemplo, `github.head_ref` solo se define en eventos `pull_request`. Si tu flujo de trabajo responde a otros eventos además de los eventos `pull_request`, necesitarás proporcionar una segunda opción para evitar un error de sintaxis. El siguiente grupo de simultaneidad cancela los trabajos en curso o solo se ejecuta en eventos `pull_request`; si `github.head_ref` no está definido, el grupo de simultaneidad revertirá al identificador de ejecución, que se garantiza que es único y definido para la ejecución. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Ejemplo: Cancelar únicamente las tareas o ejecuciones en curso para el flujo de trabajo actual Si tienes múltiples flujos de trabajo en el mismo repositorio, los nombres de los grupos de concurrencia deben ser únicos en todos los flujos de trabajo para evitar que se cancelen tareas o ejecuciones en progreso de otros flujos de trabajo. De lo contrario, cualquier tarea pendiente o previamente en curso se cancelará, sin importar el flujo de trabajo. Para cancelar solo las ejecuciones en curso del mismo flujo de trabajo, puedes usar la propiedad `github.workflow` para compilar el grupo de simultaneidad: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### Ejemplo: Cancelar solo trabajos en curso en ramas específicas Si desea cancelar trabajos en curso en determinadas ramas, pero no en otras, puede usar expresiones condicionales con `cancel-in-progress`. Por ejemplo, puede hacerlo si desea cancelar trabajos en curso en ramas de desarrollo, pero no en ramas de lanzamiento. Para cancelar solo las ejecuciones en curso del mismo flujo de trabajo cuando no se ejecutan en una rama de versión, puede establecer en `cancel-in-progress` una expresión similar a la siguiente: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` En este ejemplo, hacer múltiples push en una rama `release/1.2.3` no cancelaría las ejecuciones en curso. Las inserciones a otra rama, como `main`, cancelarían las ejecuciones en curso. ## `jobs` Una ejecución de flujo de trabajo se compone de uno o varios `jobs`, que se ejecutan en paralelo de forma predeterminada. Para ejecutar trabajos de manera secuencial, puede definir dependencias en otros trabajos mediante la palabra clave `jobs..needs`. Cada trabajo se ejecuta en un entorno de ejecutor especificado por `runs-on`. Puedes ejecutar una cantidad ilimitada de trabajos siempre que estés dentro de los límites de uso del flujo de trabajo. Consulta [Facturación y utilización](/es/actions/learn-github-actions/usage-limits-billing-and-administration) para información sobre los límites de uso de los ejecutores hospedados en GitHub y [Límites de acciones](/es/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) para información sobre los límites de uso de los ejecutores autohospedados. Si necesitas encontrar el identificador único de un trabajo que se ejecuta en una ejecución de flujo de trabajo, puedes usar la API GitHub. Para más información, consulta [Puntos de conexión de api REST para Acciones de GitHub](/es/rest/actions#workflow-jobs). ## `jobs.` Usa `jobs.` para asignar un identificador único al trabajo. La clave `job_id` es una cadena y su valor es un mapa de los datos de configuración del trabajo. Debes reemplazar `` por una cadena que sea única para el objeto `jobs`. `` debe empezar con una letra o `_`, y solo puede contener caracteres alfanuméricos, `-` o `_`. ### Ejemplo: Crear jobs En este ejemplo, se han creado dos trabajos y sus valores `job_id` son `my_first_job` y `my_second_job`. ```yaml jobs: my_first_job: name: My first job my_second_job: name: My second job ``` ## `jobs..name` Usa `jobs..name` a fin de establecer un nombre para el trabajo, que se muestra en la UI de GitHub. ## `jobs..permissions` Para un trabajo concreto, puede usar `jobs..permissions` para modificar los permisos predeterminados concedidos a `GITHUB_TOKEN` si se agrega o elimina el acceso según sea necesario, de forma que solo se permita el acceso mínimo necesario. Para más información, consulta [Uso de GITHUB\_TOKEN para la autenticación en flujos de trabajo](/es/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token). Al especificar el permiso dentro de una definición de trabajo, puede configurar un conjunto diferente de permisos para el `GITHUB_TOKEN` de cada trabajo, si es necesario. Como alternativa, puedes especificar los permisos para todos los jobs en el flujo de trabajo. Para obtener información sobre cómo definir permisos en el nivel de flujo de trabajo, vea [`permissions`](/es/actions/using-workflows/workflow-syntax-for-github-actions#permissions). En cada uno de los permisos disponibles, que se muestran en la tabla siguiente, puedes asignar uno de los niveles de acceso: `read` (si corresponde), `write` o `none`. `write` incluye `read`. Si especifica el acceso para cualquiera de estos permisos, todos los que no se especifiquen se establecen en `none`. Los permisos y detalles disponibles de lo que cada uno permite que una acción haga: | Permiso | Permite una acción con `GITHUB_TOKEN` | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | Trabajar con Acciones de GitHub. Por ejemplo, `actions: write` permite que una acción cancele la ejecución de un flujo de trabajo. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). | | | | | `artifact-metadata` | Trabajar con metadatos de artefactos. Por ejemplo, `artifact-metadata: write` permite que una acción cree registros de almacenamiento para un artefacto de construcción. Para más información, consulta [Puntos de conexión de api REST para metadatos de artefacto](/es/rest/orgs/artifact-metadata?apiVersion=2022-11-28). | | | | | | | | `attestations` | Trabajar con atestaciones de artefactos. Por ejemplo, `attestations: write` permite que una acción genere una certificación de artefacto para una compilación. Para obtener más información, consulta [Uso de atestaciones de artefactos para establecer la procedencia de las compilaciones](/es/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds). | | | | | `checks` | Trabajar con ejecuciones de comprobación y conjuntos de comprobación. Por ejemplo, `checks: write` permite que una acción cree un ciclo de comprobación. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). | | | | | `code-quality` | Trabajar con calidad de código. Por ejemplo, `code-quality: write` permite que una acción cargue informes de cobertura de código. Para más información, consulta [Acerca de la calidad del código de GitHub](/es/code-security/concepts/about-code-quality). | | | | | `contents` | Trabajar con los contenidos del repositorio. Por ejemplo, `contents: read` permite que una acción enumere las confirmaciones, mientras que `contents: write` permita que la acción cree una versión. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). | | `deployments` | Trabajar con implementaciones. Por ejemplo, `deployments: write` permite que una acción cree una implementación. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). | | `discussions` | Trabajar con las discusiones de GitHub. Por ejemplo, `discussions: write` permite que una acción cierre o elimine una discusión. Para más información, consulta [Utilizar la API de GraphQL para los debates](/es/graphql/guides/using-the-graphql-api-for-discussions). | | | | | `id-token` | Capture un token de OpenID Connect (OIDC). Esto requiere el valor `id-token: write`. Para obtener más información, consulta [OpenID Connect](/es/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc). | | | | | `issues` | Resolver problemas. Por ejemplo, `issues: write` permite que una acción agregue un comentario a un problema. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). | | | | | `models` | Genere respuestas de inferencia de IA con GitHub Models. Por ejemplo, `models: read` permite que una acción use la GitHub Models API de inferencia. Consulta [Creación de prototipos con modelos de IA](/es/github-models/prototyping-with-ai-models). | | | | | `packages` | Trabajar con paquetes de GitHub. Por ejemplo, `packages: write` permite que una acción cargue y publique paquetes en GitHub Packages. Para más información, consulta [Acerca de los permisos para los Paquetes de GitHub](/es/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). | | `pages` | Trabajar con GitHub Pages. Por ejemplo, `pages: write` permite que una acción solicite una compilación de GitHub Pages. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). | | `pull-requests` | Trabajar con solicitudes de incorporación de cambios. Por ejemplo, `pull-requests: write` permite que una acción agregue una etiqueta a una solicitud de incorporación de cambios. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). | | `security-events` | Trabaja con alertas de escaneo de código de GitHub. Por ejemplo, `security-events: read` permite que una acción enumere las alertas de escaneo de código para el repositorio, mientras que `security-events: write` permite que una acción actualice el estado de una alerta de escaneo de código. Para obtener más información, consulte [Permisos de repositorio para "Alertas de análisis de código".](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

| | Para las alertas de Dependabot, utilice el `vulnerability-alerts` permiso. Las alertas de escaneo de secretos no se pueden leer con este permiso y requieren una aplicación de GitHub o un personal access token. Para obtener más información, consulte [Permisos de repositorio para "Alertas de examen de secretos"](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) en "Permisos necesarios para aplicaciones de GitHub". | | | `statuses` | Trabajar con estados de confirmación. Por ejemplo, `statuses:read` permite que una acción enumere los estados de confirmación de una referencia determinada. Para más información, consulta [Permisos necesarios para aplicaciones de GitHub](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). | | | | | `vulnerability-alerts` | Lea Las alertas de Dependabot. Por ejemplo, `vulnerability-alerts: read` permite que una acción enumere las alertas de Dependabot para el repositorio. Solo `read` y `none` son compatibles; `write` no es válido. Cuando `write-all` se usa o `read-all` , `vulnerability-alerts` se incluye automáticamente como `read`. Para obtener más información, consulte [Permisos de repositorio para "Alertas de Dependabot".](/es/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) | | | | ### Definición del acceso para los ámbitos de `GITHUB_TOKEN` Para definir el acceso que `GITHUB_TOKEN` permitirá, especifica `read`, `write` o `none` como valor de los permisos disponibles en la clave `permissions`. ```yaml permissions: actions: read|write|none artifact-metadata: read|write|none attestations: read|write|none checks: read|write|none code-quality: read|write|none contents: read|write|none deployments: read|write|none id-token: write|none issues: read|write|none models: read|none discussions: read|write|none packages: read|write|none pages: read|write|none pull-requests: read|write|none security-events: read|write|none statuses: read|write|none vulnerability-alerts: read|none ``` Si especifica el acceso para cualquiera de estos permisos, todos los que no se especifiquen se establecen en `none`. Puedes utilizar la siguiente sintaxis para definir un acceso `read-all` o `write-all` para todos los permisos disponibles: ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` Puedes utilizar la siguiente sintaxis para inhabilitar los permisos para todos los permisos disponibles: ```yaml permissions: {} ``` #### Cambio de los permisos en un repositorio bifurcado Puede usar la clave `permissions` a fin de agregar y quitar permisos de lectura para repositorios bifurcados, pero normalmente no se puede conceder acceso de escritura. La excepción a este comportamiento es cuando un usuario administrador ha seleccionado la opción **Enviar tokens a flujos de trabajo desde solicitudes de incorporación de cambios** en la configuración de GitHub Actions. Para más información, consulta [Administración de la configuración de GitHub Actions para un repositorio](/es/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks). #### Ejemplo: configuración de los permisos de `GITHUB_TOKEN` para una tarea en un flujo de trabajo En este ejemplo se muestran los permisos establecidos para `GITHUB_TOKEN` que solo se aplicarán al trabajo denominado `stale`. Se concede acceso de escritura a los permisos `issues` y `pull-requests`. Todos los demás permisos no tendrán acceso. ```yaml jobs: stale: runs-on: ubuntu-latest permissions: issues: write pull-requests: write steps: - uses: actions/stale@v10 ``` ## `jobs..needs` Use `jobs..needs` para identificar los trabajos que se deben completar correctamente antes de que se ejecute este trabajo. Puede ser una cadena o matriz de cadenas. Si se omite un trabajo o este presenta un error, se omitirán todos los trabajos, a menos que utilicen una expresión condicional que haga que el trabajo continúe. Si una ejecución contiene una serie de trabajos que se necesitan entre sí, se produce un error en todos los trabajos de la cadena de dependencias o se omiten desde el punto de error en adelante. Si deseas que un trabajo se ejecute incluso si el trabajo del que depende no se realizó correctamente, usa la expresión condicional `always()` en `jobs..if`. ### Ejemplo: Requerir jobs dependientes exitosos ```yaml jobs: job1: job2: needs: job1 job3: needs: [job1, job2] ``` En este ejemplo, `job1` se debe completar correctamente antes de que comience `job2` y `job3` espera a que se completen `job1` y `job2`. En este ejemplo, los trabajos se ejecutan de manera secuencial: 1. `job1` 2. `job2` 3. `job3` ### Ejemplo: No requerir jobs dependientes exitosos ```yaml jobs: job1: job2: needs: job1 job3: if: ${{ always() }} needs: [job1, job2] ``` En este ejemplo, `job3` usa la expresión condicional `always()` para que siempre se ejecute después de que se hayan completado `job1` y `job2`, independientemente de si se han realizado correctamente. Para más información, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions#status-check-functions). ## `jobs..if` Puede usar el condicional `jobs..if` para impedir que se ejecute una tarea si no se cumple una condición. Puedes usar cualquier contexto y expresión admitidos para crear un condicional. Para más información sobre los contextos que se admiten en esta clave, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts#context-availability). > \[!NOTE] > La condición `jobs..if` se evalúa antes de aplicar [`jobs..strategy.matrix`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix). Cuando se usan expresiones en un condicional `if`, se puede omitir la sintaxis de la expresión `${{ }}` opcionalmente, porque GitHub Actions evalúa automáticamente el condicional `if` como una expresión. Sin embargo, esta excepción no se aplica en todas partes. Debe usar siempre la sintaxis de expresión `${{ }}` o escapar con `''`, `""`o `()` cuando la expresión comienza con `!`, ya que `!` es una notación reservada en formato YAML. Por ejemplo: ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` Para más información, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions). ### Ejemplo: Solo ejecutar un job para un repositorio específico En este ejemplo se usa `if` para controlar cuándo se puede ejecutar el trabajo `production-deploy`. Solo se ejecutará si el repositorio se denomina `octo-repo-prod` y está dentro de la organización `octo-org`. De lo contrario, el trabajo se marcará como *omitido*. ```yaml copy name: example-workflow on: [push] jobs: production-deploy: if: github.repository == 'octo-org/octo-repo-prod' runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats ``` ## `jobs..runs-on` Use `jobs..runs-on` para definir el tipo de máquina en la que se ejecutará el trabajo. * La máquina de destino puede ser ya sea un [GitHubrunner hospedado](#choosing-github-hosted-runners), [ejecutor más grande](#choosing-runners-in-a-group), o un [runner autohospedado](#choosing-self-hosted-runners). * Puedes seleccionar los ejecutores en función de las etiquetas que tengan asignadas, del grupo al que pertenezcan o de una combinación de ambos criterios. * Puedes proporcionar `runs-on` como: * Una sola cadena * Una sola variable que contiene una cadena. * Una matriz de cadenas, variables que contienen cadenas o una combinación de ambas. * Un par `key: value` que usa las claves `group` o `labels`. * Si especificas una matriz de cadenas o variables, el flujo de trabajo se ejecutará en cualquier ejecutor que coincida con todos los valores `runs-on` especificados. Por ejemplo, aquí el trabajo solo se ejecutará en un ejecutor autohospedado que tenga las etiquetas `linux`, `x64` y `gpu`: ```yaml runs-on: [self-hosted, linux, x64, gpu] ``` Para más información, consulta [Elegir ejecutores autoalojados](#choosing-self-hosted-runners). * Puedes combinar cadenas y variables en una matriz. Por ejemplo: ```yaml on: workflow_dispatch: inputs: chosen-os: required: true type: choice options: - Ubuntu - macOS jobs: test: runs-on: [self-hosted, "${{ inputs.chosen-os }}"] steps: - run: echo Hello world! ``` * Si quiere ejecutar el flujo de trabajo en varias máquinas, use [`jobs..strategy`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy). > \[!NOTE] > Las comillas no son necesarias en torno a cadenas simples como `self-hosted`, pero son necesarias para expresiones como `"${{ inputs.chosen-os }}"`. ### Selección de ejecutores alojados GitHub Si usa un ejecutor hospedado en GitHub, cada trabajo se ejecuta en una nueva instancia de la imagen del ejecutor especificada por `runs-on`. El valor de runs-on, cuando se utiliza un ejecutor hospedado en GitHub, es una etiqueta del flujo de trabajo o el nombre de un grupo de ejecutores. Las etiquetas de los runners estándar alojados en GitHub se muestran en las siguientes tablas. Para más información, consulta [Ejecutores hospedados en GitHub](/es/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners). ### Ejecutores estándar hospedados GitHub para repositorios públicos En el caso de los repositorios públicos, los trabajos que usan las etiquetas de flujo de trabajo que se muestran en la tabla siguiente se ejecutarán con las especificaciones asociadas. A excepción de los ejecutores de CPU única, cada GitHubejecutor hospedado por }es una nueva máquina virtual hospedada por GitHub. Runners de CPU única se ejecutan en un contenedor en una VM compartida; consulte [Referencia de ejecutores hospedados en GitHub](/es/actions/reference/runners/github-hosted-runners#single-cpu-runners). El uso de los ejecutores hospedados estándar GitHubes gratuito y ilimitado en repositorios públicos. ```
Máquina virtual o contenedor Procesador (CPU) Memoria (RAM) Almacenamiento (SSD) Arquitectura Etiqueta de flujo de trabajo
Linux 1 5 GB 14 GB x64 ubuntu-slim
Linux 4 16 GB 14 GB x64 ``` ubuntu-latest, ubuntu-24.04, ubuntu-22.04, ubuntu-26.04 (Versión preliminar pública)
Windows 4 16 GB 14 GB x64 windows-latest, windows-2025, , windows-2025-vs2026, windows-2022
Linux 4 16 GB 14 GB ARM64 ubuntu-24.04-arm, ubuntu-22.04-arm, ubuntu-26.04-arm (Versión preliminar pública)
Windows 4 16 GB 14 GB ARM64 windows-11-arm, windows-11-vs2026-arm (Versión preliminar pública)
macOS 4 14 GB 14 GB Intel macos-15-intel, macos-26-intel
macOS 3 (M1) 7 GB 14 GB ARM64 macos-latest, macos-14, , macos-15, macos-26
### GitHubEjecutores hospedados estándar para privados En privados, los trabajos que usan las etiquetas de flujo de trabajo que se muestran en la tabla siguiente se ejecutarán en máquinas virtuales con las especificaciones asociadas. Estos ejecutores utilizan la asignación de minutos gratuitos de su GitHub cuenta y, enseguida, se aplica el cobro según las tarifas por minuto. Consulta [Precios del ejecutor de acciones](/es/billing/reference/actions-minute-multipliers). ```
Máquina virtual Procesador (CPU) Memoria (RAM) Almacenamiento (SSD) Arquitectura Etiqueta de flujo de trabajo
Linux 1 5 GB 14 GB x64 ubuntu-slim
Linux 2 8 GB 14 GB x64 ``` ubuntu-latest, ubuntu-24.04, ubuntu-22.04, ubuntu-26.04 (Versión preliminar pública)
Windows 2 8 GB 14 GB x64 windows-latest, , windows-2025, windows-2022
Linux 2 8 GB 14 GB ARM64 ubuntu-24.04-arm, ubuntu-22.04-arm, ubuntu-26.04-arm (Versión preliminar pública)
Windows 2 8 GB 14 GB ARM64 windows-11-arm, windows-11-vs2026-arm (Versión preliminar pública)
macOS 4 14 GB 14 GB Intel macos-15-intel, macos-26-intel
macOS 3 (M1) 7 GB 14 GB ARM64 macos-latest, macos-14, , macos-15, macos-26
Además de los ejecutores estándar alojados en GitHub, GitHub ofrece a los clientes con los planes GitHub Team y GitHub Enterprise Cloud una gama de máquinas virtuales administradas con prestaciones avanzadas; por ejemplo, más núcleos y espacio en disco, máquinas con GPU y máquinas con arquitectura ARM. Para más información, consulta [Ejecutores más grandes](/es/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners). > \[!NOTE] > Las imágenes de ejecutor `-latest` son las imágenes estables más recientes que proporciona GitHub y puede que no sean la versión más reciente del sistema operativo disponible del proveedor del sistema operativo. > \[!WARNING] > Las imágenes beta y en desuso se proporcionan "tal cual", "con todos sus fallos" y "conforme estén disponibles" y están excluidas del acuerdo de nivel de servicio y de la garantía. Las Imágenes Beta podrían no estar cubiertas por la asistencia al cliente. #### Ejemplo: Especificación de un sistema operativo ```yaml runs-on: ubuntu-latest ``` Para más información, consulta [Ejecutores hospedados en GitHub](/es/actions/using-github-hosted-runners/about-github-hosted-runners). ### Selección de ejecutores autohospedados A fin de especificar un ejecutor autohospedado para el trabajo, configure `runs-on` en el archivo de flujo de trabajo con las etiquetas de ejecutor autohospedado. Los ejecutores autohospedados pueden tener la etiqueta `self-hosted`. Al configurar un ejecutor autohospedado, de forma predeterminada se incluirá la etiqueta `self-hosted`. Puedes pasar la marca `--no-default-labels` para evitar que se aplique la etiqueta autohospedada. Las etiquetas pueden usarse para crear opciones de destino para los ejecutores, como el sistema operativo o la arquitectura, se recomienda proporcionar una serie de etiquetas que comience con `self-hosted` (debe estar en primer lugar) y que luego incluya etiquetas adicionales según sea necesario. Cuando especifiques un arreglo de etiquetas, los jobs se pondrán en cola cuando se trate de ejecutores que tengan todas las etiquetas que especificas. > \[!NOTE] El Actions Runner Controller no admite la etiqueta `self-hosted`. #### Ejemplo: Uso de etiquetas para la selección del ejecutor ```yaml runs-on: [self-hosted, linux] ``` Para más información, consulta [Ejecutores autohospedados](/es/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) y [Uso de ejecutores autohospedados en un flujo de trabajo](/es/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow). ### Elección de ejecutores en un grupo Puedes usar `runs-on` para dirigirte a grupos de ejecutores, de modo que el trabajo se ejecute en cualquier ejecutor que sea miembro de ese grupo. Para un control más granular, también puedes combinar grupos de ejecutores con etiquetas. Los grupos de ejecutores solo pueden tener [ejecutor más grande](/es/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners) o [ejecutores autohospedados](/es/actions/how-tos/managing-self-hosted-runners) como miembros. #### Ejemplo: Uso de grupos para controlar dónde se ejecutan los trabajos En este ejemplo, se han añadido runners a un grupo denominado `build-runners`. La clave `runs-on` envía el trabajo a cualquier ejecutor disponible del grupo `build-runners`: ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: build-runners steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` #### Ejemplo: Combinación de grupos y etiquetas Al combinar grupos y etiquetas, el ejecutor debe cumplir ambos requisitos para poder ejecutar el trabajo. En este ejemplo, la clave `runs-on` combina `group` y `labels` para que la tarea se envíe a cualquier ejecutor disponible dentro del grupo que también tenga una etiqueta que coincida: ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: ubuntu-runners labels: ubuntu-24.04-16core steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` ## `jobs..snapshot` Puede usar `jobs..snapshot` para generar una imagen personalizada. Agregue la palabra clave snapshot a la tarea, utilizando la sintaxis de cadena o la sintaxis de mapeo, como se muestra en [Generación de una imagen personalizada](/es/actions/how-tos/manage-runners/larger-runners/use-custom-images#generating-a-custom-image). Cada trabajo que incluya la palabra clave snapshot crea una imagen independiente. Para generar solo una imagen o versión de imagen, incluya todos los pasos de flujo de trabajo en un solo trabajo. Cada ejecución correcta de un trabajo que incluye la palabra clave snapshot crea una nueva versión de esa imagen. Para más información, consulta [Uso de imágenes personalizadas](/es/actions/how-tos/manage-runners/larger-runners/use-custom-images). ## `jobs..environment` Use `jobs..environment` para definir el entorno al que hace referencia el trabajo. Puede proporcionar el entorno como solo el entorno `name`, o bien como un objeto de entorno con `name` y `url`. La dirección URL se asigna a `environment_url` en la API de implementaciones. Para más información sobre la API de implementaciones, consulta [Puntos de conexión de la API de REST para repositorios](/es/rest/repos#deployments). > \[!NOTE] > Todas las reglas de protección de implementación deben pasar antes de que un job que referencie dicho ambiente se envie a un ejecutor. Para más información, consulta [Administrar entornos para la implementación](/es/actions/deployment/targeting-different-environments/managing-environments-for-deployment). ### Ejemplo: Utilizar un solo nombre de ambiente ```yaml environment: staging_environment ``` ### Ejemplo: Uso de un nombre y una URL de entorno ```yaml environment: name: production_environment url: https://github.com ``` El valor de `url` puede ser una expresión. Contextos de expresión permitidos: [`github`](/es/actions/learn-github-actions/contexts#github-context), [`inputs`](/es/actions/learn-github-actions/contexts#inputs-context), [`vars`](/es/actions/learn-github-actions/contexts#vars-context), [`needs`](/es/actions/learn-github-actions/contexts#needs-context), [`strategy`](/es/actions/learn-github-actions/contexts#strategy-context), [`matrix`](/es/actions/learn-github-actions/contexts#matrix-context), [`job`](/es/actions/learn-github-actions/contexts#job-context), [`runner`](/es/actions/learn-github-actions/contexts#runner-context), [`env`](/es/actions/learn-github-actions/contexts#env-context), y [`steps`](/es/actions/learn-github-actions/contexts#steps-context). Para más información sobre las expresiones, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions). ### Ejemplo: Uso de la salida como dirección URL ```yaml environment: name: production_environment url: ${{ steps.step_id.outputs.url_output }} ``` El valor de `name` puede ser una expresión. Contextos de expresión permitidos: [`github`](/es/actions/learn-github-actions/contexts#github-context), [`inputs`](/es/actions/learn-github-actions/contexts#inputs-context), [`vars`](/es/actions/learn-github-actions/contexts#vars-context), [`needs`](/es/actions/learn-github-actions/contexts#needs-context), [`strategy`](/es/actions/learn-github-actions/contexts#strategy-context) y [`matrix`](/es/actions/learn-github-actions/contexts#matrix-context). Para más información sobre las expresiones, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions). ### Ejemplo: Uso de una expresión como nombre de entorno ```yaml environment: name: ${{ github.ref_name }} ``` ## `jobs..concurrency` Use `jobs..concurrency` para asegurarse de que solo se ejecute al mismo tiempo un trabajo o flujo de trabajo que use el mismo grupo de concurrencia. Un grupo de concurrencia puede ser cualquier secuencia o expresión. Contextos de expresión permitidos: [`github`](/es/actions/learn-github-actions/contexts#github-context), [`inputs`](/es/actions/learn-github-actions/contexts#inputs-context), [`vars`](/es/actions/learn-github-actions/contexts#vars-context), [`needs`](/es/actions/learn-github-actions/contexts#needs-context), [`strategy`](/es/actions/learn-github-actions/contexts#strategy-context) y [`matrix`](/es/actions/learn-github-actions/contexts#matrix-context). Para más información sobre las expresiones, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions). También puede especificar `concurrency` en el nivel de flujo de trabajo. Para más información, vea [`concurrency`](/es/actions/using-workflows/workflow-syntax-for-github-actions#concurrency). Esto significa que en cualquier momento puede haber como máximo un trabajo o flujo de trabajo en ejecución en un grupo de concurrencia. Cuando un trabajo o flujo de trabajo concurrente se pone en cola, si otro trabajo o flujo de trabajo que utilicen el mismo grupo de simultaneidad en el repositorio se encuentra en curso, el trabajo o flujo de trabajo en cola se mostrará como `pending`. De forma predeterminada, cualquier trabajo o flujo de trabajo `pending` existente en el mismo grupo de simultaneidad se cancelará y el nuevo trabajo o flujo de trabajo en cola ocupará su lugar. Para cancelar también cualquier trabajo o flujo de trabajo actualmente en ejecución en el mismo grupo de simultaneidad, especifica `cancel-in-progress: true`. Para cancelar condicionalmente los trabajos o flujos de trabajo en ejecución actualmente en el mismo grupo de simultaneidad, puede especificar `cancel-in-progress` como una expresión con cualquiera de los contextos de expresión permitidos. Para permitir que más de un `pending` trabajo o ejecución de flujo de trabajo esperen en el mismo grupo de simultaneidad, use la propiedad opcional `queue`. La `queue` propiedad acepta los siguientes valores: * `single` (valor predeterminado): Como máximo, una tarea o ejecución de flujo de trabajo puede estar `pending` en el grupo de concurrencia. Cuando se pone en cola un nuevo trabajo o ejecución de flujo de trabajo, se cancela y reemplaza cualquier trabajo o flujo de trabajo existente `pending` que se ejecute en el mismo grupo. * `max`: hasta 100 trabajos o tareas de flujo de trabajo pueden incluirse en el grupo de concurrencia. Cuando la cola está llena, se cancelan los trabajos o ejecuciones de flujo de trabajo adicionales. La combinación de `queue: max` y `cancel-in-progress: true` no está permitida y producirá un error de validación de flujo de trabajo. > \[!NOTE] > > * El nombre de grupo de simultaneidad no distingue mayúsculas de minúsculas. Por ejemplo, `prod` y `Prod` se tratarán como el mismo grupo de simultaneidad. > * Los trabajos o ejecuciones de flujo de trabajo en el mismo grupo de concurrencia se procesan en el orden primero en entrar, primero en salir (FIFO) según el momento en que cada uno comenzó a esperar en el grupo de concurrencia, no en el momento en que se envió cada flujo de trabajo. Dado que la hora de inicio real de un trabajo o ejecución puede variar, no se garantiza la ordenación. ### Ejemplos: Utilizar la simultaneidad y el comportamiento predeterminado El comportamiento predeterminado de GitHub Actions es permitir que varios trabajos o ejecuciones de flujos de trabajo se ejecuten al mismo tiempo. La `concurrency` palabra clave permite controlar la simultaneidad de las ejecuciones de flujo de trabajo. Por ejemplo, puedes usar la `concurrency` palabra clave inmediatamente después de donde se definen las condiciones del gatillo para limitar la simultaneidad de ejecuciones de flujo de trabajo completas para una rama específica: ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` También puede limitar la simultaneidad de los trabajos dentro de un flujo de trabajo usando la `concurrency` palabra clave en el nivel de trabajo: ```yaml on: push: branches: - main jobs: job-1: runs-on: ubuntu-latest concurrency: group: example-group cancel-in-progress: true ``` ### Ejemplo: Grupos de concurrencia Los grupos de simultaneidad proporcionan un método para administrar y limitar las ejecuciones de flujos de trabajo o trabajos que comparten la misma clave de simultaneidad. La `concurrency` tecla se usa para agrupar flujos de trabajo o trabajos en un grupo de concurrencia. Al definir una `concurrency` clave, GitHub Actions garantiza que solo se ejecute un flujo de trabajo o trabajo con esa clave en un momento dado. Si una nueva ejecución de flujo de trabajo o trabajo comienza con la misma `concurrency` clave, GitHub Actions cancelará cualquier flujo de trabajo o trabajo que ya se ejecute con esa clave. La `concurrency` clave puede ser una cadena codificada de forma rígida o puede ser una expresión dinámica que incluya variables de contexto. Es posible definir condiciones de simultaneidad en el flujo de trabajo para que el flujo de trabajo o el trabajo formen parte de un grupo de simultaneidad. Esto significa que cuando se inicia una ejecución o un trabajo, GitHub cancelará las ejecuciones o trabajos que ya estén en curso en el mismo grupo de concurrencia. Esto resulta útil en escenarios en los que desea evitar ejecuciones paralelas para un determinado conjunto de flujos de trabajo o trabajos, como los que se usan para las implementaciones en un entorno de ensayo, con el fin de evitar acciones que puedan provocar conflictos o consumir más recursos de los necesarios. En este ejemplo, `job-1` forma parte de un grupo de simultaneidad denominado `staging_environment`. Esto significa que si se desencadena una nueva ejecución de `job-1`, se cancelarán las ejecuciones del mismo trabajo en el grupo de simultaneidad `staging_environment` que ya están en curso. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` Alternativamente, el uso de una expresión dinámica como `concurrency: ci-${{ github.ref }}` en el flujo de trabajo significa que el flujo de trabajo o el trabajo formarían parte de un grupo de simultaneidad denominado `ci-` seguido de la referencia de la rama o etiqueta que desencadenó el flujo de trabajo. En este ejemplo, si se inserta un nuevo compromiso en la rama principal mientras una ejecución anterior sigue en curso, se cancelará la ejecución anterior y se iniciará la nueva: ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Ejemplo: Poner en cola varias ejecuciones pendientes De forma predeterminada, solo un trabajo o ejecución de flujo de trabajo puede estar `pending` en un grupo de concurrencia a la vez. Para permitir que varias ejecuciones se pongan en cola en lugar de cancelarse, establezca `queue: max`. Con `queue: max`, hasta 100 trabajos o ejecuciones de flujo de trabajo pueden esperar en el grupo de simultaneidad; cuando la cola está llena, se cancelan las ejecuciones adicionales. Por ejemplo, el siguiente flujo de trabajo encola las implementaciones en el entorno `production`, procesándolas una a una en orden, según el momento en que cada ejecución comenzó a esperar en el grupo de concurrencia. ```yaml on: push: branches: - main concurrency: group: production-deploy queue: max ``` Tenga en cuenta que `queue: max` no se puede combinar con `cancel-in-progress: true`, porque las dos opciones describen comportamientos conflictivos para manejar las ejecuciones en curso. ### Ejemplo: Utilizar la concurrencia para cancelar cualquier tarea o ejecución en curso Para usar la concurrencia para cancelar cualquier trabajo en curso o ejecución en GitHub Actions, puede usar la clave `concurrency` con la opción `cancel-in-progress` establecida en `true`. ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Tenga en cuenta que en este ejemplo, sin definir un grupo de simultaneidad determinado, GitHub Actions cancelará *cualquier* ejecución en curso del trabajo o flujo de trabajo. ### Ejemplo: Utilizar un valor de respaldo Si compilas el nombre de grupo con una propiedad que solo se defina para eventos específicos, puedes utilizar un valor de segunda opción. Por ejemplo, `github.head_ref` solo se define en eventos `pull_request`. Si tu flujo de trabajo responde a otros eventos además de los eventos `pull_request`, necesitarás proporcionar una segunda opción para evitar un error de sintaxis. El siguiente grupo de simultaneidad cancela los trabajos en curso o solo se ejecuta en eventos `pull_request`; si `github.head_ref` no está definido, el grupo de simultaneidad revertirá al identificador de ejecución, que se garantiza que es único y definido para la ejecución. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Ejemplo: Cancelar únicamente las tareas o ejecuciones en curso para el flujo de trabajo actual Si tienes múltiples flujos de trabajo en el mismo repositorio, los nombres de los grupos de concurrencia deben ser únicos en todos los flujos de trabajo para evitar que se cancelen tareas o ejecuciones en progreso de otros flujos de trabajo. De lo contrario, cualquier tarea pendiente o previamente en curso se cancelará, sin importar el flujo de trabajo. Para cancelar solo las ejecuciones en curso del mismo flujo de trabajo, puedes usar la propiedad `github.workflow` para compilar el grupo de simultaneidad: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### Ejemplo: Cancelar solo trabajos en curso en ramas específicas Si desea cancelar trabajos en curso en determinadas ramas, pero no en otras, puede usar expresiones condicionales con `cancel-in-progress`. Por ejemplo, puede hacerlo si desea cancelar trabajos en curso en ramas de desarrollo, pero no en ramas de lanzamiento. Para cancelar solo las ejecuciones en curso del mismo flujo de trabajo cuando no se ejecutan en una rama de versión, puede establecer en `cancel-in-progress` una expresión similar a la siguiente: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` En este ejemplo, hacer múltiples push en una rama `release/1.2.3` no cancelaría las ejecuciones en curso. Las inserciones a otra rama, como `main`, cancelarían las ejecuciones en curso. ## `jobs..outputs` Puede usar `jobs..outputs` para crear un objeto `map` de salidas para un trabajo. Las salidas de un job se encuentran disponibles para todos los jobs descendentes que dependan de este job. Para más información sobre cómo definir dependencias de trabajo, vea [`jobs..needs`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds). Las salidas pueden ser un máximo de 1 MB por trabajo. El total de salidas de una ejecución de flujo de trabajo puede tener un máximo de 50 MB. El tamaño es aproximado en función de la codificación UTF-16. Las salidas de un trabajo que incluyen expresiones se evalúan en el ejecutor al final de cada trabajo. Las salidas que contienen secretos se redactan en el ejecutor y no se envían a GitHub Actions. Si se omite una salida porque puede contener un secreto, verá el siguiente mensaje de advertencia: "Omitir salida `{output.Key}`, ya que puede contener un secreto". Para obtener más información sobre cómo controlar los secretos, consulte el [ejemplo: Enmascaramiento y transmisión de un secreto entre trabajos o flujos de trabajo](/es/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#example-masking-and-passing-a-secret-between-jobs-or-workflows). Para usar salidas de trabajo en un trabajo dependiente, puede utilizar el contexto `needs`. Para más información, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts#needs-context). ### Ejemplo: definir salidas para un job ```yaml jobs: job1: runs-on: ubuntu-latest # Map a step output to a job output outputs: output1: ${{ steps.step1.outputs.test }} output2: ${{ steps.step2.outputs.test }} steps: - id: step1 run: echo "test=hello" >> "$GITHUB_OUTPUT" - id: step2 run: echo "test=world" >> "$GITHUB_OUTPUT" job2: runs-on: ubuntu-latest needs: job1 steps: - env: OUTPUT1: ${{needs.job1.outputs.output1}} OUTPUT2: ${{needs.job1.outputs.output2}} run: echo "$OUTPUT1 $OUTPUT2" ``` ### Uso de salidas de trabajo en un trabajo de matriz Las matrices se pueden usar para generar varias salidas de nombres diferentes. Al usar una matriz, las salidas de trabajo se combinarán desde todos los trabajos dentro de la matriz. ```yaml jobs: job1: runs-on: ubuntu-latest outputs: output_1: ${{ steps.gen_output.outputs.output_1 }} output_2: ${{ steps.gen_output.outputs.output_2 }} output_3: ${{ steps.gen_output.outputs.output_3 }} strategy: matrix: version: [1, 2, 3] steps: - name: Generate output id: gen_output run: | version="${{ matrix.version }}" echo "output_${version}=${version}" >> "$GITHUB_OUTPUT" job2: runs-on: ubuntu-latest needs: [job1] steps: # Will show # { # "output_1": "1", # "output_2": "2", # "output_3": "3" # } - run: echo '${{ toJSON(needs.job1.outputs) }}' ``` > \[!WARNING] > Las acciones no garantizan el orden en el que se ejecutarán los trabajos de matriz. Asegúrese de que el nombre de salida es único, de lo contrario el último trabajo de matriz que se invalide el valor de salida. ## `jobs..env` Objeto `map` de las variables disponibles para todos los pasos del trabajo. También puedes establecer las variables para todo el flujo de trabajo o para un paso en particular. Para más información, vea [`env`](#env) y [`jobs..steps[*].env`](#jobsjob_idstepsenv). Cuando se define más de una variable de entorno con el mismo nombre, GitHub utiliza la más específica. Por ejemplo, una variable de entorno definida en un paso anulará aquellas variables de entorno de los trabajos y flujos de trabajo con el mismo nombre, mientras ejecuta el paso. Una variable de entorno definida para un trabajo anulará aquella de un flujo de trabajo si tienen el mismo nombre, mientras se ejecuta el trabajo. ### Ejemplo de `jobs..env` ```yaml jobs: job1: env: FIRST_NAME: Mona ``` ## `jobs..defaults` Use `jobs..defaults` para crear un elemento `map` de configuración predeterminada que se aplicará a todos los pasos del trabajo. También puedes configurar ajustes predeterminados para todo el flujo de trabajo. Para obtener más información, vea [`defaults`](/es/actions/using-workflows/workflow-syntax-for-github-actions#defaults). Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ## `jobs..defaults.run` Use `jobs..defaults.run` para proporcionar el valor predeterminado de `shell` y `working-directory` para todos los pasos `run` del trabajo. Puede proporcionar las opciones predeterminadas de `shell` y `working-directory` para todos los pasos [`run`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) de un trabajo. También puede establecer la configuración predeterminada de `run` para todo el flujo de trabajo. Para obtener más información, vea [`defaults.run`](/es/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun). Se pueden invalidar en los niveles `jobs..defaults.run` y `jobs..steps[*].run`. Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ## `jobs..defaults.run.shell` Usa `shell` para definir `shell` para un paso. Esta palabra clave puede hacer referencia a varios contextos. Para más información, consulta [Contextos](/es/actions/learn-github-actions/contexts#context-availability). | Plataforma compatible | Parámetro `shell` | Descripción | Comando ejecutado interamente | | --------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- | | Linux/macOS | unspecified | El shell predeterminado en plataformas que no son de Windows. Ten en cuenta que esto ejecuta un comando diferente a cuando `bash` se especifica explícitamente. Si `bash` no se encuentra en la ruta de acceso, se trata como `sh`. | `bash -e {0}` | | Todo | `bash` | El shell predeterminado en plataformas que no son de Windows con una reserva en `sh`. Al especificar un bash shell en Windows, se usa el bash shell incluido con Git para Windows. | `bash --noprofile --norc -eo pipefail {0}` | | Todo | `pwsh` | Powershell Core. GitHub agrega la extensión `.ps1` al nombre del script. | `pwsh -command ". '{0}'"` | | Todo | `python` | Ejecuta el comando python. | `python {0}` | | Linux/macOS | `sh` | El comportamiento de reserva para plataformas que no son Windows si no se proporciona un shell y `bash` no se encuentra en la ruta. | `sh -e {0}` | | Windows | `cmd` | GitHub agrega la extensión `.cmd` al nombre del script y lo sustituye por `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Este es el shell predeterminado que se usa en Windows. Powershell Core. GitHub agrega la extensión `.ps1` al nombre del script. Si el ejecutor autohospedado de Windows no tiene *PowerShell Core* instalado, en su lugar se usa *PowerShell Desktop*. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | El PowerShell Desktop. GitHub agrega la extensión `.ps1` al nombre del script. | `powershell -command ". '{0}'"`. | Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ## `jobs..defaults.run.working-directory` Usa `working-directory` para definir el directorio de trabajo para `shell` para un paso. Esta palabra clave puede hacer referencia a varios contextos. Para más información, consulta [Contextos](/es/actions/learn-github-actions/contexts#context-availability). > \[!TIP] > Asegúrate de que la asignación de `working-directory` exista en el ejecutor antes de ejecutar el shell en él. > Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo. ### Ejemplo: Establecimiento de las opciones predeterminadas de los pasos `run` para un trabajo ```yaml jobs: job1: runs-on: ubuntu-latest defaults: run: shell: bash working-directory: ./scripts ``` ## `jobs..steps` Un trabajo contiene una secuencia de tareas denominada `steps`. Los pasos pueden ejecutar comandos, tareas de configuración o una acción en tu repositorio, un repositorio público o una acción publicada en un registro de Docker. No todos los pasos ejecutan acciones, pero todas las acciones se ejecutan como un paso. Cada paso se ejecuta en su propio proceso en el ambiente ejecutor y tiene acceso al espacio de trabajo y al sistema de archivos. Ya que los pasos se ejecutan en su propio proceso, los cambios a las variables de ambiente no se preservan entre pasos. GitHub proporciona pasos integrados para configurar y completar un trabajo. GitHub solo muestra las primeras 1000 comprobaciones; sin embargo, puede ejecutar un número ilimitado de pasos siempre que se encuentren dentro de los límites de uso del flujo de trabajo. Para obtener más información, consulte [Facturación y utilización](/es/actions/learn-github-actions/usage-limits-billing-and-administration) para ejecutores alojados GitHub y [Límites de acciones](/es/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) para los límites de uso de los ejecutores autohospedados. ### Ejemplo de `jobs..steps` ```yaml name: Greeting from Mona on: push jobs: my-job: name: My Job runs-on: ubuntu-latest steps: - name: Print a greeting env: MY_VAR: Hi there! My name is FIRST_NAME: Mona MIDDLE_NAME: The LAST_NAME: Octocat run: | echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME. ``` ## `jobs..steps[*].id` Un identificador único para el paso. Puede usar `id` para hacer referencia al paso en los contextos. Para más información, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts). ## `jobs..steps[*].if` Puede usar el condicional `if` para impedir que se ejecute un paso si no se cumple una condición. Puedes usar cualquier contexto y expresión admitidos para crear un condicional. Para más información sobre los contextos que se admiten en esta clave, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts#context-availability). Cuando se usan expresiones en un condicional `if`, se puede omitir la sintaxis de la expresión `${{ }}` opcionalmente, porque GitHub Actions evalúa automáticamente el condicional `if` como una expresión. Sin embargo, esta excepción no se aplica en todas partes. Debe usar siempre la sintaxis de expresión `${{ }}` o escapar con `''`, `""`o `()` cuando la expresión comienza con `!`, ya que `!` es una notación reservada en formato YAML. Por ejemplo: ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` Para obtener más información, consulte [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions). ### Ejemplo: Uso de contextos Este paso solo se ejecuta cuando el tipo de evento es `pull_request` y la acción del evento es `unassigned`. ```yaml steps: - name: My first step if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }} run: echo This event is a pull request that had an assignee removed. ``` ### Ejemplo: Utilizando funciones de verificación de estado El objeto `my backup step` solo se ejecuta cuando se produce un error en el paso anterior de un trabajo. Para más información, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/learn-github-actions/expressions#status-check-functions). ```yaml steps: - name: My first step uses: octo-org/action-name@main - name: My backup step if: ${{ failure() }} uses: actions/heroku@1.0.0 ``` ### Ejemplo: Utilizar secretos No se puede hacer referencia a los secretos directamente en las condicionales `if:`. En vez de esto, considera configurar secretos como variables de entorno a nivel de trabajo y luego referenciar dichas variables para ejecutar pasos condicionalmente en el trabajo. Si no se ha establecido un secreto, el valor devuelto de una expresión que hace referencia al secreto (como `${{ secrets.SuperSecret }}` en el ejemplo) será una cadena vacía. ```yaml name: Run a step if a secret has been set on: push jobs: my-jobname: runs-on: ubuntu-latest env: super_secret: ${{ secrets.SuperSecret }} steps: - if: ${{ env.super_secret != '' }} run: echo 'This step will only run if the secret has a value set.' - if: ${{ env.super_secret == '' }} run: echo 'This step will only run if the secret does not have a value set.' ``` Para más información, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts#context-availability) y [Uso de secretos en Acciones de GitHub](/es/actions/security-guides/using-secrets-in-github-actions). ## `jobs..steps[*].name` Un nombre para su paso que se mostrará en GitHub. ## `jobs..steps[*].uses` Selecciona una acción a ejecutar como parte de un paso en tu trabajo. Una acción es una unidad de código reutilizable. Puede usar una acción definida en el mismo repositorio que el flujo de trabajo, un repositorio público o en una [imagen de contenedor de Docker publicada](https://hub.docker.com/). Te recomendamos encarecidamente que incluyas la versión de la acción que estás utilizando. Para ello, especifica una referencia de Git, SHA o una etiqueta de Docker. Si no especificas una versión, podrías interrumpir tus flujos de trabajo o provocar un comportamiento inesperado cuando el propietario de la acción publique una actualización. * El uso del SHA de confirmación de una versión de acción lanzada es lo más seguro para la estabilidad y la seguridad. * Si la acción publica etiquetas de versiones principales, debes esperar recibir correcciones críticas y parches de seguridad a la vez que se conserva la compatibilidad. Ten en cuenta que este comportamiento queda a discreción del autor de la acción. * Puede ser conveniente utilizar la rama predeterminada de una acciòn, pero si alguien lanza una versiòn principal nueva con un cambio importante, tu flujo de trabajo podrìa fallar. Algunas acciones necesitan entradas que debe establecer mediante la palabra clave [`with`](#jobsjob_idstepswith). Revisa el archivo README de la acción para determinar las entradas requeridas. Las acciones son archivos de JavaScript o contenedores de Docker. Si la acción que estás usando es un contenedor de Docker, debes ejecutar el job en un ambiente Linux. Para obtener información, vea [`runs-on`](#jobsjob_idruns-on). ### Ejemplo: Utilizando acciones versionadas ```yaml steps: # Reference a specific commit - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # Reference the major version of a release - uses: actions/checkout@v6 # Reference a specific version - uses: actions/checkout@v6.2.0 # Reference a branch - uses: actions/checkout@main ``` ### Ejemplo: Utilizando una acción pública `{owner}/{repo}@{ref}` Puede especificar una rama, una referencia o SHA en un repositorio público GitHub . ```yaml jobs: my_first_job: steps: - name: My first step # Uses the default branch of a public repository uses: actions/heroku@main - name: My second step # Uses a specific version tag of a public repository uses: actions/aws@v2.0.1 ``` ### Ejemplo: Utilizando una acción pública en un subdirectorio `{owner}/{repo}/{path}@{ref}` Un subdirectorio en un repositorio público GitHub en una rama, referencia o SHA específicos. ```yaml jobs: my_first_job: steps: - name: My first step uses: actions/aws/ec2@main ``` ### Ejemplo: Utilizando una acción en el mismo repositorio que el flujo de trabajo `./path/to/dir` La ruta al directorio que contiene la acción en el repositorio de tu flujo de trabajo. Debes revisar tu repositorio antes de usar la acción. Ejemplo de estructura de archivo de repositorio: ```shell |-- hello-world (repository) | |__ .github | └── workflows | └── my-first-workflow.yml | └── actions | |__ hello-world-action | └── action.yml ``` La ruta de acceso es relativa (`./`) al directorio de trabajo predeterminado (`github.workspace`, `$GITHUB_WORKSPACE`). Si la acción comprueba el repositorio en una ubicación diferente del flujo de trabajo, se debe actualizar la ruta de acceso relativa que se usa para las acciones locales. Ejemplo de archivo de flujo de trabajo: ```yaml jobs: my_first_job: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: My first step - check out repository uses: actions/checkout@v6 # This step references the directory that contains the action. - name: Use local hello-world-action uses: ./.github/actions/hello-world-action ``` ### Ejemplo: Utilizando una acción de Docker Hub `docker://{image}:{tag}` Una imagen de Docker publicada en [Docker Hub](https://hub.docker.com/). ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://alpine:3.8 ``` ### Ejemplo: Uso de GitHub PackagesContainer registry `docker://{host}/{image}:{tag}` Imagen pública de Docker en GitHub PackagesContainer registry. ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://ghcr.io/OWNER/IMAGE_NAME ``` ### Ejemplo: Utilizando una acción del registro público de Docker `docker://{host}/{image}:{tag}` Una imagen de Docker en un registro público. En este ejemplo se usa Google Container Registry en `gcr.io`. ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://gcr.io/cloud-builders/gradle ``` ### Ejemplo: Utilizando una acción dentro de un repositorio privado diferente al del flujo de trabajo Si la acción está en un repositorio interno o en un repositorio privado configurado para permitir el acceso desde el repositorio del flujo de trabajo, puede hacer referencia a la acción directamente. Para más información, consulta [Administración de la configuración de GitHub Actions para un repositorio](/es/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository) y [Administración de la configuración de GitHub Actions para un repositorio](/es/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository). Si la acción no está en un repositorio configurado para permitir el acceso, debe consultar el repositorio y hacer referencia a la acción localmente. Genere un personal access token y agregue el token como un secreto. En el ejemplo siguiente se muestra este método para hacer referencia a una acción. Para más información, consulta [Administración de tokens de acceso personal](/es/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) y [Uso de secretos en Acciones de GitHub](/es/actions/security-guides/using-secrets-in-github-actions). Reemplace `PERSONAL_ACCESS_TOKEN` en el ejemplo por el nombre del secreto. ```yaml jobs: my_first_job: steps: - name: Check out repository uses: actions/checkout@v6 with: repository: octocat/my-private-repo ref: v1.0 token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} path: ./.github/actions/my-private-repo - name: Run my action uses: ./.github/actions/my-private-repo/my-action ``` Como alternativa, use un GitHub App en lugar de un personal access token para garantizar que el flujo de trabajo continúe ejecutándose incluso si el propietario de personal access token se va. Para más información, consulta [Realización de solicitudes de API autenticadas con una aplicación de GitHub en un flujo de trabajo de Acciones de GitHub](/es/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). ## `jobs..steps[*].run` Ejecuta programas de línea de comandos que no superan los 21 000 caracteres mediante el shell del sistema operativo. Si no proporciona un valor `name`, el nombre del paso tendrá como valor predeterminado el texto especificado en el comando `run`. Los comandos se ejecutan por defecto utilizando shells no de inicio de sesión. Puedes elegir un shell diferente y personalizar el que utilizaste para ejecutar los comandos. Para más información, vea [`jobs..steps[*].shell`](#jobsjob_idstepsshell). Cada palabra clave `run` representa un nuevo proceso y shell en el entorno del ejecutor. Cuando proporcionas comandos de varias líneas, cada línea se ejecuta en el mismo shell. Por ejemplo: * Comando de una sola línea: ```yaml - name: Install Dependencies run: npm install ``` * Comando de varias líneas: ```yaml - name: Clean install dependencies and build run: | npm ci npm run build ``` ## `jobs..steps[*].working-directory` Con la palabra clave `working-directory`, puede especificar el directorio de trabajo desde el que ejecutar el comando. ```yaml - name: Clean temp directory run: rm -rf * working-directory: ./temp ``` Como alternativa, puede especificar un directorio de trabajo predeterminado para todos los `run` pasos de un trabajo o para todos los `run` pasos del flujo de trabajo completo. Para más información, vea [`defaults.run.working-directory`](/es/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory) y [`jobs..defaults.run.working-directory`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunworking-directory). También puede usar un `run` paso para ejecutar un script. Para más información, consulta [Agregar scripts a tu flujo de trabajo](/es/actions/writing-workflows/choosing-what-your-workflow-does/adding-scripts-to-your-workflow). ## `jobs..steps[*].shell` Puedes invalidar los valores del shell predeterminado en el sistema operativo del ejecutor y el valor predeterminado del trabajo mediante la palabra clave `shell`. Puede usar palabras clave `shell` integradas, o bien puede definir un conjunto personalizado de opciones de shell. El comando de shell que se ejecuta internamente ejecuta un archivo temporal que contiene los comandos especificados en la palabra clave `run`. | Plataforma compatible | Parámetro `shell` | Descripción | Comando ejecutado interamente | | --------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- | | Linux/macOS | unspecified | El shell predeterminado en plataformas que no son de Windows. Ten en cuenta que esto ejecuta un comando diferente a cuando `bash` se especifica explícitamente. Si `bash` no se encuentra en la ruta de acceso, se trata como `sh`. | `bash -e {0}` | | Todo | `bash` | El shell predeterminado en plataformas que no son de Windows con una reserva en `sh`. Al especificar un bash shell en Windows, se usa el bash shell incluido con Git para Windows. | `bash --noprofile --norc -eo pipefail {0}` | | Todo | `pwsh` | Powershell Core. GitHub agrega la extensión `.ps1` al nombre del script. | `pwsh -command ". '{0}'"` | | Todo | `python` | Ejecuta el comando python. | `python {0}` | | Linux/macOS | `sh` | El comportamiento de reserva para plataformas que no son Windows si no se proporciona un shell y `bash` no se encuentra en la ruta. | `sh -e {0}` | | Windows | `cmd` | GitHub agrega la extensión `.cmd` al nombre del script y lo sustituye por `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Este es el shell predeterminado que se usa en Windows. Powershell Core. GitHub agrega la extensión `.ps1` al nombre del script. Si el ejecutor autohospedado de Windows no tiene *PowerShell Core* instalado, en su lugar se usa *PowerShell Desktop*. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | El PowerShell Desktop. GitHub agrega la extensión `.ps1` al nombre del script. | `powershell -command ". '{0}'"`. | Como alternativa, puedes especificar un shell predeterminado para todos los pasos `run` de un trabajo o para todos los pasos `run` del flujo de trabajo completo. Para más información, vea [`defaults.run.shell`](/es/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunshell) y [`jobs..defaults.run.shell`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunshell). ### Ejemplo: Ejecutar un comando con Bash ```yaml steps: - name: Display the path shell: bash run: echo $PATH ``` ### Ejemplo: Ejecutar un comando con Windows `cmd` ```yaml steps: - name: Display the path shell: cmd run: echo %PATH% ``` ### Ejemplo: Ejecutar un comando con PowerShell Core ```yaml steps: - name: Display the path shell: pwsh run: echo ${env:PATH} ``` ### Ejemplo: Usar el escritorio de PowerShell para ejecutar un comando ```yaml steps: - name: Display the path shell: powershell run: echo ${env:PATH} ``` ### Ejemplo: Ejecutar un script alineado de Python ```yaml steps: - name: Display the path shell: python run: | import os print(os.environ['PATH']) ``` ### Shell personalizado Puede establecer el valor `shell` en una cadena de plantilla mediante `command [options] {0} [more_options]`. GitHub interpreta la primera palabra delimitada por espacios en blanco de la cadena como comando e inserta el nombre de archivo para el script temporal en `{0}`. Por ejemplo: ```yaml steps: - name: Display the environment variables and their values shell: perl {0} run: | print %ENV ``` El comando que se usa, `perl` en este ejemplo, debe estar instalado en el ejecutor. Para obtener información sobre el software incluido en los ejecutores hospedados en GitHub, consulte [Ejecutores hospedados en GitHub](/es/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software). ### Códigos de salida y preferencia de acción de error Para las palabras clave de shell integradas, proporcionamos los siguientes valores predeterminados que son ejecutados por los ejecutores alojados en GitHub. Deberías usar estos lineamientos al ejecutar scripts de shell. * `bash` / `sh`: * De forma predeterminada, se impone un comportamiento de fallo rápido mediante `set -e` para `sh` y `bash`. Cuando se especifica `shell: bash`, `-o pipefail` también se aplica para forzar una salida anticipada de las canalizaciones que generan un estado de salida distinto de cero. * Puedes controlar completamente los parámetros del shell al proporcionar una cadena de plantilla a las opciones del shell. Por ejemplo, `bash {0}`. * Los shells tipo `sh` salen con el código de salida del último comando ejecutado en un script, que también es el comportamiento predeterminado para las acciones. El ejecutor informará el estado del paso como fallido o exitoso según este código de salida. * `powershell`/`pwsh` * Comportamiento de falla rápida cuando sea posible. Para el shell integrado de `pwsh` y `powershell`, se antepondrá `$ErrorActionPreference = 'stop'` al contenido del script. * Se anexa `if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }` a los scripts de PowerShell para que los estados de acción reflejen el último código de salida del script. * Los usuarios siempre pueden optar por no usar el shell integrado y proporcionar una opción de shell personalizada como `pwsh -File {0}` o `powershell -Command "& '{0}'"`, según sea necesario. * `cmd` * No parece haber una manera de optar por completo por un comportamiento de falla rápida que no sea escribir tu script para verificar cada código de error y responder en consecuencia. Debido a que en realidad no podemos proporcionar ese comportamiento por defecto, debes escribir este comportamiento en tu script. * `cmd.exe` saldrá con el nivel de error del último programa que ha ejecutado y devolverá el código de error al ejecutor. Este comportamiento es internamente coherente con el comportamiento predeterminado de `sh` y `pwsh` anterior, y es el `cmd.exe` predeterminado, por lo que este comportamiento permanece intacto. ## `jobs..steps[*].with` Objeto `map` de los parámetros de entrada definidos por la acción. Cada parámetro de entrada es un par clave/valor. Los parámetros de entrada se establecen como variables de entorno. La variable utiliza el prefijo `INPUT_` se convierte en mayúsculas. Los parámetros de entrada definidos para un contenedor de Docker deben usar `args`. Para más información, vea [`jobs..steps[*].with.args`](#jobsjob_idstepswithargs). ### Ejemplo de `jobs..steps[*].with` Define los tres parámetros de entrada (`first_name`, `middle_name` y `last_name`) definidos por la acción `hello_world`. Estas variables de entrada serán accesibles para la acción `hello-world` como las variables de entorno `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME` y `INPUT_LAST_NAME`. ```yaml jobs: my_first_job: steps: - name: My first step uses: actions/hello_world@main with: first_name: Mona middle_name: The last_name: Octocat ``` ## `jobs..steps[*].with.args` Objeto `string` que define las entradas de un contenedor de Docker. GitHub pasa el `args` al `ENTRYPOINT` del contenedor cuando este se inicia. Este parámetro no admite un objeto `array of strings`. Un solo argumento que incluya espacios debe estar entre comillas dobles `""`. ### Ejemplo de `jobs..steps[*].with.args` ```yaml steps: - name: Explain why this job ran uses: octo-org/action-name@main with: entrypoint: /bin/echo args: The ${{ github.event_name }} event triggered this step. ``` `args` se usan en lugar de la instrucción `CMD` en `Dockerfile`. Si usa `CMD` en su `Dockerfile`, utilice las pautas ordenadas por preferencia: 1. Documenta los argumentos requeridos en el README de la acción y omítelos de la instrucción `CMD`. 2. Use los valores predeterminados que permiten usar la acción sin especificar `args`. 3. Si la acción expone una marca `--help`, o algo similar, úsela como valor predeterminado para que la acción se documente de forma automática. ## `jobs..steps[*].with.entrypoint` Invalida el `ENTRYPOINT` de Docker en el `Dockerfile`, o lo establece si todavía no se ha especificado. A diferencia de la instrucción `ENTRYPOINT` de Docker que tiene un formato de shell y archivo ejecutable, la palabra clave `entrypoint` solo acepta una cadena que define el archivo ejecutable que se va a ejecutar. ### Ejemplo de `jobs..steps[*].with.entrypoint` ```yaml steps: - name: Run a custom command uses: octo-org/action-name@main with: entrypoint: /a/different/executable ``` La palabra clave `entrypoint` se debe usar con acciones de contenedor de Docker, pero también se puede utilizar con acciones de JavaScript que no definan ninguna entrada. ## `jobs..steps[*].env` Establece variables para los pasos a utilizar en el entorno de ejecución. También puedes establecer las variables para todo el flujo de trabajo o para una tarea. Para más información, vea [`env`](#env) y [`jobs..env`](#jobsjob_idenv). Cuando se define más de una variable de entorno con el mismo nombre, GitHub utiliza la más específica. Por ejemplo, una variable de entorno definida en un paso anulará aquellas variables de entorno de los trabajos y flujos de trabajo con el mismo nombre, mientras ejecuta el paso. Una variable de entorno definida para un trabajo anulará aquella de un flujo de trabajo si tienen el mismo nombre, mientras se ejecuta el trabajo. Es posible que las acciones públicas especifiquen las variables esperadas en el archivo README. Si vas a establecer un secreto o un valor confidencial, como una contraseña o un token, debes establecer secretos mediante el contexto `secrets`. Para más información, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts). ### Ejemplo de `jobs..steps[*].env` ```yaml steps: - name: My first action env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} FIRST_NAME: Mona LAST_NAME: Octocat ``` ## `jobs..steps[*].continue-on-error` Impide que un trabajo falle cuando falla un paso. Establézcalo en `true` para permitir que un trabajo se supere cuando se produzca un error en este paso. ## `jobs..steps[*].timeout-minutes` El número máximo de minutos para ejecutar el paso antes de terminar el proceso. Máximo: 360 tanto para los ejecutores alojados en GitHub como para los autohospedados. No se admiten valores fraccionales. `timeout-minutes` debe ser un entero positivo. ## `jobs..steps[*].background` Ejecuta un paso de forma asíncrona para que el trabajo continúe con el paso siguiente sin esperar a que finalice. Use `background: true` para procesos de ejecución prolongada, como bases de datos, servidores o tareas de supervisión, que deben ejecutarse junto con otros pasos. Más tarde, se sincroniza con los pasos en segundo plano mediante [`wait`](#jobsjob_idstepswait) o [`wait-all`](#jobsjob_idstepswait-all), o bien los detiene con [`cancel`](#jobsjob_idstepscancel). Puede usar `background` en los pasos que usan `run` o `uses`. Para hacer referencia a un paso en segundo plano desde [`wait`](#jobsjob_idstepswait) o [`cancel`](#jobsjob_idstepscancel), asígnele un [`id`](#jobsjob_idstepsid). Se pueden ejecutar simultáneamente un máximo de 10 pasos en segundo plano en un mismo trabajo; los pasos adicionales en segundo plano se ponen en cola hasta que haya un hueco libre. Las salidas y los cambios de entorno de un paso en segundo plano solo están disponibles tras ejecutar un paso `wait` o `wait-all` que lo incluya. Si un paso en segundo plano falla, la tarea falla en el siguiente `wait` o `wait-all` que lo incluya (a menos que se establezca [`continue-on-error`](#jobsjob_idstepscontinue-on-error) en ese paso). Se ejecuta implícitamente `wait-all` antes de cualquier limpieza posterior al trabajo. Use `background` cuando necesite un control específico: iniciar un proceso de ejecución prolongada (como un servidor o una base de datos) que permanezca activo mientras se ejecutan pasos posteriores, haciendo referencia a un paso específico con [`wait`](#jobsjob_idstepswait) o [`cancel`](#jobsjob_idstepscancel), o intercalando el trabajo en segundo plano con otros pasos. Si en su lugar tiene un grupo independiente de pasos que deben finalizar antes de que continúe el trabajo, [`parallel`](#jobsjob_idstepsparallel) es una abreviatura más cómoda. > \[!NOTE] > No se puede usar `background` en los pasos dentro de una acción compuesta. Una acción compuesta se puede ejecutar como un paso en segundo plano, pero no puede declarar los pasos en segundo plano internamente. ### Ejemplo: Ejecución de un paso en segundo plano ```yaml steps: - name: Start server id: server run: npm start background: true - name: Run tests against the server run: npm test - name: Wait for the server step to finish wait: server ``` ## `jobs..steps[*].wait` Detiene el trabajo hasta que se completen uno o varios pasos en segundo plano. Un `wait` paso no realiza ningún trabajo, solo se bloquea hasta que finalicen los pasos en segundo plano a los que se hace referencia. Proporcione un solo paso `id` como una cadena o varios pasos `id`como una matriz. Una vez completado un `wait` paso, las salidas de los pasos en segundo plano a los que se hace referencia estarán disponibles para los pasos posteriores. Si se produce un error en un paso en segundo plano al que se hace referencia, también se produce un error en el `wait` paso. > \[!NOTE] > Un `wait` paso siempre se ejecuta y no admite el [`if`](#jobsjob_idstepsif) condicional. ### Ejemplo: Espera de pasos específicos en segundo plano ```yaml steps: - name: Build frontend id: build-frontend run: npm run build:frontend background: true - name: Build backend id: build-backend run: npm run build:backend background: true - name: Run linter while builds run run: npm run lint - name: Wait for both builds to finish wait: [build-frontend, build-backend] - name: Run tests run: npm test ``` ## `jobs..steps[*].wait-all` Pone en pausa la tarea hasta que se hayan completado todos los pasos activos en segundo plano. Esto resulta útil cuando se están ejecutando varios pasos en segundo plano y desea que finalicen todos antes de continuar. Al igual que `wait`, el paso `wait-all` falla si cualquiera de los pasos en segundo plano que espera ha fallado, a menos que establezca [`continue-on-error`](#jobsjob_idstepscontinue-on-error) en `true`. La palabra clave `wait-all` no admite argumentos. > \[!NOTE] > Un paso `wait-all` siempre se ejecuta y no admite la condicional [`if`](#jobsjob_idstepsif). ### Ejemplo: Esperando a que finalicen todos los pasos en segundo plano ```yaml steps: - name: Start database id: db run: docker run -d postgres:15 background: true - name: Start cache id: cache run: docker run -d redis:7 background: true - name: Run integration tests run: npm run test:integration - name: Wait for all services to stop wait-all: ``` ## `jobs..steps[*].cancel` Finaliza correctamente un paso en segundo plano en ejecución. El ejecutor envía al proceso del paso una señal de terminación (`SIGTERM`) para que pueda realizar las tareas de limpieza, y lo detiene por la fuerza (`SIGKILL`) si no finaliza dentro de un breve período de gracia. La palabra clave `cancel` se dirige a un único paso de fondo mediante su `id`. > \[!NOTE] > Un paso `cancel` siempre se ejecuta y no admite la condición [`if`](#jobsjob_idstepsif). ### Ejemplo: Cancelación de un paso en segundo plano ```yaml steps: - name: Start long-running monitor id: monitor run: ./scripts/monitor.sh background: true - name: Run the main task run: npm test - name: Stop the monitor cancel: monitor ``` ## `jobs..steps[*].parallel` Ejecuta un grupo de pasos simultáneamente y, a continuación, espera a que finalicen todos antes de continuar. La palabra clave `parallel` es una abreviatura: cada paso del grupo se ejecuta como un paso de fondo, con un `wait` implícito al final del grupo. Úselo cuando tenga un grupo independiente de pasos que se puedan ejecutar al mismo tiempo y no es necesario hacer referencia a ellos individualmente. Utilice `parallel` cuando tenga un conjunto autónomo de pasos que deban finalizar antes de que el proceso continúe, por ejemplo, al compilar varios componentes a la vez. Use [`background`](#jobsjob_idstepsbackground) cuando necesite un control más preciso: iniciar un proceso de ejecución prolongada (como un servidor o una base de datos) que permanezca activo mientras se ejecutan pasos posteriores, haciendo referencia a un paso específico con [`wait`](#jobsjob_idstepswait) o [`cancel`](#jobsjob_idstepscancel), o intercalando el trabajo en segundo plano con otros pasos. En resumen, `parallel` es más limitado pero más conveniente para el caso de "ejecutar este grupo a la vez", mientras que `background` es el primitivo de uso general. Cada paso del grupo está sujeto al mismo límite de concurrencia de 10 pasos que el de otros pasos en segundo plano. > \[!NOTE] > No se puede usar `parallel` dentro de una acción compuesta. ### Ejemplo: Ejecución de pasos en paralelo ```yaml steps: - uses: actions/checkout@v6 - parallel: - name: Build frontend run: npm run build:frontend - name: Build backend run: npm run build:backend - name: Build docs run: npm run build:docs - name: Run tests after all builds complete run: npm test ``` El grupo anterior es equivalente a declarar cada paso con `background: true` seguido de un `wait` paso. ## `jobs..timeout-minutes` El número máximo de minutos durante los que se permite que un trabajo se ejecute antes de que GitHub lo cancele automáticamente. Predeterminado: 360 Si el tiempo de espera excede el límite de tiempo de ejecución de la tarea para el ejecutor, la tarea se cancelará cuando se alcance el límite de tiempo de ejecución. Para obtener más información sobre los límites de tiempo de ejecución de los trabajos, consulte [Facturación y utilización](/es/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits) para los ejecutores alojados en GitHub y [Límites de acciones](/es/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) para los límites de uso de los ejecutores autohospedados. > \[!NOTE] > `GITHUB_TOKEN` expira cuando finaliza un trabajo o después de un máximo de 24 horas. En el caso de los ejecutores autohospedados, el token puede ser el factor limitante si el tiempo de espera del trabajo es superior a 24 horas. Para obtener más información sobre el `GITHUB_TOKEN`, consulta [Uso de GITHUB\_TOKEN para la autenticación en flujos de trabajo](/es/actions/security-guides/automatic-token-authentication#about-the-github_token-secret). ## `jobs..strategy` Usa `jobs..strategy` para emplear una estrategia de matriz para tus trabajos. Una estrategia de matriz permite usar variables en una definición de trabajo para crear automáticamente varias ejecuciones de trabajos basadas en las combinaciones de las variables. Por ejemplo, puedes usar una estrategia de matriz para probar el código en varias versiones de un lenguaje o en varios sistemas operativos. Para obtener más información, consulte [Ejecución de variaciones de trabajos en un flujo de trabajo](/es/actions/using-jobs/using-a-matrix-for-your-jobs). ## `jobs..strategy.matrix` Usa `jobs..strategy.matrix` para definir una matriz de diferentes configuraciones de trabajo. Para más información, consulta [Ejecución de variaciones de trabajos en un flujo de trabajo](/es/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow). Una matriz puede generar un máximo de 256 trabajos por ejecución de flujo de trabajo. Este límite se aplica tanto a los ejecutores alojados en GitHub como a los autohospedados. Las variables que defines se convierten en propiedades en el contexto de `matrix` y puedes hacer referencia a la propiedad en otras áreas del archivo de flujo de trabajo. En este ejemplo, puedes usar `matrix.version` y `matrix.os` para acceder al valor actual de `version` y `os` que el trabajo utiliza. Para más información, consulta [Contextos de referencia](/es/actions/learn-github-actions/contexts). De forma predeterminada, GitHub maximizará el número de trabajos que se ejecutan en paralelo en función de la disponibilidad del ejecutor. El orden de las variables de la matriz determina el orden en el que se crean los trabajos. La primera variable que definas será el primer trabajo que se cree en tu ejecución de flujo de trabajo. ### Uso de una matriz de una sola dimensión En el flujo de trabajo siguiente se define la variable `version` con los valores `[10, 12, 14]`. El flujo de trabajo ejecutará tres trabajos, uno para cada valor de la variable. Cada trabajo tendrá acceso al valor `version` mediante el contexto `matrix.version` y pasará el valor como `node-version` a la acción `actions/setup-node`. ```yaml jobs: example_matrix: strategy: matrix: version: [10, 12, 14] steps: - uses: actions/setup-node@v4 with: node-version: ${{ matrix.version }} ``` ### Uso de una matriz multidimensional Especifica varias variables para crear una matriz multidimensional. Se ejecutará un trabajo para cada combinación posible de las variables. Por ejemplo, el flujo de trabajo siguiente especifica dos variables: * Dos sistemas operativos especificados en la variable `os` * Tres versiones de Node.js especificadas en la variable `version` El flujo de trabajo ejecutará seis trabajos, uno para cada combinación de las variables `os` y `version`. Cada trabajo establecerá el valor `runs-on` en el valor `os` actual y pasará el valor `version` actual a la acción `actions/setup-node`. ```yaml jobs: example_matrix: strategy: matrix: os: [ubuntu-22.04, ubuntu-24.04] version: [10, 12, 14] runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v4 with: node-version: ${{ matrix.version }} ``` Una configuración de variable en una matriz puede ser `array` de `object`. Por ejemplo, la matriz siguiente genera cuatro trabajos con los contextos correspondientes. ```yaml matrix: os: - ubuntu-latest - macos-latest node: - version: 14 - version: 20 env: NODE_OPTIONS=--openssl-legacy-provider ``` Cada trabajo de la matriz tendrá su propia combinación de valores `os` y `node`, como se muestra a continuación. ```yaml - matrix.os: ubuntu-latest matrix.node.version: 14 - matrix.os: ubuntu-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider - matrix.os: macos-latest matrix.node.version: 14 - matrix.os: macos-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider ``` ## `jobs..strategy.matrix.include` Para cada objeto de la lista `include`, los pares clave:valor del objeto se agregarán a cada una de las combinaciones de matriz si ninguno de los pares clave:valor sobrescribe ninguno de los valores de matriz originales. Si el objeto no se puede agregar a ninguna de las combinaciones de matriz, se creará una nueva combinación de matriz. Ten en cuenta que los valores originales de matriz no se sobrescribirán, mientras que los valores agregados de matriz sí se pueden sobrescribir. ### Ejemplo: Expansión de configuraciones Por ejemplo, el siguiente flujo de trabajo ejecutará cuatro trabajos, uno para cada combinación de `os` y `node`. Cuando se ejecute el trabajo para el valor de `os` de `windows-latest` y el valor de `node` de `16`, se incluirá en el trabajo una variable adicional denominada `npm` con el valor de `6`. ```yaml jobs: example_matrix: strategy: matrix: os: [windows-latest, ubuntu-latest] node: [14, 16] include: - os: windows-latest node: 16 npm: 6 runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v4 with: node-version: ${{ matrix.node }} - if: ${{ matrix.npm }} run: npm install -g npm@${{ matrix.npm }} - run: npm --version ``` ### Ejemplo: Incorporación de configuraciones Por ejemplo, esta matriz ejecutará 10 trabajos, uno para cada combinación de `os` y `version` en la matriz, además de un trabajo para el valor `os` de `windows-latest` y el valor `version` de `17`. ```yaml jobs: example_matrix: strategy: matrix: os: [macos-latest, windows-latest, ubuntu-latest] version: [12, 14, 16] include: - os: windows-latest version: 17 ``` Si no especificas ninguna variable de matriz, se ejecutarán todas las configuraciones de `include`. Por ejemplo, el siguiente flujo de trabajo ejecutaría dos trabajos, uno para cada entrada `include`. Esto permite aprovechar la estrategia de matriz sin tener una matriz totalmente rellenada. ```yaml jobs: includes_only: runs-on: ubuntu-latest strategy: matrix: include: - site: "production" datacenter: "site-a" - site: "staging" datacenter: "site-b" ``` ## `jobs..strategy.matrix.exclude` Una configuración excluida solo necesita coincidir parcialmente para ser excluida. Todas las combinaciones de `include` se procesan después de `exclude`. Esto le permite usar `include` para volver a agregar combinaciones previamente excluidas. ## `jobs..strategy.fail-fast` Puedes controlar cómo se manejan los errores de trabajo con `jobs..strategy.fail-fast` y `jobs..continue-on-error`. `jobs..strategy.fail-fast` se aplica a toda la matriz. Si `jobs..strategy.fail-fast` se establece en `true` o su expresión calcula hasta `true`, GitHub cancelará todos los trabajos en curso y en cola en la matriz si se produce un error de cualquiera de los trabajos de esta. El valor predeterminado de esta propiedad es `true`. `jobs..continue-on-error` se aplica a un solo trabajo. Si `jobs..continue-on-error` es `true`, el resto de los trabajos de la matriz seguirán ejecutándose aunque se produzca un error en el trabajo con `jobs..continue-on-error: true`. Puede usar `jobs..strategy.fail-fast` y `jobs..continue-on-error` de forma conjunta. Por ejemplo, el flujo de trabajo siguiente iniciará cuatro trabajos. En cada trabajo, `continue-on-error` se determina mediante el valor de `matrix.experimental`. Si se produce un error en alguno de los trabajos con `continue-on-error: false`, se cancelarán todos los trabajos en curso o en la cola. Si se produce un error en el trabajo con `continue-on-error: true`, el resto de trabajos no se verán afectados. ```yaml jobs: test: runs-on: ubuntu-latest continue-on-error: ${{ matrix.experimental }} strategy: fail-fast: true matrix: version: [6, 7, 8] experimental: [false] include: - version: 9 experimental: true ``` ## `jobs..strategy.max-parallel` De forma predeterminada, GitHub maximizará el número de trabajos que se ejecutan en paralelo en función de la disponibilidad del ejecutor. ## `jobs..continue-on-error` `jobs..continue-on-error` se aplica a un solo trabajo. Si `jobs..continue-on-error` es `true`, el resto de los trabajos de la matriz seguirán ejecutándose aunque se produzca un error en el trabajo con `jobs..continue-on-error: true`. Impide que una ejecución de flujo de trabajo falle cuando una tarea falla. Establézcalo en `true` para permitir que se supere una ejecución de flujo de trabajo cuando se produce un error en este trabajo. ### Ejemplo: Previniendo un job de matriz específico que falle desde una ejecución de flujo de trabajo que también falle Puedes permitir que ciertos jobs en una matriz de jobs fallen sin que la ejecución de flujo de trabajo falle. Por ejemplo, si desea permitir únicamente que un trabajo experimental con `node` configurado en `15` falle sin que ello provoque que falle la ejecución del flujo de trabajo. ```yaml runs-on: ${{ matrix.os }} continue-on-error: ${{ matrix.experimental }} strategy: fail-fast: false matrix: node: [13, 14] os: [macos-latest, ubuntu-latest] experimental: [false] include: - node: 15 os: ubuntu-latest experimental: true ``` ## `jobs..container` > \[!NOTE] > Si en los flujos de trabajo se usan acciones de contenedor de Docker, contenedores de trabajos o contenedores de servicios, deberás usar un ejecutor de Linux: > > * Si estás utilizando ejecutores hospedados en GitHub, debes utilizar un ejecutor de Ubuntu. > * Si estás utilizando ejecutores auto-hospedados, debes utilizar una máquina Linux como tu ejecutor, y ésta debe tener Docker instalado. Use `jobs..container` a fin de crear un contenedor para ejecutar cualquier paso de un trabajo que todavía no especifique un contenedor. Si tienes pasos que usan tanto acciones de script como de contenedor, las acciones de contenedor se ejecutarán como contenedores hermanos en la misma red con los mismos montajes de volumen. Si no configura un objeto `container`, todos los pasos se ejecutarán directamente en el host especificado por `runs-on`, a menos que un paso haga referencia a una acción configurada para ejecutarse en un contenedor. > \[!NOTE] > El shell predeterminado para los pasos `run` dentro de un contenedor es `sh` en lugar de `bash`. Esto se puede invalidar con [`jobs..defaults.run`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun) o [`jobs..steps[*].shell`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell). ### Ejemplo: Ejecución de un trabajo dentro de un contenedor ```yaml copy name: CI on: push: branches: [ main ] jobs: container-test-job: runs-on: ubuntu-latest container: image: node:18 env: NODE_ENV: development ports: - 80 volumes: - my_docker_volume:/volume_mount options: --cpus 1 steps: - name: Check for dockerenv file run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv) ``` Cuando solo especifique una imagen de contenedor, puede omitir la palabra clave `image`. ```yaml jobs: container-test-job: runs-on: ubuntu-latest container: node:18 ``` ## `jobs..container.image` Use `jobs..container.image` a fin de definir la imagen de Docker que usar como contenedor para ejecutar la acción. El valor puede ser el nombre de imagen de Docker Hub o un nombre de registro. > \[!NOTE] > Docker Hub normalmente impone límites de transferencia en las operaciones de inserción y extracción que afectarán a los trabajos en ejecutores autohospedados. Pero los ejecutores hospedados en GitHub no están sujetos a estos límites en función de un acuerdo entre GitHub y Docker. ## `jobs..container.credentials` Si el registro de contenedor de la imagen necesita la autenticación para extraer la imagen, puede usar `jobs..container.credentials` para establecer un valor `map` de `username` y `password`. Las credenciales son los mismos valores que se proporcionarían al comando [`docker login`](https://docs.docker.com/engine/reference/commandline/login/). ### Ejemplo: definir las credenciales para un registro de contenedores ```yaml container: image: ghcr.io/owner/image credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} ``` ## `jobs..container.env` Usa `jobs..container.env` para establecer un `map` de variables de entorno en el contenedor. ## `jobs..container.ports` Use `jobs..container.ports` para establecer un elemento `array` de puertos que se exponga en el contenedor. ## `jobs..container.volumes` Use `jobs..container.volumes` para establecer un valor `array` de volúmenes para que lo use contenedor. Puedes usar volúmenes para compartir datos entre servicios u otros pasos en un trabajo. Puedes especificar volúmenes Docker con nombre, volúmenes Docker anónimos o montajes de enlace en el host. Para especificar un volumen, especifica la ruta de origen y destino: `:`. `` es un nombre de volumen o una ruta absoluta en el equipo host y `` es una ruta absoluta en el contenedor. ### Ejemplo: Montaje de volúmenes en un contenedor ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..container.options` Use `jobs..container.options` para configurar opciones adicionales de recursos del contenedor de Docker. Para obtener una lista de opciones, consulta [Opciones de `docker create`](https://docs.docker.com/engine/reference/commandline/create/#options). > \[!WARNING] > Las opciones `--network` y `--entrypoint` no se admiten. ## `jobs..services` > \[!NOTE] > Si en los flujos de trabajo se usan acciones de contenedor de Docker, contenedores de trabajos o contenedores de servicios, deberás usar un ejecutor de Linux: > > * Si estás utilizando ejecutores hospedados en GitHub, debes utilizar un ejecutor de Ubuntu. > * Si estás utilizando ejecutores auto-hospedados, debes utilizar una máquina Linux como tu ejecutor, y ésta debe tener Docker instalado. Se usa para hospedar contenedores de servicio para una tarea dentro de un flujo de trabajo. Los contenedores de servicio son útiles para crear bases de datos o servicios de caché como Redis. El ejecutor crea automáticamente una red Docker y administra el ciclo de vida de los contenedores de servicio. Si configuras tu trabajo para que se ejecute en un contenedor, o si tu paso usa acciones del contenedor, no necesitas asignar puertos para acceder al servicio o a la acción. Docker expone automáticamente todos los puertos entre contenedores en la misma red de puente definida por el usuario de Docker. Puedes hacer referencia directamente al contenedor de servicio por su nombre de host. El nombre del host se correlaciona automáticamente con el nombre de la etiqueta que configuraste para el servicio en el flujo de trabajo. Si configuras el trabajo para que se ejecute directamente en la máquina del ejecutor y tu paso no usa una acción de contenedor, debes asignar cualquier puerto del contenedor de servicio Docker que sea necesario para el host Docker (la máquina del ejecutor). Puedes acceder al contenedor de servicio utilizando host local y el puerto asignado. Para más información sobre las diferencias entre los contenedores de servicios de red, consulta [Comunicación con contenedores de servicios de Docker](/es/actions/using-containerized-services/about-service-containers). ### Ejemplo: Utilizando al host local Este ejemplo crea dos servicios: nginx y Redis. Cuando se especifica el puerto del contenedor pero no el puerto del host, el puerto del contenedor se asigna aleatoriamente a un puerto libre del host. GitHub establece el puerto de host asignado en el `${{job.services..ports}}` contexto. En este ejemplo, puede acceder a los puertos del host de servicio utilizando los contextos `${{ job.services.nginx.ports['80'] }}` y `${{ job.services.redis.ports['6379'] }}`. ```yaml services: nginx: image: nginx # Map port 8080 on the Docker host to port 80 on the nginx container ports: - 8080:80 redis: image: redis # Map random free TCP port on Docker host to port 6379 on redis container ports: - 6379/tcp steps: - run: | echo "Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}" echo "Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}" ``` ## `jobs..services..image` La imagen Docker a utilizar como un contenedor de servicio para ejecutar la acción. El valor puede ser el nombre de la imagen de Docker Hub o un nombre de registro. Si a `jobs..services..image` se le asigna una cadena vacía, el servicio no se iniciará. Puedes usarlo para configurar servicios condicionales, de forma similar al ejemplo siguiente. ```yaml services: nginx: image: ${{ options.nginx == true && 'nginx' || '' }} ``` ## `jobs..services..credentials` Si el registro de contenedor de la imagen necesita la autenticación para extraer la imagen, puede usar `jobs..container.credentials` para establecer un valor `map` de `username` y `password`. Las credenciales son los mismos valores que se proporcionarían al comando [`docker login`](https://docs.docker.com/engine/reference/commandline/login/). ### Ejemplo de `jobs..services..credentials` ```yaml services: myservice1: image: ghcr.io/owner/myservice1 credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} myservice2: image: dockerhub_org/myservice2 credentials: username: ${{ secrets.DOCKER_USER }} password: ${{ secrets.DOCKER_PASSWORD }} ``` ## `jobs..services..env` Establece un valor `map` de variables de entorno en el contenedor de servicios. ## `jobs..services..ports` Establece un valor `array` de puertos que se van a exponer en el contenedor de servicios. ## `jobs..services..volumes` Establece un valor `array` de volúmenes para el contenedor de servicios. Puedes usar volúmenes para compartir datos entre servicios u otros pasos en un trabajo. Puedes especificar volúmenes Docker con nombre, volúmenes Docker anónimos o montajes de enlace en el host. Para especificar un volumen, especifica la ruta de origen y destino: `:`. `` es un nombre de volumen o una ruta absoluta en el equipo host y `` es una ruta absoluta en el contenedor. ### Ejemplo de `jobs..services..volumes` ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..services..options` Opciones adicionales de recursos del contenedor Docker. Para obtener una lista de opciones, consulta [`docker create` opciones](https://docs.docker.com/engine/reference/commandline/create/#options). > \[!WARNING] > La opción `--network` no es compatible. ## `jobs..services..command` Invalida el comando predeterminado de la imagen de Docker (`CMD`). El valor se pasa como argumentos después del nombre de la imagen en el comando `docker create`. Si también especifica `entrypoint`, `command` proporciona los argumentos a ese punto de entrada. ### Ejemplo de `jobs..services..command` ```yaml services: mysql: image: mysql:8 command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M env: MYSQL_ROOT_PASSWORD: test ports: - 3306:3306 ``` ## `jobs..services..entrypoint` Invalida el valor predeterminado `ENTRYPOINT`de la imagen de Docker. El valor es una cadena única que define el ejecutable que se va a ejecutar. Úselo cuando necesite reemplazar completamente el punto de entrada de la imagen. Puede combinar `entrypoint` con `command` para pasar argumentos al punto de entrada personalizado. ### Ejemplo de `jobs..services..entrypoint` ```yaml services: etcd: image: quay.io/coreos/etcd:v3.5.17 entrypoint: etcd command: >- --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379 ports: - 2379:2379 ``` ## `jobs..uses` La ubicación y versión de un archivo de flujo de trabajo reutilizable para ejecutar como una tarea. Utiliza una de las siguientes sintaxis: * `{owner}/{repo}/.github/workflows/{filename}@{ref}` para flujos de trabajo reutilizables en repositorios públicos y privados. * `./.github/workflows/{filename}` para flujos de trabajo reutilizables en el mismo repositorio. En la primera opción, `{ref}` puede ser un SHA, una etiqueta de lanzamiento o un nombre de rama. Si una etiqueta de versión y una rama tienen el mismo nombre, la primera tiene prioridad sobre el nombre de la rama. Utilizar el SHA de la confirmación es la opción más segura para lograr estabilidad y seguridad. Para más información, consulta [Referencia de uso seguro](/es/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows). Si usas la segunda opción de sintaxis (sin `{owner}/{repo}` y `@{ref}`), el flujo de trabajo que se llama procede de la misma confirmación que el flujo de trabajo autor de la llamada. No se permiten prefijos de referencia como `refs/heads` y `refs/tags`. No puedes utilizar contextos o expresiones en esta palabra clave. ### Ejemplo de `jobs..uses` ```yaml jobs: call-workflow-1-in-local-repo: uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89 call-workflow-2-in-local-repo: uses: ./.github/workflows/workflow-2.yml call-workflow-in-another-repo: uses: octo-org/another-repo/.github/workflows/workflow.yml@v1 ``` Para más información, consulta [Reutilización de flujos de trabajo](/es/actions/using-workflows/reusing-workflows). ## `jobs..with` Cuando se utiliza un trabajo para invocar un flujo de trabajo reutilizable, puede usar `with` para proporcionar un mapa de entradas que se pasan al flujo de trabajo llamado. Cualquier entrada que pases debe coincidir con las especificaciones de la entrada que se define en el flujo de trabajo llamado. A diferencia de [`jobs..steps[*].with`](#jobsjob_idstepswith), las entradas que se pasan con `jobs..with` no están disponibles como variables de entorno en el flujo de trabajo llamado. En su lugar, puede hacer referencia a las entradas mediante el contexto `inputs`. ### Ejemplo de `jobs..with` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main with: username: mona ``` ## `jobs..with.` Un par que consiste de un identificador de secuencias para la entrada y del valor de entrada. El identificador debe coincidir con el nombre de una entrada definida por [`on.workflow_call.inputs.`](/es/actions/creating-actions/metadata-syntax-for-github-actions#inputsinput_id) en el flujo de trabajo llamado. El tipo de datos del valor debe coincidir con el tipo definido por [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype) en el flujo de trabajo llamado. Contextos de expresión permitidos: `github` y `needs`. ## `jobs..secrets` Cuando se utiliza un trabajo para llamar a un flujo de trabajo reutilizable, puede usar `secrets` para proporcionar un mapa de secretos que se pasen al flujo de trabajo llamado. Cualquier secreto que pases debe coincidir con los nombres que se definen en el flujo de trabajo llamado. ### Ejemplo de `jobs..secrets` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main secrets: access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} ``` ## `jobs..secrets.inherit` Usa la palabra clave `inherit` para pasar todos los secretos del flujo de trabajo que realiza la llamada al flujo de trabajo llamado. Esto incluye todos los secretos a los que tiene acceso el flujo de trabajo que realiza la llamada, es decir, los secretos de la organización, al repositorio y el entorno. La palabra clave `inherit` se puede usar para pasar secretos entre repositorios de la misma organización o entre organizaciones de la misma empresa. ### Ejemplo de `jobs..secrets.inherit` ```yaml on: workflow_dispatch: jobs: pass-secrets-to-workflow: uses: ./.github/workflows/called-workflow.yml secrets: inherit ``` ```yaml on: workflow_call: jobs: pass-secret-to-action: runs-on: ubuntu-latest steps: - name: Use a repo or org secret from the calling workflow. run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }} ``` ## `jobs..secrets.` Un par que consiste de un identificador de secuencias para el secreto y el valor de dicho secreto. El identificador debe coincidir con el nombre de un secreto definido por [`on.workflow_call.secrets.`](#onworkflow_callsecretssecret_id) en el flujo de trabajo llamado. Contextos de expresión permitidos: `github`, `needs` y `secrets`. ## Guía rápida de patrones de filtro Puedes usar caracteres especiales en los filtros de ruta, de rama y de etiqueta. * `*`: coincide con cero o más caracteres, pero no coincide con el carácter `/`. Por ejemplo, `Octo*` coincide con `Octocat`. * `**`: coincide con cero o más repeticiones de cualquier carácter. * `?`: coincide con cero o una repetición del carácter anterior. * `+`: coincide con cero o más repeticiones del carácter anterior. * `[]` coincide con un carácter alfanumérico que aparece en los corchetes o que se incluye en los rangos. Los rangos solo pueden incluir `a-z`, `A-Z`y `0-9`. Por ejemplo, el rango `[0-9a-z]` coincide con cualquier dígito o letra minúscula. Por ejemplo, `[CB]at` coincide con `Cat` o `Bat`, y `[1-2]00` coincide con `100` y `200`. * `!`: al comienzo de un patrón hace que se nieguen los patrones positivos anteriores. No tiene ningún significado especial si no es el primer caracter. Los caracteres `*`, `[` y `!` son caracteres especiales en YAML. Si inicia un patrón con `*`, `[` o `!`, debe incluirlo entre comillas. Además, si usas una [secuencia de flujo](https://yaml.org/spec/1.2.2/#flow-sequences) con un patrón que contiene `[` o `]`, este patrón debe incluirse entre comillas. ```yaml # Valid paths: - '**/README.md' # Invalid - creates a parse error that # prevents your workflow from running. paths: - **/README.md # Valid branches: [ main, 'release/v[0-9].[0-9]' ] # Invalid - creates a parse error branches: [ main, release/v[0-9].[0-9] ] ``` Para más información sobre la sintaxis de filtro de rama, etiqueta y ruta, consulta [`on..`](#onpushbranchestagsbranches-ignoretags-ignore), [`on..`](#onpull_requestpull_request_targetbranchesbranches-ignore) y [`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore). ### Patrones para encontrar ramas y etiquetas | Patrón | Descripción | Coincidencias de ejemplo | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | `feature/*` | El carácter comodín `*` coincide con cualquier carácter, pero no con la barra diagonal (`/`). | `feature/my-branch`

`feature/your-branch` | | `feature/**` | El carácter comodín `**` coincide con cualquier carácter, incluida la barra diagonal (`/`) en los nombres de rama y etiqueta. | `feature/beta-a/my-branch`

`feature/your-branch`

`feature/mona/the/octocat` | | `main`

`releases/mona-the-octocat` | Coincide con el nombre exacto de una rama o de una etiqueta. | `main`

`releases/mona-the-octocat` | | `'*'` | Coincide con todos los nombres de rama o de etiqueta que no contienen una barra diagonal (`/`). El carácter `*` es un carácter especial en YAML. Al iniciar un patrón con `*`, debe usar comillas. | `main`

`releases` | | `'**'` | Coincide con todos los nombres de ramas y etiquetas. Este es el comportamiento predeterminado cuando no se usa un filtro `branches` o `tags`. | `all/the/branches`

`every/tag` | | `'*feature'` | El carácter `*` es un carácter especial en YAML. Al iniciar un patrón con `*`, debe usar comillas. | `mona-feature`

`feature`

`ver-10-feature` | | `v2*` | Coincide con los nombres de rama y etiqueta que comienzan por `v2`. | `v2`

`v2.0`

`v2.9` | | `v[12].[0-9]+.[0-9]+` | Coincide con todas las etiquetas y ramas de versionamiento semántico con la versión principal 1 o 2. | `v1.10.1`

`v2.0.0` | ### Patrones para encontrar rutas de archivos Los patrones de ruta deben coincidir con toda la ruta y comenzar desde la raíz del repositorio. | Patrón | Descripción de coincidencias | Coincidencias de ejemplo | | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | `'*'` | El carácter comodín `*` coincide con cualquier carácter, pero no con la barra diagonal (`/`). El carácter `*` es un carácter especial en YAML. Al iniciar un patrón con `*`, debe usar comillas. | `README.md`

`server.rb` | | `'*.jsx?'` | El carácter `?` coincide con cero o uno del carácter anterior. | `page.js`

`page.jsx` | | `'**'` | El carácter comodín `**` coincide con cualquier carácter, incluida la barra diagonal (`/`). Este es el comportamiento predeterminado cuando no se usa un filtro `path`. | `all/the/files.md` | | `'*.js'` | El carácter comodín `*` coincide con cualquier carácter, pero no con la barra diagonal (`/`). Coincide con todos los archivos `.js` en la raíz del repositorio. | `app.js`

`index.js` | | `'**.js'` | Coincide con todos los archivos `.js` en el repositorio. | `index.js`

`js/index.js`

`src/js/app.js` | | `docs/*` | Todos los archivos dentro de la raíz del directorio `docs` únicamente, en la raíz del repositorio. | `docs/README.md`

`docs/file.txt` | | `docs/**` | Cualquier archivo del directorio `docs` y sus subdirectorios en la raíz del repositorio. | `docs/README.md`

`docs/mona/octocat.txt` | | `docs/**/*.md` | Un archivo con un sufijo `.md` en cualquier parte del directorio `docs`. | `docs/README.md`

`docs/mona/hello-world.md`

`docs/a/markdown/file.md` | | `'**/docs/**'` | Todos los archivos de un directorio `docs` en cualquier parte del repositorio. | `docs/hello.md`

`dir/docs/my-file.txt`

`space/docs/plan/space.doc` | | `'**/README.md'` | Un archivo README.md en cualquier parte del repositorio. | `README.md`

`js/README.md` | | `'**/*src/**'` | Cualquier archivo de una carpeta con un sufijo `src` en cualquier parte del repositorio. | `a/src/app.js`

`my-src/code/js/app.js` | | `'**/*-post.md'` | Un archivo con el sufijo `-post.md` en cualquier parte del repositorio. | `my-post.md`

`path/their-post.md` | | `'**/migrate-*.sql'` | Un archivo con el prefijo `migrate-` y el sufijo `.sql` en cualquier parte del repositorio. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` | | `'*.md'`

`'!README.md'` | El uso de una signo de exclamación (`!`) delante de un patrón lo niega. Cuando un archivo coincida con un patrón y también coincida con un patrón negativo definido más adelante en el archivo, no se incluirá el archivo. | `hello.md`

| | *No coincide*

`README.md`

`docs/hello.md` | | | | `'*.md'`

`'!README.md'`

`README*` | Los patrones se verifican de forma secuencial. Un patrón que niega un patrón previo volverá a incluir las rutas del archivo. | `hello.md`

`README.md`

`README.doc` |