# Activar un flujo de trabajo

Cómo activar automáticamente GitHub Actions flujos de trabajo

## Requisitos previos

Para 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).

## Activar un flujo de trabajo desde otro flujo de trabajo

Cuando 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:

* `workflow_dispatch` y `repository_dispatch` los eventos siempre crean ejecuciones de flujo de trabajo.
* ```
            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).
  ```

Para 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).

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

Si 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).

Para minimizar los GitHub Actions costos de uso, asegúrese de que no cree ejecuciones de flujo de trabajo recursivas o no deseadas.

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

```yaml
on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.MY_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"
```

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

```yaml
on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"
```

## Utilizar eventos para activar flujos de trabajo

Use 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).

### Utilizar un único evento

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.

### Uso de tipos de actividad y filtros con eventos múltiples

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

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:
```

## Utilizar tipos de actividad de eventos

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

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

```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/reference/workflows-and-actions/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 filtros para apuntar a ramas específicas para los eventos de solicitudes de cambios

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/reference/workflows-and-actions/workflow-syntax#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/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).

#### Ejemplo: Incluyendo ramificaciones

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

#### 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`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->

```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. <!-- markdownlint-disable-line outdated-release-phase-terminology -->

```yaml
on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'
```

### Utilizar filtros para apuntar a ramas o etiquetas específicas para los eventos de subida

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/reference/workflows-and-actions/workflow-syntax#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/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).

#### Ejemplo: Incluyendo 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`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->
* 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. <!-- markdownlint-disable-line outdated-release-phase-terminology -->

```yaml
on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'
```

### Utilizar filtros para apuntar a rutas específicas para los eventos de subida o solicitudes de cambios

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:
>
> * Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva excluirá la ruta de acceso.
> * Un patrón positivo después de una coincidencia negativa volverá a incluir 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 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).

#### Ejemplo: Incluir rutas

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 siguiente flujo de trabajo se ejecutaría cada vez que hagas push 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/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.

#### 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

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

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 utilizando comparaciones de dos puntos para los envíos y de tres puntos para las solicitudes de incorporación de cambios:

* **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.
* **Envíos a ramas existentes:** Una comparación de dos puntos compara directamente entre sí los SHA de la cabeza y de la base.
* **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.

En algunas situaciones, GitHub Actions aplica límites que cambian cómo se ejecutan los flujos de trabajo filtrados:

* Si un push contiene más de 1.000 commits, el flujo de trabajo **siempre** se ejecutará.
* Si se agota el tiempo de espera al generar la comparación, el flujo de trabajo se ejecutará **siempre**.
* 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á.

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

Para más información, consulta [Ramas](/es/pull-requests/reference/branches).

### Utilizar filtros para apuntar a ramas específicas para los eventos de ejecución de flujos de trabajo

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

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/reference/workflows-and-actions/workflow-syntax#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 desencadenador solo se ejecutará cuando el flujo de trabajo llamado `Build` se ejecute en una rama que no se llame `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.

* Un patrón negativo coincidente (con el prefijo `!`) después de una coincidencia positiva excluirá 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 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 -->

```yaml
on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'
```

## Definir entradas para los flujos de trabajo que se activan manualmente

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.
El 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).

> \[!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.

```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 }} 
```

## Definir entradas, salidas y secretos para los flujos de trabajo reutilizables

Puedes 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).

## Utilizar la información de los eventos

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

### Ver todas las propiedades de un evento

Referencia 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).

Tambié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:

```yaml
jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT
```

### Acceder y utilizar las propiedades de evento

Puede 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`).

```yaml
on:
  pull_request:
    types:
      - opened
    paths:
      - '.github/workflows/**'
      - '.github/CODEOWNERS'
      - 'package*.json'

jobs:
  triage:
    if: >-
      github.event.pull_request.user.login != 'octobot' &&
      github.event.pull_request.user.login != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: "Comment about changes we can't accept"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.html_url }}
        run: |
          gh pr edit $PR --add-label 'invalid'
          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.'
```

Para 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).

## Controlar aún más la forma en la que se ejecutará tu flujo de trabajo

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

### Utilizar condicionales

Puedes utilizar condicionales para tener un mayor control sobre si se ejecutarán los trabajos o pasos de tu flujo de trabajo.

#### Ejemplo utilizando un valor en la carga útil del evento

Por 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`.

```yaml
on:
  issues:
    types:
      - labeled

jobs:
  run_if_label_matches:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    steps:
      - run: echo 'The label was bug'
```

#### Ejemplo utilizando un tipo de evento

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

```yaml
on:
  issues:
    types:
      - closed
  pull_request:
    types:
      - closed

jobs:
  state_event_type:
    runs-on: ubuntu-latest
    steps:
    - name: if_issue
      if: github.event.issue
      run: |
        echo An issue was closed
    - name: if_pr
      if: github.event.pull_request
      run: |
        echo A pull request was closed
```

Para 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).

### Utilizar ambientes para activar jobs de flujos de trabajo manualmente

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

Por 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`).

```yaml
on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        run: |
          echo 'building'

  publish:
    needs: [build]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: publish
        run: |
          echo 'publishing'
```

> \[!NOTE]
> 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.
> 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.

## Eventos disponibles

Para ver la lista completa de eventos disponibles, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/reference/workflows-and-actions/events-that-trigger-workflows).