{"meta":{"title":"Activar un flujo de trabajo","intro":"Cómo activar automáticamente GitHub Actions flujos de trabajo","product":"GitHub Actions","breadcrumbs":[{"href":"/es/actions","title":"GitHub Actions"},{"href":"/es/actions/how-tos","title":"Procedimientos"},{"href":"/es/actions/how-tos/write-workflows","title":"Escribir flujos de trabajo"},{"href":"/es/actions/how-tos/write-workflows/choose-when-workflows-run","title":"Elegir cuándo se ejecutan los flujos de trabajo"},{"href":"/es/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow","title":"Desencadenamiento de un flujo de trabajo"}],"documentType":"article"},"body":"# Activar un flujo de trabajo\n\nCómo activar automáticamente GitHub Actions flujos de trabajo\n\n## Requisitos previos\n\nPara más información sobre los flujos de trabajo y el desencadenamiento de flujos de trabajo, consulta [Flujos de trabajo](/es/actions/concepts/workflows-and-actions/workflows).\n\n## Activar un flujo de trabajo desde otro flujo de trabajo\n\nCuando se usa el repositorio `GITHUB_TOKEN` para realizar tareas, los eventos desencadenados por `GITHUB_TOKEN` no crearán una nueva ejecución de flujo de trabajo, con las siguientes excepciones:\n\n* `workflow_dispatch` y `repository_dispatch` los eventos siempre crean ejecuciones de flujo de trabajo.\n* ```\n            Eventos `pull_request` con los tipos de actividad `opened`, `synchronize` o `reopened`: cuando un flujo de trabajo que utiliza `GITHUB_TOKEN` crea o actualiza una solicitud de incorporación de cambios, el evento `pull_request` resultante genera ejecuciones de flujo de trabajo en estado de **aprobación obligatoria**. La solicitud de incorporación de cambios muestra un banner en el cuadro de combinación, y un usuario con acceso de escritura al repositorio puede iniciar las ejecuciones seleccionando **Aprobar flujos de trabajo para ejecutar**. Otros `pull_request` tipos de actividad (como `labeled`, `edited`o `closed`) no crean ejecuciones de flujo de trabajo. Esto evita que ejecuciones de flujo de trabajo recursivas a tiempo que se permite que se ejecuten flujos de trabajo de CI en las solicitudes de incorporación de cambios creadas por automatización. Para obtener más información sobre cómo aprobar ejecuciones de flujo de trabajo, consulte [AUTOTITLE](/actions/how-tos/manage-workflow-runs/approve-runs-from-forks).\n  ```\n\nPara todos los demás eventos, este comportamiento impide que cree accidentalmente ejecuciones de flujo de trabajo recursivas. Por ejemplo, si una ejecución de flujo de trabajo inserta código mediante `GITHUB_TOKEN` del repositorio, un nuevo flujo de trabajo no se ejecutará incluso cuando el repositorio contenga un flujo de trabajo configurado para ejecutarse cuando se produzcan eventos `push`. Para obtener más información, consulte [Uso de GITHUB\\_TOKEN para la autenticación en flujos de trabajo](/es/actions/tutorials/authenticate-with-github_token).\n\nSi quiere activar un flujo de trabajo desde la ejecución de otro flujo de trabajo, puede usar un GitHub App token de acceso de la instalación o un personal access token en lugar de `GITHUB_TOKEN` para activar eventos que requieran un token. Usar una de estas alternativas también permite que `pull_request` los flujos de trabajo se ejecuten automáticamente (sin la solicitud de aprobación descrita anteriormente) cuando el pull request es creado o actualizado por la automatización.\n\nSi utiliza un GitHub App, tendrá que crear un GitHub App y almacenar el identificador de la aplicación y la clave privada como secretos. 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/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). Si utiliza un personal access token, deberá crear un personal access token y guardarlo como secreto. Para obtener más información sobre cómo crear un personal access token, vea [Administración de tokens de acceso personal](/es/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). Para obtener más información sobre cómo almacenar secretos, consulta [Uso de secretos en Acciones de GitHub](/es/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\nPara minimizar los GitHub Actions costos de uso, asegúrese de que no cree ejecuciones de flujo de trabajo recursivas o no deseadas.\n\nPor ejemplo, el siguiente flujo de trabajo usa un personal access token (almacenado como un secreto denominado `MY_TOKEN`) para agregar una etiqueta a una incidencia mediante GitHub CLI. Cualquier flujo de trabajo que se ejecute cuando se agregue una etiqueta se ejecutará una vez que se realice este paso.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.MY_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\nPor su parte, el siguiente flujo de trabajo usa `GITHUB_TOKEN` para agregar una etiqueta a una incidencia. No activará ningún flujo de trabajo que se ejecute cuando se agregue una etiqueta.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\n## Utilizar eventos para activar flujos de trabajo\n\nUse la clave `on` para especificar qué eventos desencadenan el flujo de trabajo. Para obtener más información sobre los eventos que puedes usar, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n### Utilizar un único evento\n\nPor 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:\n\n```yaml\non: push\n```\n\n### Utilizar eventos múltiples\n\nPuedes 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:\n\n```yaml\non: [push, fork]\n```\n\nSi 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.\n\n### Uso de tipos de actividad y filtros con eventos múltiples\n\nPuedes utilizar tipos de actividad y filtros para controlar aún más cuándo se ejecutará tu flujo de trabajo. Para obtener más información, vea [Uso de tipos de actividad de eventos](#using-event-activity-types) y [Uso de filtros](#using-filters). 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.\n\nPor ejemplo, un flujo de trabajo con el valor `on` siguiente se ejecutará cuando:\n\n* Se crea una etiqueta\n* Se hace una inserción a la rama `main` en el repositorio.\n* Se hace una subida a la rama habilitada por GitHub Pages\n\n```yaml\non:\n  label:\n    types:\n      - created\n  push:\n    branches:\n      - main\n  page_build:\n```\n\n## Utilizar tipos de actividad de eventos\n\nAlgunos eventos tienen tipos de actividad que te proporcionan más control sobre cuándo debería ejecutarse tu flujo de trabajo. Use `on.<event_name>.types` para definir el tipo de actividad de evento que desencadenará una ejecución de flujo de trabajo.\n\nPor 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.\n\n```yaml\non:\n  label:\n    types:\n      - created\n```\n\nSi 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 se etiqueta una incidencia. Si se abre una incidencia con dos etiquetas, se iniciarán tres ejecuciones de flujo de trabajo: una para el evento de apertura de la incidencia y dos para los dos eventos de etiquetado de la incidencia.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n      - labeled\n```\n\nPara más información sobre cada evento y sus tipos de actividad, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n## Utilizar filtros\n\nAlgunos eventos tienen filtros que te dan más control sobre qué flujo de trabajo debería ejecutarse.\n\nPor 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.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n      - 'releases/**'\n```\n\n### Utilizar filtros para apuntar a ramas específicas para los eventos de solicitudes de cambios\n\nAl 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.\n\nUse 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.\n\nSi defines `branches`/`branches-ignore` y [`paths`/`paths-ignore`](/es/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), el flujo de trabajo solo se ejecutará cuando se cumplan ambos filtros.\n\nLas 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/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Ejemplo: Incluyendo ramificaciones\n\nLos 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:\n\n* Una rama denominada `main` (`refs/heads/main`)\n* Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`)\n* Una rama cuyo nombre comienza por `releases/`, como `releases/10` (`refs/heads/releases/10`)\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n```\n\nSi se omite un flujo de trabajo debido al filtrado de ramas, al [filtrado de rutas de acceso](/es/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) o a un [mensaje de confirmación](/es/actions/how-tos/manage-workflow-runs/skip-workflow-runs), las comprobaciones asociadas a ese flujo de trabajo permanecerán en estado \"Pendiente\". Se bloqueará la combinación de una solicitud de cambios que requiera que esas comprobaciones se superen correctamente.\n\n#### Ejemplo: Excluir ramas\n\nCuando 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:\n\n* Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`)\n* Una rama cuyo nombre coincide con `releases/**-alpha`, como `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n```\n\n#### Ejemplo: Incluir y excluir ramas\n\nNo 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.\n\nSi 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.\n\nEl orden en que defines los patrones importa.\n\n* Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva hará que se excluya la referencia de Git.\n* Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git.\n\nEl 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. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Utilizar filtros para apuntar a ramas o etiquetas específicas para los eventos de subida\n\nAl usar el evento `push`, puede configurar un flujo de trabajo para que se ejecute en ramas o etiquetas específicas.\n\nUse 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.\n\nUse 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.\n\nSi 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/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), el flujo de trabajo solo se ejecutará cuando se cumplan ambos filtros.\n\nLas 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/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Ejemplo: Incluyendo ramas y etiquetas\n\nLos 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:\n\n* Una rama denominada `main` (`refs/heads/main`)\n* Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`)\n* Una rama cuyo nombre comienza por `releases/`, como `releases/10` (`refs/heads/releases/10`)\n* Una etiqueta denominada `v2` (`refs/tags/v2`)\n* Una etiqueta cuyo nombre comienza por `v1.`, como `v1.9.1` (`refs/tags/v1.9.1`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n    # Sequence of patterns matched against refs/tags\n    tags:\n      - v2\n      - v1.*\n```\n\n#### Ejemplo: Excluir ramas y etiquetas\n\nCuando 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:\n\n* Una rama denominada `mona/octocat` (`refs/heads/mona/octocat`)\n* Una rama cuyo nombre coincide con `releases/**-alpha`, como `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n* Una etiqueta denominada `v2` (`refs/tags/v2`)\n* Una etiqueta cuyo nombre comienza por `v1.`, como `v1.9` (`refs/tags/v1.9`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n    # Sequence of patterns matched against refs/tags\n    tags-ignore:\n      - v2\n      - v1.*\n```\n\n#### Ejemplo: incluir y excluir ramas y etiquetas\n\nNo 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.\n\nSi 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.\n\nEl orden en que defines los patrones importa.\n\n* Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva hará que se excluya la referencia de Git.\n* Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git.\n\nEl 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. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  push:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Utilizar filtros para apuntar a rutas específicas para los eventos de subida o solicitudes de cambios\n\nAl 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.\n\nUsa 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.\n\n> \\[!NOTE]\n> El orden en que defines los patrones `paths` importa:\n>\n> * Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva excluirá la ruta de acceso.\n> * Un patrón positivo después de una coincidencia negativa volverá a incluir la ruta.\n\nSi define `branches`/`branches-ignore` y `paths`/`paths-ignore`, el flujo de trabajo solo se ejecutará cuando se cumplan los dos filtros.\n\nLas palabras clave `paths` y `paths-ignore` aceptan patrones glob que usan los caracteres comodín `*` y `**` para hacer coincidir varios nombres de ruta. Para obtener más información, consulta el [Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Ejemplo: Incluir rutas\n\nSi al menos una ruta de acceso coincide con un patrón en el filtro `paths`, se ejecuta el flujo de trabajo. Por ejemplo, el siguiente flujo de trabajo se ejecutaría cada vez que hagas push de un archivo JavaScript (`.js`).\n\n```yaml\non:\n  push:\n    paths:\n      - '**.js'\n```\n\nSi se omite un flujo de trabajo debido al filtrado de rutas de acceso, al [filtrado de ramas](/es/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) o a un [mensaje de confirmación](/es/actions/how-tos/manage-workflow-runs/skip-workflow-runs), las comprobaciones asociadas a ese flujo de trabajo permanecerán en estado \"Pendiente\". Se bloqueará la combinación de una solicitud de cambios que requiera que esas comprobaciones se superen correctamente.\n\n#### Ejemplo: Exclusión de rutas de acceso\n\nCuando 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á.\n\nUn 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.\n\n```yaml\non:\n  push:\n    paths-ignore:\n      - 'docs/**'\n```\n\n#### Ejemplo: Inclusión y exclusión de rutas\n\nNo 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.\n\nSi 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.\n\nEl orden en que defines los patrones `paths` importa:\n\n* 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.\n* Un patrón de coincidencia positiva luego de una coincidencia negativa excluirá nuevamente la ruta.\n\nEste 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á.\n\n```yaml\non:\n  push:\n    paths:\n      - 'sub-project/**'\n      - '!sub-project/docs/**'\n```\n\n#### Comparaciones de diferencias de Git\n\nEl 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.\n\nGitHub genera la lista de archivos modificados utilizando comparaciones de dos puntos para los envíos y de tres puntos para las solicitudes de incorporación de cambios:\n\n* **Solicitudes de extracción:** Las comparaciones de tres puntos son una comparación entre la versión más reciente de la rama temática y la confirmación en la que la rama temática se sincronizó por última vez con la rama base.\n* **Envíos a ramas existentes:** Una comparación de dos puntos compara directamente entre sí los SHA de la cabeza y de la base.\n* **Envíos a nuevas ramas:** Una comparación de dos puntos con respecto a la rama principal del antepasado de la confirmación más reciente enviada.\n\nEn algunas situaciones, GitHub Actions aplica límites que cambian cómo se ejecutan los flujos de trabajo filtrados:\n\n* Si un push contiene más de 1.000 commits, el flujo de trabajo **siempre** se ejecutará.\n* Si se agota el tiempo de espera al generar la comparación, el flujo de trabajo se ejecutará **siempre**.\n* Si el diff generado contiene más de 3.000 archivos y los archivos con los que coincide el filtro del flujo de trabajo no están entre los primeros 3.000 devueltos por el filtro, el flujo de trabajo **no** se ejecutará.\n\nSi observas estos comportamientos, es posible que tengas que hacer tus filtros más específicos o cambiar la forma en que trabajas con los envíos y las solicitudes de incorporación de cambios para generar comparaciones más sencillas.\n\nPara más información, consulta [Ramas](/es/pull-requests/reference/branches).\n\n### Utilizar filtros para apuntar a ramas específicas para los eventos de ejecución de flujos de trabajo\n\nCuando utilice el evento `workflow_run`, puede especificar en qué ramas debe ejecutarse el flujo de trabajo que lo desencadena para desencadenar su flujo de trabajo.\n\nLos 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/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\nPor 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/`:\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n```\n\nUn flujo de trabajo con el siguiente desencadenador solo se ejecutará cuando el flujo de trabajo llamado `Build` se ejecute en una rama que no se llame `canary`:\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches-ignore:\n      - \"canary\"\n```\n\nNo 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.\n\nEl orden en que defines los patrones importa.\n\n* Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva excluirá la rama.\n* El tener un patrón de coincidencia positivo después de una coincidencia negativa hará que se incluya la rama nuevamente.\n\nPor ejemplo, un flujo de trabajo con el siguiente activador se ejecutará cuando el flujo de trabajo llamado `Build` se ejecute en una rama cuyo nombre sea `releases/10` o `releases/beta/mona`, pero no lo hará en `releases/10-alpha`, `releases/beta/3-alpha` ni `main`. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## Definir entradas para los flujos de trabajo que se activan manualmente\n\nCuando se usa el evento `workflow_dispatch`, puede especificar opcionalmente entradas que se pasan al flujo de trabajo.\n\nEste desencadenador solo recibe eventos cuando el archivo de flujo de trabajo está en la rama predeterminada.\nEl flujo de trabajo desencadenado recibe las entradas en el contexto `inputs`. Para más información, consulta [Contextos](/es/actions/reference/workflows-and-actions/contexts#inputs-context).\n\n> \\[!NOTE]\n>\n> * 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.\n> * El número máximo de propiedades de nivel superior para `inputs` es 25 .\n> * La carga máxima de `inputs` es de 65 535 caracteres.\n\n```yaml\non:\n  workflow_dispatch:\n    inputs:\n      logLevel:\n        description: 'Log level'\n        required: true\n        default: 'warning'\n        type: choice\n        options:\n          - info\n          - warning\n          - debug\n      print_tags:\n        description: 'True to print to STDOUT'\n        required: true\n        type: boolean\n      tags:\n        description: 'Test scenario tags'\n        required: true\n        type: string\n      environment:\n        description: 'Environment to run tests against'\n        type: environment\n        required: true\n\njobs:\n  print-tag:\n    runs-on: ubuntu-latest\n    if: ${{ inputs.print_tags }} \n    steps:\n      - name: Print the input tag to STDOUT\n        run: echo  The tags are ${{ inputs.tags }} \n```\n\n## Definir entradas, salidas y secretos para los flujos de trabajo reutilizables\n\nPuedes definir entradas y secretos que deben recibir los flujos de trabajo reutilizables desde un flujo de trabajo llamante. También puedes especificar las salidas que un flujo de trabajo reutilizable pondrá a disposición de un flujo de trabajo que lo llama. Para más información, consulta [Reutilización de flujos de trabajo](/es/actions/how-tos/reuse-automations/reuse-workflows).\n\n## Utilizar la información de los eventos\n\nLa información sobre el evento que ha desencadenado una ejecución de flujo de trabajo está disponible en el contexto `github.event`. Las propiedades del contexto `github.event` dependen del tipo de evento que ha desencadenado el flujo de trabajo. Por ejemplo, un flujo de trabajo que se activa cuando se etiqueta una incidencia tendría información sobre la incidencia y la etiqueta.\n\n### Ver todas las propiedades de un evento\n\nReferencia la documentación de evento de webhook para las propiedades comunes y cargas útiles de ejemplo. Para más información, consulta [Eventos y cargas de webhook](/es/webhooks/webhook-events-and-payloads).\n\nTambién puede imprimir todo el contexto `github.event` para ver qué propiedades están disponibles para el evento que ha desencadenado el flujo de trabajo:\n\n```yaml\njobs:\n  print_context:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          EVENT_CONTEXT: ${{ toJSON(github.event) }}\n        run: |\n          echo $EVENT_CONTEXT\n```\n\n### Acceder y utilizar las propiedades de evento\n\nPuede usar el contexto `github.event` en el flujo de trabajo. Por ejemplo, el siguiente flujo de trabajo se ejecuta cuando se abre un pull request que cambia `package*.json`, `.github/CODEOWNERS` o `.github/workflows/**`. Si el autor de la solicitud de extracción (`github.event.pull_request.user.login`) no es `octobot` ni `dependabot[bot]`, el flujo de trabajo usa GitHub CLI para etiquetar y comentar la solicitud de extracción (`github.event.pull_request.number`).\n\n```yaml\non:\n  pull_request:\n    types:\n      - opened\n    paths:\n      - '.github/workflows/**'\n      - '.github/CODEOWNERS'\n      - 'package*.json'\n\njobs:\n  triage:\n    if: >-\n      github.event.pull_request.user.login != 'octobot' &&\n      github.event.pull_request.user.login != 'dependabot[bot]'\n    runs-on: ubuntu-latest\n    steps:\n      - name: \"Comment about changes we can't accept\"\n        env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          PR: ${{ github.event.pull_request.html_url }}\n        run: |\n          gh pr edit $PR --add-label 'invalid'\n          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'\n```\n\nPara obtener más información sobre los contextos, consulta [Contextos de referencia](/es/actions/reference/workflows-and-actions/contexts). Para obtener más información sobre la carga de datos de los eventos, consulta [Eventos y cargas de webhook](/es/webhooks/webhook-events-and-payloads).\n\n## Controlar aún más la forma en la que se ejecutará tu flujo de trabajo\n\nSi quieres un control más pormenorizado que el que proporcionan los eventos, los tipos de actividad de eventos o los filtros de eventos, puedes utilizar condicionales y entornos para controlar si se ejecutarán trabajos o pasos individuales en el flujo de trabajo.\n\n### Utilizar condicionales\n\nPuedes utilizar condicionales para tener un mayor control sobre si se ejecutarán los trabajos o pasos de tu flujo de trabajo.\n\n#### Ejemplo utilizando un valor en la carga útil del evento\n\nPor ejemplo, si quiere que el flujo de trabajo se ejecute cuando se agregue una etiqueta específica a una incidencia, puede desencadenar el tipo de actividad de evento `issues labeled` y usar un condicional para comprobar qué etiqueta ha desencadenado el flujo de trabajo. El siguiente flujo de trabajo se ejecutará cuando se agregue cualquier etiqueta a una incidencia en el repositorio del flujo de trabajo, pero el trabajo `run_if_label_matches` solo se ejecutará si la etiqueta se denomina `bug`.\n\n```yaml\non:\n  issues:\n    types:\n      - labeled\n\njobs:\n  run_if_label_matches:\n    if: github.event.label.name == 'bug'\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo 'The label was bug'\n```\n\n#### Ejemplo utilizando un tipo de evento\n\nPor ejemplo, si quieres ejecutar jobs o pasos diferentes dependiendo de qué evento activó el flujo de trabajo, puedes utilizar una condicional para verificar si un tipo de evento específico existe en el contexto del mismo. El siguiente flujo de trabajo se ejecutará cada que se cierre una propuesta o solicitud de cambios. Si el flujo de trabajo se ha ejecutado porque se ha cerrado una incidencia, el contexto `github.event` contendrá un valor para `issue`, pero no para `pull_request`. Por lo tanto, el paso `if_issue` se ejecutará, pero el paso `if_pr` no. Por el contrario, si el flujo de trabajo se ha ejecutado porque se ha cerrado una solicitud de incorporación de cambios, el paso `if_pr` se ejecutará, pero el paso `if_issue` no.\n\n```yaml\non:\n  issues:\n    types:\n      - closed\n  pull_request:\n    types:\n      - closed\n\njobs:\n  state_event_type:\n    runs-on: ubuntu-latest\n    steps:\n    - name: if_issue\n      if: github.event.issue\n      run: |\n        echo An issue was closed\n    - name: if_pr\n      if: github.event.pull_request\n      run: |\n        echo A pull request was closed\n```\n\nPara obtener más información sobre qué información está disponible en el contexto del evento, consulta [Uso de información de eventos](#using-event-information). Para obtener más información sobre cómo usar condicionales, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/reference/workflows-and-actions/expressions).\n\n### Utilizar ambientes para activar jobs de flujos de trabajo manualmente\n\nSi quieres activar manualmente un job específico en un flujo de trabajo, puedes utilizar un ambiente que requiera aprobación de un equipo o usuario específico. Primero, configura un ambiente con revisores requeridos. Para más información, consulta [Administrar entornos para la implementación](/es/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Luego, haga referencia al nombre del entorno en un trabajo de su flujo de trabajo utilizando la clave `environment:`. No se ejecutará ninguna tarea que referencie el entorno hasta que al menos un revisor la apruebe.\n\nPor ejemplo, el siguiente flujo de trabajo se ejecutará siempre que haya una subida a la rama principal. El trabajo `build` siempre se ejecutará. El trabajo `publish` solo se ejecutará después de que el trabajo `build` se complete correctamente (debido a `needs: [build]`) y después de que se pasen todas las reglas (incluidos los revisores necesarios) para el entorno denominado `production` (debido a `environment: production`).\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: build\n        run: |\n          echo 'building'\n\n  publish:\n    needs: [build]\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: publish\n        run: |\n          echo 'publishing'\n```\n\n> \\[!NOTE]\n> Los entornos, los secretos de entorno y las reglas de protección de despliegue están disponibles en repositorios públicos para todos los GitHub planes actuales. No están disponibles en planes antiguos, como Bronce, Plata o Oro. Para acceder a entornos, secretos de entorno e ramas de implementación en repositorios privados o internos, debe usar GitHub Pro, GitHub Teamo GitHub Enterprise.\n> Si estás en un plan GitHub Free, GitHub Pro o GitHub Team, otras reglas de protección de implementación, como un temporizador de espera o revisores necesarios, solo están disponibles para repositorios públicos.\n\n## Eventos disponibles\n\nPara ver la lista completa de eventos disponibles, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/reference/workflows-and-actions/events-that-trigger-workflows)."}