Nota: Actualmente los ejecutores hospedados en GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.
Acerca de las variables
Las variables proporcionan una manera de almacenar y reutilizar información de configuración no confidencial. Puedes almacenar cualquier dato de configuración, como marcas del compilador, nombres de usuario o nombres de servidor como variables. Las variables se interpolan en la máquina del ejecutor que ejecuta el flujo de trabajo. Los comandos que se ejecutan en las acciones o flujos de trabajo pueden crear, leer y modificar las variables.
Puedes establecer tus propias variables personalizadas o usar las variables de entorno predeterminadas que GitHub establece automáticamente. Para obtener más información, consulta "Variables de entorno predeterminadas".
Puede establecer una variable personalizada de dos maneras.
- Para definir una variable de entorno para su uso en un único flujo de trabajo, puedes usar la clave
env
en el archivo de flujo de trabajo. Para obtener más información, consulta "Definición de variables de entorno para un único flujo de trabajo". - Para definir una variable de configuración en varios flujos de trabajo, puedes definirla en el nivel de organización, repositorio o entorno. Para obtener más información, consulta "Definición de variables de configuración para varios flujos de trabajo".
Advertencia: De forma predeterminada, las variables se representan sin máscara en las salidas de compilación. Si necesita mayor seguridad para la información confidencial, como contraseñas, use secretos en su lugar. Para obtener más información, consulta "Uso de secretos en Acciones de GitHub".
Consulta la definición de variables de entorno para un único flujo de trabajo
Para definir una variable de entorno personalizada para su uso en un único flujo de trabajo, puede definir la clave env
en el archivo de flujo de trabajo. El alcance de una variable personalizada establecida por este método se limita al elemento en el cual se define. Puedes definir las variables que tienen alcance para:
- Todo el flujo de trabajo, mediante el uso de
env
en el nivel superior del archivo de flujo de trabajo. - El contenido de un trabajo dentro de un flujo de trabajo mediante
jobs.<job_id>.env
. - Un paso específico dentro de un trabajo mediante
jobs.<job_id>.steps[*].env
.
name: Greeting on variable day on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Greeting on variable day
on:
workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
Puedes acceder a los valores de variable env
mediante variables de entorno de ejecutor o mediante contextos. En el ejemplo anterior, se muestran tres variables personalizadas que se usan como variables de entorno de ejecutor en un echo
comando: $DAY_OF_WEEK
, $Greeting
y $First_Name
. A los valores para estas variables se les configura y da el alcance en el flujo de trabajo, job y nivel de paso respectivamente. La interpolación de estas variables se produce en el ejecutor.
El shell que usa en el ejecutor procesa los comandos de los pasos run
de un flujo de trabajo o una acción a la que se hace referencia. Las instrucciones en las otras partes del flujo de trabajo son procesadas por GitHub Actions y no se envían al ejecutor. Puede usar contextos o variables de entorno de ejecutor en los pasos run
, pero en las partes de un flujo de trabajo que no se envían al ejecutor debe usar contextos para tener acceso a los valores de las variables. Para más información, consulte “Uso del contexto para acceder a los valores de las variables”.
Debido a que la interpolación de las variables de ambiente del ejecutor se realiza después de que un trabajo del flujo de trabajo se envíe a una máquina ejecutora, debes utilizar la sintaxis adecuada para el shell que se utiliza en el ejecutor. En este ejemplo, el flujo de trabajo especifica ubuntu-latest
. De manera predeterminada, los ejecutores de Linux utilizan el shell bash, así que debe utilizar la sintaxis $NAME
. De forma predeterminada, los ejecutores de Windows usan PowerShell, por lo que tendría que usar la sintaxis $env:NAME
. Para obtener más información sobre shells, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".
Convenciones de nomenclatura para las variables de entorno
Cuando configuras una variable de entorno, no puedes utilizar ninguno de los nombres de variable de entorno predeterminados. Para obtener una lista completa de variables de entorno predeterminadas, consulta la sección "Variables de entorno predeterminadas" a continuación. Si intentas anular el valor de estas variables predeterminadas, se ignorará la tarea.
Nota: Puede enumerar todo el conjunto de variables de entorno que están disponibles para un paso del flujo de trabajo utilizando run: env
en un paso y, a continuación, examinar el resultado del paso.
Definición de variables de configuración para varios flujos de trabajo
Nota: Las variables de configuración para GitHub Actions están en beta y están sujetas a cambios.
Puedes crear variables de configuración para su uso en varios flujos de trabajo y definirlas en el nivel de organización, repositorio o entorno.
Por ejemplo, puedes usar variables de configuración para establecer valores predeterminados para los parámetros pasados a herramientas de compilación en un nivel de organización, pero, a continuación, permitir que los propietarios del repositorio invaliden estos parámetros por caso.
Al definir variables de configuración, están disponibles automáticamente en el contexto vars
. Para más información, consulta "Uso del contexto vars
para acceder a los valores de las variables de configuración".
Precedencia de las variables de configuración
Si existe una variable con el mismo nombre en varios niveles, tiene preferencia la del nivel más bajo. Por ejemplo, si una variable a nivel de organización tiene el mismo nombre que una variable a nivel de repositorio, entonces el secreto a nivel de repositorio tomará precedencia. De forma similar, si una organización, repositorio y ambiente tienen una variable con el mismo nombre, la que esté a nivel de ambiente tomará precedencia.
En el caso de los flujos de trabajo reutilizables, se usan las variables del repositorio del flujo de trabajo del autor de la llamada. Las variables del repositorio que contiene el flujo de trabajo llamado no están disponibles para el flujo de trabajo del autor de la llamada.
Convenciones de nomenclatura para variables de configuración
Las siguientes reglas se aplican a los nombres de variables de configuración:
- Los nombres solo pueden contener caracteres alfanuméricos (
[a-z]
,[A-Z]
,[0-9]
) o caracteres de subrayado (_
). No se permiten espacios. - Los nombres no deben comenzar con el prefijo
GITHUB_
. - Los nombres no deben comenzar con un número.
- Los nombres no distinguen mayúsculas de minúsculas.
- Los nombres deben ser únicos en el nivel en el que se hayan creado.
Creación de variables de configuración para un repositorio
Para crear secretos o variables en GitHub para el repositorio de una cuenta personal, debe ser propietario del repositorio. Para crear secretos o en GitHub para el repositorio de una organización, debe tener acceso de admin
. Por último, para crear secretos o variables para el repositorio de una cuenta personal o el repositorio de una organización a través de la API de REST, es preciso tener acceso de colaborador.
-
En GitHub, navegue hasta la página principal del repositorio.
-
En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.
-
En la sección "Seguridad" de la barra lateral, seleccione Secretos y variables y haga clic en Acciones.
-
Haz clic en la pestaña Variables.
-
Haz clic en Nueva variable de repositorio.
-
Escribe el nombre de la variable en el campo Nombre.
-
En el campo Valor, escribe el valor de la variable.
-
Haga clic en Agregar variable.
Creación de variables de configuración para un entorno
Para crear secretos o variables para un entorno en el repositorio de una cuenta personal, debe ser el propietario del repositorio. A fin de crear secretos o variables para un entorno en el repositorio de una organización, debe tener acceso de admin
. Para obtener más información sobre los entornos, consulta "Administrar entornos para la implementación".
-
En GitHub, navegue hasta la página principal del repositorio.
-
En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.
-
En la barra lateral de la izquierda, haz clic en Entornos.
-
Haz clic en el ambiente al cual quieras agregar una variable.
-
En Variables de entorno, haz clic en Agregar variable.
-
Escribe el nombre de la variable en el campo Nombre.
-
En el campo Valor, escribe el valor de la variable.
-
Haga clic en Agregar variable.
Creación de variables de configuración para una organización
Cuando creas un secreto o una variable en una organización, puedes usar una política para limitar el acceso por repositorio. Por ejemplo, puedes otorgar acceso a todos los repositorios, o limitarlo a solo los repositorios privados o a una lista específica de estos.
Los propietarios de la organización pueden crear secretos o variables a nivel de organización.
-
En GitHub, navega a la página principal de tu organización.
-
En el nombre de la organización, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.
-
En la sección "Seguridad" de la barra lateral, seleccione Secretos y variables y haga clic en Acciones.
-
Haz clic en la pestaña Variables.
-
Haz clic en Nueva variable de organización.
-
Escribe el nombre de la variable en el campo Nombre.
-
En el campo Valor, escribe el valor de la variable.
-
En la lista desplegable Repository access (Acceso al repositorio), elija una directiva de acceso.
-
Haga clic en Agregar variable.
Límites de variables de configuración
Las variables individuales tienen un tamaño máximo de 48 KB.
Puedes almacenar hasta 1000 variables de organización, 500 variables por repositorio y 100 por entorno. El límite de tamaño combinado total para las variables de organización y repositorio es de 10 MB por ejecución de flujo de trabajo.
Un flujo de trabajo que se haya creado en un repositorio puede acceder a la siguiente cantidad de variables:
- Hasta 500 variables de repositorio, si el tamaño total de las variables del repositorio es inferior a 10 MB. Si el tamaño total de las variables de repositorio supera los 10 MB, solo estarán disponibles las variables del repositorio que estén por debajo del límite (ordenadas alfabéticamente por nombre de variable).
- Hasta 1000 variables de organización, si el tamaño total combinado de variables de repositorio y organización es inferior a 10 MB. Si el tamaño total combinado de variables de organización y repositorio supera los 10 MB, solo estarán disponibles las variables de organización que se encuentran por debajo de ese límite (después de tener en cuenta las variables de repositorio y ordenadas alfabéticamente por nombre de variable).
- Hasta 100 variables de nivel de entorno.
Nota: Las variables de nivel de entorno no cuentan para el límite de tamaño total de 10 MB. Si superas el límite de tamaño combinado de las variables de repositorio y organización y todavía necesitas variables adicionales, puedes usar un entorno y definir variables adicionales en él.
Uso de contextos para acceder a los valores de las variables
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. Para obtener más información, consulta "Acceso a información contextual sobre ejecuciones de flujo de trabajo". Hay muchos otros contextos que puedes utilizar para propósitos diversos en tus flujos de trabajo. Para obtener más información sobre dónde se pueden usar varios contextos dentro de un flujo de trabajo, consulta "Acceso a información contextual sobre ejecuciones de flujo de trabajo".
Puedes acceder a los valores de variables de entorno mediante el env
contexto y los valores de las variables de configuración mediante el contexto vars
.
Uso del contexto env
para acceder a los valores de las variables de entorno
Adicionalmente a las variables de entorno del ejecutor, GitHub Actions también te permite configurar y leer los valores clave env
utilizando contextos. Se pretende utilizar las variables de ambiente y contextos en puntos diferentes del flujo de trabajo.
Un ejecutor procesa los pasos run
de un flujo de trabajo o de una acción a la que se hace referencia. Como resultado, puede usar las variables de entorno del ejecutor aquí, mediante la sintaxis adecuada para el shell que está utilizando en el ejecutor; por ejemplo, $NAME
para el shell de Bash en un ejecutor de Linux o $env:NAME
para PowerShell en un ejecutor de Windows. En la mayoría de los casos también puede usar contextos, con la sintaxis ${{ CONTEXT.PROPERTY }}
, para tener acceso al mismo valor. La diferencia es que el contexto se interpolará y reemplazará por una cadena antes de enviar el trabajo a un ejecutor.
Sin embargo, no puede utilizar las variables de entorno de ejecutor en partes de un flujo de trabajo que son procesadas por GitHub Actions y no son enviadas al ejecutor. En su lugar, puedes utilizar contextos. Por ejemplo, GitHub Actions siempre procesará un condicional if
, el cual determina si un trabajo o paso se envía al ejecutor o no. Tendrá que utilizar un contexto en una declaración condicional if
para acceder al valor de una variable.
name: Conditional env variable on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" if: ${{ env.DAY_OF_WEEK == 'Monday' }} run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Conditional env variable
on: workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
if: ${{ env.DAY_OF_WEEK == 'Monday' }}
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
En esta modificación del primer ejemplo, hemos introducido un valor if
condicional. Ahora, el paso del flujo de trabajo solo se ejecuta si DAY_OF_WEEK
está establecido en "Monday". Accedemos a este valor desde la instrucción condicional if
mediante el contexto env
. El contexto env
no es necesario para las variables a las que se hace referencia en el comando run
. Se hace referencia a ellas como variables de entorno de ejecutor y se interpolan después de que el ejecutor reciba el trabajo. Sin embargo, podríamos haber elegido interpolar esas variables antes de enviar el trabajo al ejecutor mediante contextos. La salida resultante sería la misma.
run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!"
Nota: Normalmente, los contextos se denotan con el signo del dólar y las llaves, como ${{ context.property }}
. En un condicional if
, ${{
y }}
son opcionales, pero si los usa, deben incluir toda la instrucción de comparación, como se muestra anteriormente.
Habitualmente, utilizarás el contexto env
o github
para acceder a los valores de variables en partes del flujo de trabajo que se procesan antes de que los trabajos se envíen a los ejecutores.
Context | Caso de uso | Ejemplo |
---|---|---|
env | Referencia las variables personalizadas que se definen en el flujo de trabajo. | ${{ env.MY_VARIABLE }} |
github | Referenciar información sobre la ejecución de flujo de trabajo y el evento que activó dicha ejecución. | ${{ github.repository }} |
Advertencia: Cuando cree flujos de trabajo y acciones, siempre debe considerar si el código podría ejecutar entradas no confiables de atacantes potenciales. Se tratará a algunos contextos como una entrada no confiable, ya que un atacante podrían insertar su propio contenido malintencionado. Para obtener más información, vea «Fortalecimiento de seguridad para GitHub Actions».
Uso del contexto vars
para acceder a los valores de las variables de configuración
Se puede acceder a las variables de configuración en el flujo de trabajo mediante el contexto vars
. Para más información, consulta "Acceso a información contextual sobre ejecuciones de flujo de trabajo".
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 }}
Variables de entorno predeterminadas
Las variables de ambiente predeterminadas que configura GitHub están disponibles para cada paso en un flujo de trabajo.
Dado que las variables de entorno predeterminadas las establece GitHub y no se definen en un flujo de trabajo, no son accesibles a través del contexto env
. Sin embargo, la mayoría de las variables predeterminadas tienen una propiedad de contexto correspondiente y con un nombre similar. Por ejemplo, el valor de la variable GITHUB_REF
se puede leer durante el procesamiento del flujo de trabajo mediante la propiedad de contexto ${{ github.ref }}
.
No se puede sobrescribir el valor de las variables de entorno predeterminadas GITHUB_*
y RUNNER_*
. Actualmente, se puede sobrescribir el valor de la variable CI
. Sin embargo, no se garantiza que sea posible siempre. Para obtener más información sobre cómo establecer variables de entorno, consulta "Definición de variables de entorno para un único flujo de trabajo" y "Comandos de flujo de trabajo para Acciones de GitHub".
Te recomendamos encarecidamente que las acciones usen variables para acceder al sistema de archivos en lugar de usar rutas de archivo codificadas de forma rígida. GitHub establece variables para que las acciones se utilicen en todos los entornos del ejecutador.
Variable | Descripción |
---|---|
CI | Siempre se establece en true . |
GITHUB_ACTION | Nombre de la acción actualmente en ejecución, o bien el valor id de un paso. Por ejemplo, para una acción, __repo-owner_name-of-action-repo .GitHub quita caracteres especiales y usa el nombre __run cuando el paso actual ejecuta un script sin id . Si utilizas el mismo script o acción más de una vez en el mismo job, el nombre incluirá un sufijo que consiste del número de secuencia precedido por un guión bajo. Por ejemplo, el primer script que ejecute tendrá el nombre __run y el segundo el nombre __run_2 . Del mismo modo, la segunda invocación de actions/checkout será actionscheckout2 . |
GITHUB_ACTION_PATH | La ruta donde se ubica una acción. Esta propiedad solo es compatible en las acciones compuestas. Puedes utilizar esta ruta para modificar los directorios a donde se ubica la acción y acceder a otros archivos que se ubican en el mismo repositorio. Por ejemplo, /home/runner/work/_actions/repo-owner/name-of-action-repo/v1 . |
GITHUB_ACTION_REPOSITORY | En el caso de un paso que ejecuta una acción, este es el propietario y el nombre de repositorio de la acción. Por ejemplo: actions/checkout . |
GITHUB_ACTIONS | Defínalo siempre en true cuando GitHub Actions esté ejecutando el flujo de trabajo. Puedes usar esta variable para diferenciar cuando las pruebas se ejecutan de forma local o mediante GitHub Actions. |
GITHUB_ACTOR | El nombre de la persona o de la aplicación que inició el flujo de trabajo. Por ejemplo, octocat . |
GITHUB_ACTOR_ID | El id. de cuenta de la persona o aplicación que desencadenó la ejecución inicial del flujo de trabajo. Por ejemplo, 1234567 . Ten en cuenta que es diferente del nombre de usuario del actor. |
GITHUB_API_URL | Devuelve la URL de la API. Por ejemplo: http(s)://HOSTNAME/api/v3 . |
GITHUB_BASE_REF | El nombre de la ref base o rama destino de la solicitud de cambios en una ejecución de flujo de trabajo. Esto solo se establece cuando el evento que desencadena una ejecución de flujo de trabajo es pull_request o pull_request_target . Por ejemplo, main . |
GITHUB_ENV | La ruta en el ejecutor del archivo que define las variables desde los comandos del flujo de trabajo. La ruta de este archivo es única para el paso actual y cambia para cada paso de un trabajo. Por ejemplo, /home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a . Para obtener más información, vea «Comandos de flujo de trabajo para Acciones de GitHub». |
GITHUB_EVENT_NAME | El nombre del evento que activó el flujo de trabajo. Por ejemplo: workflow_dispatch . |
GITHUB_EVENT_PATH | La ruta al archivo en el ejecutor que contiene toda la carga útil del webhook del evento. Por ejemplo, /github/workflow/event.json . |
GITHUB_GRAPHQL_URL | Devuelve la URL de la API de GraphQL. Por ejemplo: http(s)://HOSTNAME/api/graphql . |
GITHUB_HEAD_REF | El ref de encabezado de la rama origen de la solicitud de cambios en una ejecución de flujo de trabajo. Esta propiedad solo se establece cuando el evento que desencadena una ejecución de flujo de trabajo es pull_request o pull_request_target . Por ejemplo: feature-branch-1 . |
GITHUB_JOB | job_id del trabajo actual. Por ejemplo, greeting_job . |
GITHUB_OUTPUT | La ruta en el ejecutor al archivo que define las las salidas del paso actual desde los comandos del flujo de trabajo. La ruta de este archivo es única para el paso actual y cambia para cada paso de un trabajo. Por ejemplo, /home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0 . Para obtener más información, vea «Comandos de flujo de trabajo para Acciones de GitHub». |
GITHUB_PATH | La ruta en el ejecutor del archivo que define las variables PATH de entorno desde los comandos del flujo de trabajo. La ruta de este archivo es única para el paso actual y cambia para cada paso de un trabajo. Por ejemplo, /home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5 . Para obtener más información, vea «Comandos de flujo de trabajo para Acciones de GitHub». |
GITHUB_REF | Referencia de formato completo de la rama o etiqueta que desencadenó la ejecución del flujo de trabajo. En el caso de los flujos de trabajo desencadenados por push , se trata de la rama o la etiqueta ref que se insertó. En el caso de los flujos de trabajo desencadenados por pull_request , se trata de la rama de combinación de solicitudes de incorporación de cambios. En el caso de los flujos de trabajo desencadenados por release , se trata de la etiqueta de versión creada. Para otros desencadenadores, se trata de la rama o la etiqueta ref que desencadenó la ejecución del flujo de trabajo. Esto solo se configura si una rama o etiqueta se encuentra disponible para el tipo de evento. La etiqueta ref especificada tiene el formato completo, lo que significa que para las ramas el formato es refs/heads/<branch_name> , para las solicitudes de incorporación de cambios es refs/pull/<pr_number>/merge y para las etiquetas es refs/tags/<tag_name> . Por ejemplo, refs/heads/feature-branch-1 . |
GITHUB_REF_NAME | Nombre de referencia corto de la rama o etiqueta que desencadenó la ejecución del flujo de trabajo. Este valor coincide con el nombre de la rama o etiqueta que se muestra en GitHub. Por ejemplo, feature-branch-1 .En el caso de las solicitudes de incorporación de cambios, el formato es <pr_number>/merge . |
GITHUB_REF_PROTECTED | true si las protecciones de rama están configurados para la referencia que desencadenó la ejecución del flujo de trabajo. |
GITHUB_REF_TYPE | El tipo de ref que activó la ejecución de flujo de trabajo. Los valores válidos son branch y tag . |
GITHUB_REPOSITORY | El nombre del repositorio y del propietario. Por ejemplo, octocat/Hello-World . |
GITHUB_REPOSITORY_ID | El id. del repositorio. Por ejemplo, 123456789 . Ten en cuenta que esto es diferente del nombre del repositorio. |
GITHUB_REPOSITORY_OWNER | Nombre de usuario del propietario del repositorio. Por ejemplo, octocat . |
GITHUB_REPOSITORY_OWNER_ID | Id. de cuenta del propietario del repositorio. Por ejemplo, 1234567 . Tenga en cuenta que es diferente del nombre del propietario. |
GITHUB_RETENTION_DAYS | Número de días que se conservan los registros y artefactos de ejecución del flujo de trabajo. Por ejemplo, 90 . |
GITHUB_RUN_ATTEMPT | Número único para cada intento de ejecución de un flujo de trabajo particular en un repositorio. Este número comienza en 1 para el primer intento de ejecución del flujo de trabajo e incrementa con cada re-ejecución. Por ejemplo, 3 . |
GITHUB_RUN_ID | Un número único para cada ejecución de flujo de trabajo dentro de un repositorio. Este número no cambia si vuelves a ejecutar el flujo de trabajo. Por ejemplo, 1658821493 . |
GITHUB_RUN_NUMBER | Un número único para cada ejecución de un flujo de trabajo particular en un repositorio. Este número comienza por 1 para la primera ejecución del flujo de trabajo y aumenta con cada nueva ejecución. Este número no cambia si vuelves a ejecutar el flujo de trabajo. Por ejemplo, 3 . |
GITHUB_SERVER_URL | Dirección URL del servidor de GitHub Enterprise Server. Por ejemplo: https://HOSTNAME . |
GITHUB_SHA | El SHA de confirmación que activó el flujo de trabajo. El valor de este SHA de confirmación depende del evento que activó el flujo de trabajo. Para obtener más información, vea «Eventos que desencadenan flujos de trabajo». Por ejemplo, ffac537e6cbbf934b08745a378932722df287a53 . |
GITHUB_STEP_SUMMARY | La ruta de acceso del ejecutor al archivo que contiene resúmenes de trabajos de comandos de flujo de trabajo. La ruta de este archivo es única para el paso actual y cambia para cada paso de un trabajo. Por ejemplo, /home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c . Para obtener más información, vea «Comandos de flujo de trabajo para Acciones de GitHub». |
GITHUB_TRIGGERING_ACTOR | Nombre de usuario del usuario que inició la ejecución del flujo de trabajo. Si la ejecución del flujo de trabajo es una repetición, este valor puede ser distinto de github.actor . Todas las repeticiones de ejecución de flujo de trabajo usarán los privilegios de github.actor , incluso si el actor que inicia la repetición de la ejecución (github.triggering_actor ) tiene otros privilegios. |
GITHUB_WORKFLOW | El nombre del flujo de trabajo. Por ejemplo, My test workflow . Si el archivo de flujo de trabajo no especifica ninguna name , el valor de esa variable es la ruta completa del archivo del flujo de trabajo en el repositorio. |
GITHUB_WORKFLOW_REF | La ruta de acceso de referencia al flujo de trabajo. Por ejemplo, octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch . |
GITHUB_WORKFLOW_SHA | El SHA de confirmación para el archivo de flujo de trabajo. |
GITHUB_WORKSPACE | Directorio de trabajo predeterminado en el ejecutor para los pasos y la ubicación predeterminada del repositorio al usar la acción checkout . Por ejemplo, /home/runner/work/my-repo-name/my-repo-name . |
RUNNER_ARCH | La arquitectura del ejecutor que ejecuta el job. Los valores posibles son X86 , X64 , ARM o ARM64 . |
RUNNER_DEBUG | Esto solo se establece si el registro de depuración está habilitado y siempre tiene el valor de 1 . Puede ser útil como indicador para habilitar la depuración adicional o el registro detallado en tus propios pasos de trabajo. |
RUNNER_ENVIRONMENT | El entorno del ejecutor que ejecuta el trabajo. Los valores posibles son: github-hosted para los ejecutores hospedados en GitHub proporcionados por GitHub y self-hosted para los ejecutores de prueba interna configurados por el propietario del repositorio. |
RUNNER_NAME | El nombre del ejecutor que ejecuta el job. Este nombre puede no ser único en una ejecución de flujo de trabajo como ejecutores en el repositorio y los niveles de organización podrían usar el mismo nombre. Por ejemplo, Hosted Agent |
RUNNER_OS | El sistema operativo del ejecutor que ejecuta el trabajo. Los valores posibles son Linux , Windows o macOS . Por ejemplo, Windows |
RUNNER_TEMP | La ruta a un directorio temporal en el ejecutor. Este directorio se vacía al inicio y al final de cada job. Nota que los archivos no se eliminarán si la cuenta de usuario del ejecutor no tiene permisos para borrarlos. Por ejemplo, D:\a\_temp |
RUNNER_TOOL_CACHE | La ruta al directorio que contiene las herramientas preinstaladas para los ejecutores hospedados en GitHub. Para más información, consulta "Utilizar los ejecutores hospedados en GitHub". Por ejemplo, C:\hostedtoolcache\windows |
Nota: Si necesitas usar la dirección URL de la ejecución de un flujo de trabajo desde un trabajo, puedes combinar estas variables: $GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID
Detectar el sistema operativo
Puede generar un único archivo de flujo de trabajo que se pueda usar para distintos sistemas operativos mediante la variable de entorno predeterminada RUNNER_OS
y la propiedad de contexto correspondiente ${{ runner.os }}
. Por ejemplo, el siguiente flujo de trabajo puede ejecutarse correctamente si ha cambiado el sistema operativo de macos-latest
a windows-latest
sin tener que alterar la sintaxis de las variables de entorno, lo cual difiere dependiendo del shell que esté utilizando el ejecutor.
on: workflow_dispatch jobs: if-Windows-else: runs-on: macos-latest steps: - name: condition 1 if: runner.os == 'Windows' run: echo "The operating system on the runner is $env:RUNNER_OS." - name: condition 2 if: runner.os != 'Windows' run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
on: workflow_dispatch
jobs:
if-Windows-else:
runs-on: macos-latest
steps:
- name: condition 1
if: runner.os == 'Windows'
run: echo "The operating system on the runner is $env:RUNNER_OS."
- name: condition 2
if: runner.os != 'Windows'
run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
En este ejemplo, las dos instrucciones if
comprueban la propiedad os
del contexto runner
para determinar el sistema operativo del ejecutor. GitHub Actions procesa los condicionales if
y solo los pasos en donde la comprobación se resuelve de manera que se envían los true
al ejecutor. Una de las comprobaciones siempre será true
y la otra false
, por lo que solo se envía uno de estos pasos al ejecutor. Una vez enviado el trabajo al ejecutor, el paso se ejecuta y la variable de entorno del comando echo
se interpola mediante la sintaxis adecuada ($env:NAME
para PowerShell en Windows y $NAME
para bash y sh en Linux y macOS). En este ejemplo, la instrucción runs-on: macos-latest
significa que se ejecutará el segundo paso.
Pasar valores entre pasos y jobs en un flujo de trabajo
Si genera un valor en un paso de un trabajo, puede utilizar dicho valor en los pasos siguientes del mismo trabajo. Para ello, asigne el valor a una variable de entorno nueva o existente y escriba lo siguiente en el archivo de entorno GITHUB_ENV
. Una acción puede utilizar directamente el archivo de entorno, o puede utilizarse desde un comando de shell en el archivo de flujo de trabajo con la palabra clave run
. Para obtener más información, vea «Comandos de flujo de trabajo para Acciones de GitHub».
Si quieres pasar un valor desde un paso en un job que está en un flujo de trabajo a un paso en otro job del mismo flujo de trabajo, puedes definir el valor como una salida de job. Puedes entonces referenciar esta salida de job desde un paso en otro job. Para obtener más información, vea «Sintaxis del flujo de trabajo para Acciones de GitHub».