Acceso a información contextual sobre ejecuciones de flujo de trabajo

Acerca de los contextos

Los contextos son una manera de acceder a información acerca de las ejecuciones de flujo de trabajo, variable, entornos del ejecutor, trabajos y pasos. Cada contexto es un objeto que contiene propiedades, que pueden ser cadenas u otros objetos.

Los contextos, objetos y propiedades variarán significativamente bajo las diferentes condiciones de ejecución de flujo de trabajo. Por ejemplo, el contexto matrix solo se rellena para los trabajos de una matriz.

Puedes acceder a los contextos utilizando la sintaxis de expresión. Para obtener más información, vea «Evaluación de expresiones en flujos de trabajo y acciones».

${{ <context> }}

Como parte de una expresión, puedes acceder a la información de contexto utilizando una de dos sintaxis.

• Sintaxis de índice: github['sha']
• Sintaxis de desreferenciación de propiedades: github.sha

Para usar la sintaxis de desreferencia de propiedades, el nombre de la propiedad debe comenzar con una letra o _ y solo puede incluir caracteres alfanuméricos, - o _.

Si intentas desreferenciar una propiedad inexistente, se evaluará como cadena vacía.

Determinar cuándo utilizar contextos

GitHub Actions incluye una colección de variables denominadas contextos y una colección de variables similar denominadas variables predeterminadas. Estas variables se pretenden utilizar en puntos diferentes del flujo de trabajo:

• Variables de entorno predeterminadas: estas variables de entorno solo existen en el ejecutor que ejecuta el trabajo. Para obtener más información, vea «Almacenamiento de información en variables».
• Contextos: puedes usar la mayoría de los contextos en cualquier punto del flujo de trabajo, incluido cuando las variables predeterminadas no estén disponibles. Por ejemplo, puede usar contextos con expresiones para realizar un procesamiento inicial antes de que el trabajo se enrute a un ejecutor para su ejecución; esto le permite utilizar un contexto con la palabra clave condicional if para determinar si se debería ejecutar un paso. Una vez que el trabajo esté en ejecución, también puede recuperar variables de contexto para el ejecutor que ejecuta el trabajo, como runner.os. Para más información sobre dónde puede usar varios contextos dentro de un flujo de trabajo, vea "Disponibilidad del contexto".

El siguiente ejemplo ilustra cómo estos tipos de variables diferentes pueden utilizarse juntas en un trabajo:

name: CI
on: push
jobs:
  prod-check:
    if: ${{ github.ref == 'refs/heads/main' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

name: CI
on: push
jobs:
  prod-check:
    if: ${{ github.ref == 'refs/heads/main' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

En este ejemplo, la instrucción if comprueba el contexto github.ref para determinar el nombre de la rama actual; si el nombre es refs/heads/main, se ejecutan los pasos siguientes. GitHub Actions procesa la comprobación if y el trabajo solo se envía al ejecutor si el resultado es true. Una vez que el trabajo se envía al ejecutor, el paso se ejecuta y hace referencia a la variable $GITHUB_REF del ejecutor.

Disponibilidad de contexto

Hay diferentes contextos disponibles a lo largo de un ejecutor de flujo de trabajo. Por ejemplo, el contexto secrets solo se puede usar en determinados puntos de un trabajo.

Adicionalmente, algunas funcionalidades solo pueden utilizarse en algunos lugares. Por ejemplo, la función hashFiles no está disponible en todas partes.

La siguiente tabla indica las restricciones en las que puede utilizarse cada contexto y función especial dentro de un flujo de trabajo. Los contextos enumerados solo están disponibles para la clave de flujo de trabajo indicada y es posible que no se usen en ningún otro lugar. A menos de que se liste a continuación, las funciones se pueden utilizar donde sea.

Ejemplo: imprimir información de contexto a la bitácora

Puedes imprimir el contenido de los contextos a la bitácora para la depuración. La función toJSON es necesaria para imprimir objetos JSON en el registro.

name: Context testing
on: push

jobs:
  dump_contexts_to_log:
    runs-on: ubuntu-latest
    steps:
      - name: Dump GitHub context
        env:
          GITHUB_CONTEXT: ${{ toJson(github) }}
        run: echo "$GITHUB_CONTEXT"
      - name: Dump job context
        env:
          JOB_CONTEXT: ${{ toJson(job) }}
        run: echo "$JOB_CONTEXT"
      - name: Dump steps context
        env:
          STEPS_CONTEXT: ${{ toJson(steps) }}
        run: echo "$STEPS_CONTEXT"
      - name: Dump runner context
        env:
          RUNNER_CONTEXT: ${{ toJson(runner) }}
        run: echo "$RUNNER_CONTEXT"
      - name: Dump strategy context
        env:
          STRATEGY_CONTEXT: ${{ toJson(strategy) }}
        run: echo "$STRATEGY_CONTEXT"
      - name: Dump matrix context
        env:
          MATRIX_CONTEXT: ${{ toJson(matrix) }}
        run: echo "$MATRIX_CONTEXT"

name: Context testing
on: push

jobs:
  dump_contexts_to_log:
    runs-on: ubuntu-latest
    steps:
      - name: Dump GitHub context
        env:
          GITHUB_CONTEXT: ${{ toJson(github) }}
        run: echo "$GITHUB_CONTEXT"
      - name: Dump job context
        env:
          JOB_CONTEXT: ${{ toJson(job) }}
        run: echo "$JOB_CONTEXT"
      - name: Dump steps context
        env:
          STEPS_CONTEXT: ${{ toJson(steps) }}
        run: echo "$STEPS_CONTEXT"
      - name: Dump runner context
        env:
          RUNNER_CONTEXT: ${{ toJson(runner) }}
        run: echo "$RUNNER_CONTEXT"
      - name: Dump strategy context
        env:
          STRATEGY_CONTEXT: ${{ toJson(strategy) }}
        run: echo "$STRATEGY_CONTEXT"
      - name: Dump matrix context
        env:
          MATRIX_CONTEXT: ${{ toJson(matrix) }}
        run: echo "$MATRIX_CONTEXT"

Contexto github

El contexto github contiene información sobre la ejecución del flujo de trabajo y el evento que ha desencadenado la ejecución. También puede leer la mayoría de los datos del contexto github en variables de entorno. Para obtener más información sobre cómo usar variables de entorno, consulte "Almacenamiento de información en variables."

Contenido de ejemplo del contexto github

El siguiente contexto de ejemplo procede de una ejecución de flujo de trabajo desencadenada por el evento push. El objeto event de este ejemplo se ha truncado porque es idéntico al contenido de la carga del webhook push.

{
  "token": "***",
  "job": "dump_contexts_to_log",
  "ref": "refs/heads/my_branch",
  "sha": "c27d339ee6075c1f744c5d4b200f7901aad2c369",
  "repository": "octocat/hello-world",
  "repository_owner": "octocat",
  "repositoryUrl": "git://github.com/octocat/hello-world.git",
  "run_id": "1536140711",
  "run_number": "314",
  "retention_days": "90",
  "run_attempt": "1",
  "actor": "octocat",
  "workflow": "Context testing",
  "head_ref": "",
  "base_ref": "",
  "event_name": "push",
  "event": {
    ...
  },
  "server_url": "https://github.com",
  "api_url": "https://api.github.com",
  "graphql_url": "https://api.github.com/graphql",
  "ref_name": "my_branch",
  "ref_protected": false,
  "ref_type": "branch",
  "secret_source": "Actions",
  "workspace": "/home/runner/work/hello-world/hello-world",
  "action": "github_step",
  "event_path": "/home/runner/work/_temp/_github_workflow/event.json",
  "action_repository": "",
  "action_ref": "",
  "path": "/home/runner/work/_temp/_runner_file_commands/add_path_b037e7b5-1c88-48e2-bf78-eaaab5e02602",
  "env": "/home/runner/work/_temp/_runner_file_commands/set_env_b037e7b5-1c88-48e2-bf78-eaaab5e02602"
}

Ejemplo de uso del contexto github

En este flujo de trabajo de ejemplo se usa el contexto github.event_name para ejecutar un trabajo solo si el evento pull_request ha desencadenado la ejecución del flujo de trabajo.

name: Run CI
on: [push, pull_request]

jobs:
  normal_ci:
    runs-on: ubuntu-latest
    steps:
      - name: Run normal CI
        run: echo "Running normal CI"

  pull_request_ci:
    runs-on: ubuntu-latest
    if: ${{ github.event_name == 'pull_request' }}
    steps:
      - name: Run PR CI
        run: echo "Running PR only CI"

name: Run CI
on: [push, pull_request]

jobs:
  normal_ci:
    runs-on: ubuntu-latest
    steps:
      - name: Run normal CI
        run: echo "Running normal CI"

  pull_request_ci:
    runs-on: ubuntu-latest
    if: ${{ github.event_name == 'pull_request' }}
    steps:
      - name: Run PR CI
        run: echo "Running PR only CI"

Contexto env

El contexto env contiene las variables que se han establecido en un flujo de trabajo, trabajo o paso. No contiene variables heredadas por el proceso del ejecutor. Para obtener más información sobre la configuración de variables en su flujo de trabajo, consulte "Sintaxis del flujo de trabajo para Acciones de GitHub".

Puedes recuperar los valores de las variables almacenadas en el contexto env y usar estos valores en el archivo de flujo de trabajo. Puedes usar el contexto env en cualquier clave de un paso de flujo de trabajo, excepto en el caso de las claves id y uses. Para obtener más información sobre la sintaxis del paso, consulte "Sintaxis del flujo de trabajo para Acciones de GitHub".

Si quieres usar el valor de una variable dentro de un ejecutor, usa el método normal del sistema operativo del ejecutor para leer las variables de entorno.

Contenido de ejemplo del contexto env

El contenido del contexto env es una asignación de nombres de variable a sus valores. El contenido del contexto puede cambiar dependiendo de dónde se utiliza en la ejecución de flujo de trabajo. En este ejemplo, el contexto env contiene dos variables.

{
  "first_name": "Mona",
  "super_duper_var": "totally_awesome"
}

Ejemplo de uso del contexto env

En este flujo de trabajo de ejemplo se muestran las variables que se establecen en el contexto env en los niveles de flujo de trabajo, trabajo y paso. A continuación, la sintaxis ${{ env.VARIABLE-NAME }} se usa para recuperar valores de variable dentro de los pasos individuales del flujo de trabajo.

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.

name: Hi Mascot
on: push
env:
  mascot: Mona
  super_duper_var: totally_awesome

jobs:
  windows_job:
    runs-on: windows-latest
    steps:
      - run: echo 'Hi ${{ env.mascot }}'  # Hi Mona
      - run: echo 'Hi ${{ env.mascot }}'  # Hi Octocat
        env:
          mascot: Octocat
  linux_job:
    runs-on: ubuntu-latest
    env:
      mascot: Tux
    steps:
      - run: echo 'Hi ${{ env.mascot }}'  # Hi Tux

name: Hi Mascot
on: push
env:
  mascot: Mona
  super_duper_var: totally_awesome

jobs:
  windows_job:
    runs-on: windows-latest
    steps:
      - run: echo 'Hi ${{ env.mascot }}'  # Hi Mona
      - run: echo 'Hi ${{ env.mascot }}'  # Hi Octocat
        env:
          mascot: Octocat
  linux_job:
    runs-on: ubuntu-latest
    env:
      mascot: Tux
    steps:
      - run: echo 'Hi ${{ env.mascot }}'  # Hi Tux

Contexto vars

El contexto vars contiene variables de configuración personalizadas establecidas en los niveles de organización, repositorio y entorno. Para más información sobre cómo definir variables de configuración para su uso en varios flujos de trabajo, consulta "Almacenamiento de información en variables".

Contenido de ejemplo del contexto vars

El contenido del contexto vars es una asignación de nombres de variable de configuración a sus valores.

{
  "mascot": "Mona"
}

Ejemplo de uso del contexto vars

En este flujo de trabajo de ejemplo se muestra cómo las variables de configuración establecidas en los niveles de repositorio, entorno u organización están disponibles automáticamente mediante el contexto vars.

Si no se ha establecido una variable de configuración, el valor devuelto de un contexto que hace referencia a la variable será una cadena vacía.

En los ejemplos siguientes, se muestra el uso de variables de configuración con el contexto vars en un flujo de trabajo. Cada una de las siguientes variables de configuración se han definido en los niveles de repositorio, organización o entorno.

on:
  workflow_dispatch:
env:
  # Setting an environment variable with the value of a configuration variable
  env_var: ${{ vars.ENV_CONTEXT_VAR }}

jobs:
  display-variables:
    name: ${{ vars.JOB_NAME }}
    # You can use configuration variables with the `vars` context for dynamic jobs
    if: ${{ vars.USE_VARIABLES == 'true' }}
    runs-on: ${{ vars.RUNNER }}
    environment: ${{ vars.ENVIRONMENT_STAGE }}
    steps:
    - name: Use variables
      run: |
        echo "repository variable : $REPOSITORY_VAR"
        echo "organization variable : $ORGANIZATION_VAR"
        echo "overridden variable : $OVERRIDE_VAR"
        echo "variable from shell environment : $env_var"
      env:
        REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
        ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
        OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
        
    - name: ${{ vars.HELLO_WORLD_STEP }}
      if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
      uses: actions/hello-world-javascript-action@main
      with:
        who-to-greet: ${{ vars.GREET_NAME }}

on:
  workflow_dispatch:
env:
  # Setting an environment variable with the value of a configuration variable
  env_var: ${{ vars.ENV_CONTEXT_VAR }}

jobs:
  display-variables:
    name: ${{ vars.JOB_NAME }}
    # You can use configuration variables with the `vars` context for dynamic jobs
    if: ${{ vars.USE_VARIABLES == 'true' }}
    runs-on: ${{ vars.RUNNER }}
    environment: ${{ vars.ENVIRONMENT_STAGE }}
    steps:
    - name: Use variables
      run: |
        echo "repository variable : $REPOSITORY_VAR"
        echo "organization variable : $ORGANIZATION_VAR"
        echo "overridden variable : $OVERRIDE_VAR"
        echo "variable from shell environment : $env_var"
      env:
        REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
        ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
        OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
        
    - name: ${{ vars.HELLO_WORLD_STEP }}
      if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
      uses: actions/hello-world-javascript-action@main
      with:
        who-to-greet: ${{ vars.GREET_NAME }}

Contexto job

El contexto job contiene información sobre el trabajo actual en ejecución.

Contenido de ejemplo del contexto job

En este contexto job de ejemplo se usa un contenedor de servicio de PostgreSQL con puertos asignados. Si en un trabajo no se usan contenedores ni contenedores de servicio, el contexto job solo contiene la propiedad status.

{
  "status": "success",
  "container": {
    "network": "github_network_53269bd575974817b43f4733536b200c"
  },
  "services": {
    "postgres": {
      "id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105",
      "ports": {
        "5432": "49153"
      },
      "network": "github_network_53269bd575974817b43f4733536b200c"
    }
  }
}

Ejemplo de uso del contexto job

Este flujo de trabajo de ejemplo configura un contenedor de servicio de PostgreSQL y, automáticamente, mapea el puerto 5432 en el contenedor de servicio a un puerto disponible elegido aleatoriamente en el host. El contexto job se usa para acceder al número del puerto que se ha asignado en el host.

name: PostgreSQL Service Example
on: push
jobs:
  postgres-job:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
        ports:
          # Maps TCP port 5432 in the service container to a randomly chosen available port on the host.
          - 5432

    steps:
      - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}
      - run: echo "Run tests against Postgres"

name: PostgreSQL Service Example
on: push
jobs:
  postgres-job:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
        ports:
          # Maps TCP port 5432 in the service container to a randomly chosen available port on the host.
          - 5432

    steps:
      - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}
      - run: echo "Run tests against Postgres"

Contexto jobs

El jobs contexto solo está disponible en flujos de trabajo reutilizables y solo se puede usar para establecer salidas para un flujo de trabajo reutilizable. Para obtener más información, vea «Reutilización de flujos de trabajo».

Contenido de ejemplo del contexto jobs

Este contexto jobs de ejemplo contiene el resultado y las salidas de un trabajo a partir de una ejecución de flujo de trabajo reutilizable.

{
  "example_job": {
    "result": "success",
    "outputs": {
      "output1": "hello",
      "output2": "world"
    }
  }
}

Ejemplo de uso del contexto jobs

Este flujo de trabajo reutilizable de ejemplo usa el contexto jobs para establecer salidas para el flujo de trabajo reutilizable. Observa cómo las salidas fluyen desde los pasos hasta el trabajo y, a continuación, al desencadenador workflow_call. Para obtener más información, vea «Reutilización de flujos de trabajo».

name: Reusable workflow

on:
  workflow_call:
    # Map the workflow outputs to job outputs
    outputs:
      firstword:
        description: "The first output string"
        value: ${{ jobs.example_job.outputs.output1 }}
      secondword:
        description: "The second output string"
        value: ${{ jobs.example_job.outputs.output2 }}

jobs:
  example_job:
    name: Generate output
    runs-on: ubuntu-latest
    # Map the job outputs to step outputs
    outputs:
      output1: ${{ steps.step1.outputs.firstword }}
      output2: ${{ steps.step2.outputs.secondword }}
    steps:
      - id: step1
        run: echo "firstword=hello" >> $GITHUB_OUTPUT
      - id: step2
        run: echo "secondword=world" >> $GITHUB_OUTPUT

name: Reusable workflow

on:
  workflow_call:
    # Map the workflow outputs to job outputs
    outputs:
      firstword:
        description: "The first output string"
        value: ${{ jobs.example_job.outputs.output1 }}
      secondword:
        description: "The second output string"
        value: ${{ jobs.example_job.outputs.output2 }}

jobs:
  example_job:
    name: Generate output
    runs-on: ubuntu-latest
    # Map the job outputs to step outputs
    outputs:
      output1: ${{ steps.step1.outputs.firstword }}
      output2: ${{ steps.step2.outputs.secondword }}
    steps:
      - id: step1
        run: echo "firstword=hello" >> $GITHUB_OUTPUT
      - id: step2
        run: echo "secondword=world" >> $GITHUB_OUTPUT

Contexto steps

El contexto steps contiene información sobre los pasos del trabajo actual en los que se ha especificado id y ya se han ejecutado.

Contenido de ejemplo del contexto steps

En este contexto steps de ejemplo se muestran dos pasos anteriores en los que se ha especificado id. El primer paso tenía el id denominado checkout, el segundo generate_number. El paso generate_number tenía una salida denominada random_number.

{
  "checkout": {
    "outputs": {},
    "outcome": "success",
    "conclusion": "success"
  },
  "generate_number": {
    "outputs": {
      "random_number": "1"
    },
    "outcome": "success",
    "conclusion": "success"
  }
}

Ejemplo de uso del contexto steps

En este flujo de trabajo de ejemplo se genera un número aleatorio como salida en un paso y, en un paso posterior se usa el contexto steps para leer el valor de esa salida.

name: Generate random failure
on: push
jobs:
  randomly-failing-job:
    runs-on: ubuntu-latest
    steps:
      - name: Generate 0 or 1
        id: generate_number
        run:  echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT
      - name: Pass or fail
        run: |
          if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi

name: Generate random failure
on: push
jobs:
  randomly-failing-job:
    runs-on: ubuntu-latest
    steps:
      - name: Generate 0 or 1
        id: generate_number
        run:  echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT
      - name: Pass or fail
        run: |
          if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi

Contexto runner

El contexto runner contiene información sobre el ejecutor que ejecuta el trabajo actual.

Contenido de ejemplo del contexto runner

El siguiente contexto de ejemplo es de un ejecutor Linux hospedado en GitHub.

{
  "os": "Linux",
  "arch": "X64",
  "name": "GitHub Actions 2",
  "tool_cache": "/opt/hostedtoolcache",
  "temp": "/home/runner/work/_temp"
}

Ejemplo de uso del contexto runner

En este flujo de trabajo de ejemplo se usa el contexto runner a fin de configurar la ruta al directorio temporal para escribir registros y, si se produce un error en el flujo de trabajo, los carga como artefacto.

name: Build
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build with logs
        run: |
          mkdir ${{ runner.temp }}/build_logs
          echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs
          exit 1
      - name: Upload logs on fail
        if: ${{ failure() }}
        uses: actions/upload-artifact@v4
        with:
          name: Build failure logs
          path: ${{ runner.temp }}/build_logs

name: Build
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build with logs
        run: |
          mkdir ${{ runner.temp }}/build_logs
          echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs
          exit 1
      - name: Upload logs on fail
        if: ${{ failure() }}
        uses: actions/upload-artifact@v4
        with:
          name: Build failure logs
          path: ${{ runner.temp }}/build_logs

Contexto secrets

El contexto secrets contiene los nombres y valores de los secretos disponibles para una ejecución de flujo de trabajo. El contexto secrets no está disponible para acciones compuestas debido a motivos de seguridad. Si deseas pasar un secreto a una acción compuesta, debes hacerlo explícitamente como entrada. Para obtener más información sobre secretos, consulte "Uso de secretos en Acciones de GitHub".

GITHUB_TOKEN es un secreto que se crea automáticamente para cada ejecución de flujo de trabajo y siempre se incluye en el contexto secrets. Para obtener más información, vea «Autenticación automática de tokens».

Contenido de ejemplo del contexto secrets

En el contenido de ejemplo siguiente del contexto secrets se muestra el valor GITHUB_TOKEN automático, así como otros dos secretos disponibles para la ejecución del flujo de trabajo.

{
  "github_token": "***",
  "NPM_TOKEN": "***",
  "SUPERSECRET": "***"
}

Ejemplo de uso del contexto secrets

En este flujo de trabajo de ejemplo se usa la CLI de GitHub, que necesita GITHUB_TOKEN como valor para el parámetro de entrada GH_TOKEN:

name: Open new issue
on: workflow_dispatch

jobs:
  open-issue:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - run: |
          gh issue --repo ${{ github.repository }} \
            create --title "Issue title" --body "Issue body"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

name: Open new issue
on: workflow_dispatch

jobs:
  open-issue:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - run: |
          gh issue --repo ${{ github.repository }} \
            create --title "Issue title" --body "Issue body"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Contexto strategy

Para los flujos de trabajo con una matriz, el contexto strategy contiene información sobre la estrategia de ejecución de matrices para el trabajo actual.

Contenido de ejemplo del contexto strategy

El contenido de ejemplo siguiente del contexto strategy procede de una matriz con cuatro trabajos y se toma del trabajo final. Observe la diferencia entre el número job-index de base cero y job-total, que no es de base cero.

{
  "fail-fast": true,
  "job-index": 3,
  "job-total": 4,
  "max-parallel": 4
}

Ejemplo de uso del contexto strategy

En este flujo de trabajo de ejemplo se usa la propiedad strategy.job-index a fin de establecer un nombre único para un archivo de registro para cada trabajo de una matriz.

name: Test strategy
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        test-group: [1, 2]
        node: [14, 16]
    steps:
      - run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt
      - name: Upload logs
        uses: actions/upload-artifact@v4
        with:
          name: Build log for job ${{ strategy.job-index }}
          path: test-job-${{ strategy.job-index }}.txt

name: Test strategy
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        test-group: [1, 2]
        node: [14, 16]
    steps:
      - run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt
      - name: Upload logs
        uses: actions/upload-artifact@v4
        with:
          name: Build log for job ${{ strategy.job-index }}
          path: test-job-${{ strategy.job-index }}.txt

Contexto matrix

Para los flujos de trabajo con una matriz, el contexto matrix contiene las propiedades de matriz definidas en el archivo de flujo de trabajo que se aplican al trabajo actual. Por ejemplo, si configuras una matriz con las claves os y node, el objeto de contexto matrix incluye las propiedades os y node con los valores que se usan para el trabajo actual.

No hay propiedades estándar en el contexto matrix, solo las definidas en el archivo de flujo de trabajo.

Contenido de ejemplo del contexto matrix

El contenido de ejemplo siguiente del contexto matrix procede de un trabajo de una matriz que tiene las propiedades de matriz os y node definidas en el flujo de trabajo. El trabajo ejecuta la combinación de matriz de un sistema operativo ubuntu-latest y la versión 16 de Node.js.

{
  "os": "ubuntu-latest",
  "node": 16
}

Ejemplo de uso del contexto matrix

Este flujo de trabajo de ejemplo crea una matriz con las claves os y node. Usa la propiedad matrix.os para establecer el tipo de ejecutor para cada trabajo y la propiedad matrix.node a fin de establecer la versión de Node.js para cada trabajo.

name: Test matrix
on: push

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [14, 16]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - name: Output node version
        run: node --version

name: Test matrix
on: push

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [14, 16]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - name: Output node version
        run: node --version

Contexto needs

El contexto needs contiene salidas de todos los trabajos que se definen como una dependencia directa del trabajo actual. Ten en cuenta que esto no incluye trabajos dependientes implícitamente (por ejemplo, trabajos dependientes de un trabajo dependiente). Para más información sobre cómo definir dependencias de trabajo, consulte "Sintaxis del flujo de trabajo para Acciones de GitHub."

Contenido de ejemplo del contexto needs

En el contenido de ejemplo siguiente del contexto needs se muestra información para dos trabajos de los que depende el trabajo actual.

{
  "build": {
    "result": "success",
    "outputs": {
      "build_id": "123456"
    }
  },
  "deploy": {
    "result": "failure",
    "outputs": {}
  }
}

Ejemplo de uso del contexto needs

Este flujo de trabajo de ejemplo tiene tres trabajos: un trabajo build que realiza una compilación, un trabajo deploy que necesita el trabajo build y un trabajo debug que necesita los trabajos build y deploy, y que solo se ejecuta si se produce un error en el flujo de trabajo. El trabajo deploy también usa el contexto needs para acceder a una salida del trabajo build.

name: Build and deploy
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      build_id: ${{ steps.build_step.outputs.build_id }}
    steps:
      - name: Build
        id: build_step
        run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying build ${{ needs.build.outputs.build_id }}"
  debug:
    needs: [build, deploy]
    runs-on: ubuntu-latest
    if: ${{ failure() }}
    steps:
      - run: echo "Failed to build and deploy"

name: Build and deploy
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      build_id: ${{ steps.build_step.outputs.build_id }}
    steps:
      - name: Build
        id: build_step
        run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying build ${{ needs.build.outputs.build_id }}"
  debug:
    needs: [build, deploy]
    runs-on: ubuntu-latest
    if: ${{ failure() }}
    steps:
      - run: echo "Failed to build and deploy"

Contexto inputs

El contexto inputs contiene las propiedades de entrada pasadas a una acción, a un flujo de trabajo reutilizable o a un flujo de trabajo desencadenado manualmente. Para flujos de trabajo reutilizables, los nombres y tipos de entrada se definen en la configuración del evento workflow_call de un flujo de trabajo reutilizable y los valores de entrada se pasan desde jobs.<job_id>.with en un flujo de trabajo externo que llama al flujo de trabajo reutilizable. En el caso de los flujos de trabajo manualmente desencadenados, las entradas se define en la workflow_dispatchconfiguración del evento de un flujo de trabajo.

Las propiedades en el contexto inputs están definidas en el archivo de flujo de trabajo. Solo están disponibles en un flujo de trabajo reutilizable o en un flujo de trabajo desencadenado por el evento workflow_dispatch

Contenido de ejemplo del contexto inputs

El contenido de ejemplo siguiente del contexto inputs proviene de un flujo de trabajo que tiene definidas las entradas build_id, deploy_target y perform_deploy.

{
  "build_id": 123456768,
  "deploy_target": "deployment_sys_1a",
  "perform_deploy": true
}

Ejemplo de uso del contexto inputs en un flujo de trabajo reutilizable

En este flujo de trabajo reutilizable de ejemplo, se usa el contexto inputs para obtener los valores de las entradas build_id, deploy_target y perform_deploy que se pasaron al flujo de trabajo reutilizable desde el flujo de trabajo del autor de la llamada.

name: Reusable deploy workflow
on:
  workflow_call:
    inputs:
      build_id:
        required: true
        type: number
      deploy_target:
        required: true
        type: string
      perform_deploy:
        required: true
        type: boolean

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ inputs.perform_deploy }}
    steps:
      - name: Deploy build to target
        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

name: Reusable deploy workflow
on:
  workflow_call:
    inputs:
      build_id:
        required: true
        type: number
      deploy_target:
        required: true
        type: string
      perform_deploy:
        required: true
        type: boolean

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ inputs.perform_deploy }}
    steps:
      - name: Deploy build to target
        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

Ejemplo del uso del contexto inputs en un flujo de trabajo manualmente desencadenado

En este flujo de trabajo de ejemplo desencadenado por un eventoworkflow_dispatch, se usa el contexto inputs para obtener los valores de las entradas build_id, deploy_target y perform_deploy que se pasaron al flujo de trabajo.

on:
  workflow_dispatch:
    inputs:
      build_id:
        required: true
        type: string
      deploy_target:
        required: true
        type: string
      perform_deploy:
        required: true
        type: boolean

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ inputs.perform_deploy }}
    steps:
      - name: Deploy build to target
        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

on:
  workflow_dispatch:
    inputs:
      build_id:
        required: true
        type: string
      deploy_target:
        required: true
        type: string
      perform_deploy:
        required: true
        type: boolean

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ inputs.perform_deploy }}
    steps:
      - name: Deploy build to target
        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"