Configurar secrets y variables en GitHub Actions te permite reutilizar valores en tus workflows y proteger información sensible como contraseñas o credenciales. Aquí verás la diferencia entre ambos, cómo declararlos y cómo accederlos desde un job, partiendo de un reto práctico con un archivo variables.yml.

Cómo se resuelve el reto del workflow con variables

El reto consistía en crear un archivo variables.yml dentro de .github/workflows que usara variables, ya sea con la palabra reservada env o con variables a nivel de repositorio.

Qué estructura debe tener el archivo variables.yml

El nombre exacto del archivo importa: las acciones del repositorio detectan variables.yml para validar que completaste el reto. La configuración base incluye:

• Un name y un run-name para identificarlo en la pestaña Actions.
• Un trigger workflow_dispatch para ejecutarlo manualmente.
• Una variable env a nivel de workflow llamada dia_de_la_semana con valor lunes.
• Un job saludo_variables con su propia variable env llamada saludo con valor hola.

Dentro del único step se imprime un echo que combina tres fuentes distintas de datos. La primera es la variable saludo, declarada a nivel de job. La segunda es ${{ vars.nombre }}, que accede a la variable nombre configurada a nivel de repositorio (con valor Juan) gracias al contexto vars. La tercera es el día de la semana.

Cuál es la diferencia entre acceder con $ y con el contexto env

Hay dos formas válidas de leer una variable de entorno dentro del runner. Como el runner corre en Ubuntu, puedes usar la sintaxis del sistema operativo: $dia_de_la_semana. La otra opción es usar el contexto propio de GitHub Actions: ${{ env.dia_de_la_semana }}.

¿Cuándo uso vars y cuándo uso env? Usa env para variables que defines dentro del archivo del workflow. Usa vars para acceder a variables configuradas en Settings del repositorio.

Qué son los secrets en GitHub Actions y para qué sirven

Los secrets viven en Settings > Secrets and variables > Actions, en la pestaña Secrets. Funcionan parecido a las variables, pero con una diferencia crítica: una vez guardas un secret, no puedes volver a ver su valor, solo su key.

Cuándo usar secrets en lugar de variables

Las variables son para datos no sensibles que cualquier persona con acceso al repositorio puede ver sin riesgo. Los secrets son para información que, si se filtra, compromete tu aplicación o a tus usuarios. Algunos casos típicos:

• Contraseñas de cuentas o bases de datos.
• Access keys de servicios cloud como AWS.
• Tokens de APIs de terceros.
• Credenciales de configuración de servidores.

Para crear uno, das clic en New secret, defines un key (por ejemplo contraseña) y un valor (por ejemplo mi contraseña supersegura). Después de guardarlo, solo podrás eliminarlo o sobreescribirlo. Por eso, guarda siempre el valor original en un lugar seguro antes de registrarlo.

¿Puedo recuperar el valor de un secret después de guardarlo? No. GitHub oculta el valor de forma permanente. Solo puedes editarlo para asignar uno nuevo o eliminarlo.

Cómo accedo a un secret desde un workflow

Para verlo en acción, se crea un nuevo archivo secretos.yml directamente en la rama main, separado de la rama aprendiendo-github-actions donde viven los retos con pull request abierto.

Cómo se declara el job que usa el secret

El workflow reutiliza el job saludo_variables y agrega uno nuevo, saludo_secretos, que corre sobre ubuntu-latest. Su único step imprime un mensaje que combina:

• La variable env.saludo definida en el workflow.
• La variable vars.nombre del repositorio.
• El secret con ${{ secrets.contraseña }}.

El contexto secrets te da acceso a cualquier key registrada en la sección de Secrets. La sintaxis siempre es ${{ secrets.NOMBRE_DEL_SECRET }}.

Cómo se ejecuta y se prueba el workflow

Al hacer commit usando una convención tipo conventional commits (feat: agregar nuevo workflow), el archivo queda disponible. Como el trigger es workflow_dispatch, debes ir a la pestaña Actions, seleccionar el workflow saludo usando variables y secretos, elegir la rama main y dar clic en Run workflow.

Al ejecutarse, GitHub Actions enmascara automáticamente el valor del secret en los logs, así que aunque alguien vea la salida, no podrá leer la contraseña.

Dónde aplicar secrets en un caso real

Un ejemplo común es subir una aplicación a un servidor en la nube. Si buscas una action en el GitHub Marketplace que despliegue a AWS, esa action te pedirá configurar las access keys como variables de entorno. Esos valores son altamente sensibles: si quedan a la luz pública, alguien podría tomar control de tu cuenta.

La solución correcta es guardarlos como secrets en el repositorio y pasarlos a la action mediante el contexto secrets. Así protegerías credenciales, llaves de APIs y cualquier dato que no debería salir del entorno seguro de GitHub.

Deja en los comentarios un ejemplo de workflow file donde uses secrets para pasarlos a una action que lo requiera, ya sea un despliegue a AWS u otro caso que se te ocurra.