Prueba Práctica de GitHub Actions
### ¿Cuál afirmación es correcta respecto a la transferencia de permisos a los workflows reutilizables?
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#access-and-permissions
1. [x] Los permisos de `GITHUB_TOKEN` transferidos desde el workflow que llama solo pueden ser reducidos por el workflow llamado.
1. [ ] Los permisos de `GITHUB_TOKEN` transferidos desde el workflow que llama solo pueden ser elevados por el workflow llamado.
1. [ ] Los permisos de `GITHUB_TOKEN` transferidos desde el workflow que llama pueden ser tanto reducidos como elevados por el workflow llamado.
1. [ ] Los permisos de `GITHUB_TOKEN` transferidos desde el workflow que llama no pueden ser ni reducidos ni elevados por el workflow llamado.
### ¿Cuáles son los diferentes niveles de permisos que puedes asignar a `GITHUB_TOKEN` en el bloque `permissions`?
> https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
1. [x] none, write, read
1. [ ] read, write, delete
1. [ ] read, write
### Puedes utilizar `permissions` para modificar los permisos de `GITHUB_TOKEN` en: (Selecciona dos.)
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token
- [x] Nivel de flujo de trabajo
- [x] Nivel de trabajo
- [ ] Nivel de paso
### ¿Son GitHub Actions gratuitos para repositorios públicos?
1. [x] Sí
1. [ ] No
### ¿Cuál de estos no es un evento válido que podría activar un workflow?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Clonar el repository
1. [ ] Hacer commit de un archivo en la rama master
1. [ ] Crear una rama
1. [ ] Agregar una etiqueta a un pull request
### ¿Qué es cierto sobre los workflows? (Selecciona tres.)
> https://docs.github.com/en/actions/using-workflows/about-workflows
- [x] Los workflows pueden ejecutar uno o varios jobs a la vez
- [x] Los workflows pueden ser activados manualmente, por un evento o ejecutados en un horario
- [x] Los workflows deben ser definidos en el directorio `.github/workflows`
- [ ] Los workflows solo pueden ejecutarse en un horario
- [ ] Un workflow solo puede ejecutar un job a la vez
- [ ] Los workflows se escriben en cualquiera de los formatos `.yaml`, `.json` o `.toml`
- [ ] Los workflows pueden compartirse en GitHub Marketplace
> Las Actions (no los workflows) pueden compartirse en GitHub Marketplace
### ¿Qué componentes se requieren para un workflow? (Seleccione dos.)
> https://docs.github.com/en/actions/using-workflows/about-workflows#workflow-basics
- [x] Uno o más eventos que desencadenarán el workflow
- [x] Uno o más jobs
- [ ] Nombre del workflow
- [ ] Ramas definidas en las que se ejecutará el workflow
### ¿Qué evento es activado por una acción de webhook desde fuera del repository?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] repository_dispatch
1. [ ] webhook_dispatch
1. [ ] workflow_dispatch
1. [ ] remote_dispatch
1. [ ] api_dispatch
### ¿En qué formato se definen los Workflows?
1. [x] yaml
1. [ ] toml
1. [ ] json
1. [ ] xml
### ¿Dónde deberías almacenar datos sensibles como contraseñas o certificados que se utilizarán en workflows?
1. [x] secrets
1. [ ] variables de configuración
1. [ ] vault
1. [ ] variables de entorno
### En un workflow con múltiples jobs, el comportamiento predeterminado es:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] Todos los jobs se ejecutan en paralelo
1. [ ] Los jobs se ejecutan en secuencia
### Si el trabajo B requiere que el trabajo A esté terminado, debes:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] usar la palabra clave `needs` en el trabajo B para crear esta dependencia
1. [ ] usar la palabra clave `needs` en el trabajo A para crear esta dependencia
1. [ ] usar la palabra clave `requires` en el trabajo B para crear esta dependencia
1. [ ] usar la palabra clave `requires` en el trabajo A para crear esta dependencia
### En un workflow con múltiples jobs, si el job A falla entonces:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] los jobs que dependen del job A se omiten
1. [ ] los jobs que dependen del job A fallan
1. [ ] el workflow cancela inmediatamente todos los demás jobs
### Este código ejecutará 6 trabajos diferentes en paralelo utilizando la estrategia de matriz. ¿Puedes usar la estrategia de matriz para paralelizar flujos de trabajo completos?
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-a-matrix-strategy-with-a-reusable-workflow
1. [ ] No
1. [x] Sí
### ¿Cuál definición de trabajo matricial es sintácticamente correcta?
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x]
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
example_matrix:
matrix:
strategy:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
example_matrix:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
### ¿Cómo se accede a variables de matriz en un trabajo con estrategia de matriz?
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [ ] Usando el contexto `vars`
1. [x] Usando el contexto `matrix`
1. [ ] Usando el contexto `job`
1. [ ] Usando el contexto `jobs`
### Al usar los eventos `pull_request` y `pull_request_target`, ¿cómo configuras el workflow para que se ejecute solo cuando se dirija a la rama `prod`?
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-for-pull-request-events
1. [x] Usando el filtro `branches`
1. [ ] Usando el filtro `branch`
1. [ ] Creas el workflow solo en la rama `prod`
1. [ ] Usando patrones globulares
### Este flujo de trabajo se ejecutará en todos los pull requests donde:
```yaml
on:
pull_request:
branches:
- 'release/**'
- '!release/**-alpha'
```
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#example-including-and-excluding-branches
1. [x] el nombre de la rama de destino comienza con `release` pero no termina con `-alpha`
1. [ ] el nombre de la rama de destino comienza con `release`
1. [ ] el nombre de la rama de origen comienza con `release` pero no termina con `-alpha`
1. [ ] el nombre de la rama de origen comienza con `release`
### Completa el espacio en blanco: Al usar filtros de activación de eventos `push`, puedes usar patrones de <____> para dirigir múltiples ramas
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-or-tags-for-push-events
1. [x] glob
1. [ ] regex
1. [ ] scheme
1. [ ] action
### ¿Qué evento te permite activar manualmente un workflow desde la interfaz de GitHub?
> https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow
1. [x] workflow_dispatch
1. [ ] manual_dispatch
1. [ ] workflow_trigger
1. [ ] manual_trigger
### ¿Cuáles son los tipos posibles de una variable de entrada para un workflow activado manualmente? (Seleccione cinco.)
> https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputsinput_idtype
- [x] choice
- [x] boolean
- [x] string
- [x] number
- [x] environment
- [ ] dropdown
- [ ] select
### Un flujo de trabajo que solo tiene el evento desencadenador `workflow_dispatch` puede ser activado usando la REST API de GitHub
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
1. [x] Verdadero
1. [ ] Falso
### Para detener temporalmente la ejecución de un workflow sin modificar el código fuente, deberías
> https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow
1. [x] Usar la opción `Disable workflow` en GitHub Actions
1. [ ] Eliminar los secretos requeridos para este workflow
1. [ ] Eliminar el entorno requerido para este workflow
1. [ ] Evitar nuevos commits en la rama principal
### ¿Para qué se utilizan los `activity types` de un evento?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Limitar las ejecuciones de workflows a tipos de actividad específicos utilizando el filtro `types`
1. [ ] Verificar si la actividad proviene de un usuario o un bot
1. [ ] Reaccionar a nueva actividad en un repository (por ejemplo, un nuevo colaborador)
### Quieres crear un flujo de trabajo reutilizable `CI` que ejecute algunas verificaciones de calidad, linting y pruebas en los cambios de código. ¿Qué evento desencadenante debería definir el flujo de trabajo `CI` para permitir que se reutilice en otros flujos de trabajo?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] workflow_call
1. [ ] workflow_trigger
> No existe tal evento desencadenante
1. [ ] workflow_dispatch
> Esto se utiliza para disparadores manuales
1. [ ] workflow_run
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
### Un flujo de trabajo reutilizable llamado `build` crea artefactos de archivos zip. ¿Cómo pasas la ubicación del archivo zip al flujo de trabajo que llama al flujo de trabajo `build`? (Selecciona tres.)
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow
- [x] Defines una salida a nivel de flujo de trabajo en el flujo de trabajo `build`
- [x] Defines una salida a nivel de trabajo en el flujo de trabajo `build`
- [x] En el flujo de trabajo `build` escribes la salida en `$GITHUB_OUTPUT` en uno de los pasos
- [ ] Todas las salidas se pasan automáticamente a los flujos de trabajo que llaman
### ¿Cuáles son los casos de uso válidos para utilizar **defaults**? (Seleccione dos.)
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults
- [x] Usar defaults.run a nivel de workflow para establecer el shell predeterminado (por ejemplo, bash) para todo un workflow
- [x] Usar defaults.run a nivel de job para establecer el directorio de trabajo predeterminado para todos los pasos en un solo job
- [ ] Usar defaults.run a nivel de step para establecer el shell predeterminado (por ejemplo, bash) para ese único paso
> defaults.run solo puede configurarse a nivel de workflow o de job
- [ ] Usar defaults.env a nivel de workflow para establecer variables de entorno predeterminadas para todo un workflow
> No existe defaults.env
- [ ] Usar defaults.env a nivel de job para establecer variables de entorno predeterminadas para todos los pasos en un solo job
> No existe defaults.env
### ¿Cómo puedes asegurarte de que un flujo de trabajo llamado `Deploy Prod` siempre se ejecute como máximo una vez a la vez?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
1. [x] Usar `concurrency` a nivel del flujo de trabajo
```yaml
concurrency: ${{ github.workflow }}
```
1. [ ] Usar `queue` a nivel del flujo de trabajo
```yaml
queue: ${{ github.workflow }}
```
1. [ ] Usar `order` a nivel del flujo de trabajo
```yaml
order: ${{ github.workflow }}
```
1. [ ] Usar `parallel` a nivel del flujo de trabajo
```yaml
parallel: ${{ github.workflow }}
```
### Su flujo de trabajo de análisis de Pull Request utiliza múltiples herramientas de análisis de código y demora aproximadamente 20 minutos en completarse completamente. Se activa con el evento `pull_request` con el filtro `branches` configurado en `master`. Por lo tanto, si un desarrollador realiza múltiples commits en pocos minutos, se ejecutan múltiples flujos de trabajo en paralelo. ¿Cómo puede detener todas las ejecuciones de flujo de trabajo anteriores y ejecutar solo la que contiene los últimos cambios?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-concurrency-to-cancel-any-in-progress-job-or-run
1. [x] Usar concurrency con cancel-in-progress
```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
```
1. [ ] Usar concurrency
```yaml
concurrency:
group: ${{ github.ref }}
```
> Esto colocaría en cola las ejecuciones en esa referencia de GitHub. No detendrá ejecuciones anteriores.
1. [ ] Usar filtro de tipos de actividad
```yaml
on:
pull_request:
branches:
- master
types: [latest]
```
> No existe un tipo de actividad denominado `latest` para el evento pull_request.
1. [ ] Usar la bandera cancel-in-progress para el evento `pull_request`
```yaml
on:
pull_request:
branches:
- master
cancel-in-progress: true
```
### ¿Cuándo se ejecutará job3?
```yaml
jobs:
job1:
job2:
needs: job1
job3:
if: ${{ always() }}
needs: [job1, job2]
```
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-not-requiring-successful-dependent-jobs
1. [x] job3 se ejecutará después de que job1 y job2 hayan finalizado, independientemente de si tuvieron éxito o no
1. [ ] No se puede usar `if: ${{ always() }}` y `needs` juntos. El flujo de trabajo fallará al iniciarse.
1. [ ] job3 se ejecutará después de que job1 y job2 se hayan completado con éxito
1. [ ] job3 se ejecutará después de que tanto job1 como job2 hayan fallado
### ¿Qué condicional `jobs.job_id.if` garantizará que el job `production-deploy` se active solo en el repositorio `my-org/my-repo`? (Selecciona dos.)
```yaml
jobs:
production-deploy:
if: <CONDITION>
runs-on: ubuntu-latest
steps:
...
```
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
- [x] `if: github.repository == 'my-org/my-repo'`
- [x] `if: ${{ github.repository == 'my-org/my-repo' }}`
- [ ] `if: ${{ github.organization == 'my-org' && github.repository == 'my-repo' }}`
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
- [ ] `if: ${{ github.org == 'my-org' && github.repository == 'my-repo' }}`
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
### ¿Qué tipos de runners alojados por GitHub están disponibles para usar? (Selecciona tres.)
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners
- [x] Windows
- [x] Ubuntu Linux
- [x] macOS
- [ ] Android
### ¿Es verdadera esta afirmación? `Not all steps run actions, but all actions run as a step`
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps
1. [x] Verdadero
1. [ ] Falso
> Los pasos pueden, pero no necesariamente deben ejecutar acciones (por ejemplo, ejecutar un comando run)
### Para cualquier acción publicada en GitHub Marketplace, a menudo puedes usarla en múltiples versiones, ¿qué enfoque es el más estable y seguro?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-versioned-actions
1. [x] Referenciar el commit SHA
1. [ ] Referenciar una etiqueta de versión
1. [ ] Referenciar la rama principal
### Para evitar que un trabajo falle cuando uno de los pasos falla, puedes incluir:
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error
1. [x] La bandera `continue-on-error` en el paso que falla
```yaml
steps:
- uses: my-org/failing-action@v1
continue-on-error: true
```
1. [ ] La bandera `ignore-error` en el paso que falla
```yaml
steps:
- uses: my-org/failing-action@v1
ignore-error: true
```
1. [ ] La condicional `failure()` en el paso que falla
```yaml
steps:
- uses: my-org/failing-action@v1
if: failure()
```
1. [ ] La condicional `always()` en el paso que falla
```yaml
steps:
- uses: my-org/failing-action@v1
if: always()
```
### Has definido un trabajo matricial `example_matrix`. ¿Cómo puedes limitar la matriz para que ejecute un máximo de 2 trabajos a la vez?
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel
1. [x] Establecer `jobs.example_matrix.strategy.max-parallel` en 2
1. [ ] Establecer `jobs.example_matrix.strategy.concurrency` en 2
1. [ ] Usar la REST API de GitHub para verificar si la cantidad de trabajos es menor que 2
1. [ ] No es posible, una matriz siempre ejecutará todos los trabajos en paralelo si hay runners disponibles
### ¿Cuál de estos es un método correcto para establecer un parámetro de salida `PET` con un valor de `DOG` en un `step`?
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter
1. [x] `echo "PET=DOG" >> "$GITHUB_OUTPUT"`
1. [ ] `echo "DOG=PET" >> "$GITHUB_OUTPUT"`
1. [ ] `gh set-output "DOG=PET"`
1. [ ] `gh set-output "PET=DOG"`
### ¿Cuál de estas es una forma de usar `action_state` en `step_two`?
```yaml
steps:
- name: Set the value
id: step_one
run: |
echo "action_state=yellow" >> "$GITHUB_ENV"
- name: Use the value
id: step_two
run: ?
```
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-of-writing-an-environment-variable-to-github_env
1. [x] `run: echo "$action_state"`
1. [ ] `run: echo "${{ steps.step_one.outputs.action_state }}"`
> Ese sería el caso si `action_state` se escribiera en `$GITHUB_OUTPUT`
1. [ ] `run: echo "$steps.step_one.outputs.action_state"`
1. [ ] `run: echo "${{ action_state }}"`
### ¿Es esta afirmación verdadera? `Los Workflows pueden ser reutilizados, pero un Workflow reutilizable no puede llamar a otro Workflow reutilizable.`
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#nesting-reusable-workflows
1. [x] Falso
1. [ ] Verdadero
> Los Workflows reutilizables pueden anidarse, pero existen limitaciones https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
### En el siguiente ejemplo, `workflow A` pasa todos sus secretos a `workflow B`, utilizando la palabra clave inherit. Luego `workflow B` llama a `workflow C`. ¿Cuál de las siguientes afirmaciones sobre los `secrets` es verdadera para ese ejemplo?
```yaml
jobs:
workflowA-calls-workflowB:
uses: octo-org/example-repo/.github/workflows/B.yml@main
secrets: inherit
```
```yaml
jobs:
workflowB-calls-workflowC:
uses: different-org/example-repo/.github/workflows/C.yml@main
```
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows
1. [x] Todos los secretos disponibles para `workflow A` también estarán disponibles para `workflow B`, pero no para `workflow C`.
1. [ ] Todos los secretos de la organización `octo-org` y del repositorio `octo-org/example-repo` estarán disponibles para `workflow B`, pero no para `workflow C`.
> No todos los secretos de la organización `octo-org` tienen que estar disponibles para `octo-org/example-repo`.
1. [ ] Todos los secretos disponibles para `workflow A` también estarán disponibles para `workflow B` y `workflow C`.
> `Workflow B` necesitaría agregar `secrets: inherit` al llamar a `workflow C`.
1. [ ] Sólo los secretos de repositorio y entorno disponibles para `workflow A` estarán disponibles para `workflow B`, pero no para `workflow C`. Los secretos de alcance organizacional no se pueden heredar.
### ¿Cuándo deberías usar `caching`?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
1. [x] Cuando deseas reutilizar archivos que no cambian con frecuencia entre trabajos o ejecuciones de flujos de trabajo, como las dependencias de compilación de un sistema de gestión de paquetes.
1. [ ] Cuando deseas reutilizar archivos que cambian con frecuencia entre trabajos o ejecuciones de flujos de trabajo, como las dependencias de compilación de un sistema de gestión de paquetes.
1. [ ] Cuando deseas guardar archivos producidos por un trabajo para verlos después de que una ejecución del flujo de trabajo haya terminado, como binarios construidos o registros de compilación.
> Para eso se deben usar Artifacts https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
1. [ ] Cuando deseas guardar binarios producidos por un trabajo de compilación para usarlos en un trabajo de implementación posterior con el fin de desplegar una nueva versión de una aplicación.
> Para eso se deben usar Artifacts https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
### ¿Cuándo deberías usar `artifacts`? (Selecciona dos.)
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#about-workflow-artifacts
- [x] Usa artifacts para guardar archivos producidos por un job para verlos después de que haya terminado la ejecución del workflow, como resultados de pruebas o registros de compilación.
- [x] Usa artifacts para guardar binarios producidos por un job de construcción para usarlos en un job de despliegue posterior y desplegar una nueva versión de una aplicación.
- [ ] Usa artifacts para reutilizar archivos que no cambian frecuentemente entre jobs o ejecuciones de workflows, como dependencias de construcción de un sistema de gestión de paquetes.
> Se debe usar caching para eso https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
- [ ] Usa artifacts para crear nuevas versiones de tu aplicación junto con notas de lanzamiento, menciones y/o colaboradores.
> Eso es un caso de uso para releases, no artifacts.
### Si un workflow se ejecuta en una rama `feature-a`, ¿puede restaurar `caches` creados en la rama predeterminada `main`?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache
1. [x] Sí, todas las ramas pueden restaurar caches creados en la rama predeterminada
1. [ ] Sí, todos los caches pueden ser accedidos por workflows en cualquier rama dentro del mismo repository
1. [ ] No, los caches solo pueden ser restaurados desde la misma rama
1. [ ] Sí, pero solo si no se cambiaron archivos en la rama `feature-a`
### Para acceder a un `artifact` que fue creado en otra ejecución de workflow previamente desencadenada, puedes:
> https://github.com/actions/download-artifact?tab=readme-ov-file#download-artifacts-from-other-workflow-runs-or-repositories
1. [ ] No puedes acceder a los `artifacts` que fueron creados en una ejecución de workflow diferente
1. [x] Usar la acción `actions/download-artifact` con permisos elevados.
1. [ ] Usar la acción `actions/upload-artifact`.
1. [ ] Usar la acción `actions/download-artifact` y asegurarte de que el artifact no haya expirado
### ¿Qué deberías usar para almacenar informes de cobertura o capturas de pantalla generados durante un workflow que ejecuta pruebas automatizadas para un repository?
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] Artifacts
1. [ ] Caches
1. [ ] Packages
> https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages
1. [ ] Releases
> https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
### Solo puedes subir un archivo a la vez al usar la acción `actions/upload-artifact`
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#uploading-build-and-test-artifacts
1. [x] Falso
1. [ ] Verdadero
### En el trabajo `deploy`, si deseas acceder a los binarios (que contienen tu aplicación) creados en el trabajo `build`, deberías
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] subir los binarios como artefactos en `build` y descargarlos en `deploy`
1. [ ] subir los binarios como artefactos en `deploy` y descargarlos en `build`
1. [ ] almacenar en caché los binarios en `build` y leer los archivos desde la caché en `deploy`
1. [ ] almacenar en caché los binarios en `deploy` y leer los archivos desde la caché en `build`
### Un trabajo llamado `job2` está utilizando artefactos creados en `job1`. Por lo tanto, es importante asegurarse de que `job1` termine antes de que `job2` comience a buscar los artefactos. ¿Cómo debes crear esa dependencia?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] crear esta dependencia usando la palabra clave `needs` en `job2`
1. [ ] esta dependencia se crea implícitamente al usar `actions/download-artifact` para descargar el artefacto desde `job1`
1. [ ] crear esta dependencia definiendo `job2` después de `job1` en la definición de `.yaml` del flujo de trabajo
1. [ ] crear esta dependencia usando la palabra clave `concurrency` en `job2`
### ¿Qué es verdadero acerca de `Starter Workflows`? (Selecciona tres.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [x] Permiten a los usuarios aprovechar plantillas de flujos de trabajo listas para usar (o que requieren cambios mínimos)
- [x] GitHub proporciona y mantiene Starter Workflows para diferentes categorías, lenguajes y herramientas
- [x] Tu organización puede crear Starter Workflows personalizados para usuarios dentro de tu organización
- [ ] Los Starter Workflows no pueden llamar a flujos de trabajo reutilizables
- [ ] Los Starter Workflows son una función de GitHub de pago
- [ ] Los Starter Workflows se proporcionan listos para usar y no pueden ser modificados ni mejorados
> https://docs.github.com/en/actions/using-workflows/using-starter-workflows#using-starter-workflows
### Los secretos y las variables de configuración se pueden delimitar a: (Selecciona tres.)
> https://docs.github.com/en/actions/using-workflows/sharing-workflows-secrets-and-runners-with-your-organization#sharing-secrets-and-variables-within-an-organization
- [x] Toda la organización o repositorios seleccionados en una organización
- [x] Un único repositorio
- [x] Un entorno en un repositorio
- [ ] Un entorno compartido entre múltiples repositorios
> Los entornos no pueden compartirse entre repositorios
- [ ] Múltiples repositorios que no comparten una organización/enterprise
- [ ] Un workflow específico en un repositorio
> Las variables de entorno pueden delimitarse a un workflow, las variables de configuración no
- [ ] Un job específico en un workflow
> Las variables de entorno pueden delimitarse a un workflow, las variables de configuración no
### ¿Cuáles son los tres tipos de Actions?
> https://docs.github.com/en/actions/creating-actions/about-custom-actions#types-of-actions
1. [x] `Docker container actions`, `JavaScript Actions`, `Composite Actions`
1. [ ] `Python Actions`, `JavaScript Actions`, `Custom Actions`
1. [ ] `Docker container Actions`, `JavaScript Actions`, `Custom Actions`
1. [ ] `Docker container actions`, `Java Actions`, `Composite Actions`
### ¿Es verdadera esta afirmación? `Las acciones de contenedores Docker suelen ser más lentas que las acciones de JavaScript`
> Las acciones de contenedores Docker son más lentas que las acciones de JavaScript
1. [x] Verdadero
1. [ ] Falso
> Debido a la latencia al construir y recuperar el contenedor, las acciones de contenedores Docker son más lentas que las acciones de JavaScript.
### Cuando creas una GitHub Action personalizada, debes almacenar el código fuente en el directorio `.github/workflows`
> https://docs.github.com/en/actions/creating-actions/about-custom-actions#choosing-a-location-for-your-action
1. [x] Falso
1. [ ] Verdadero
> Eso es cierto para `workflows`, no para `actions`
### Al crear GitHub Actions personalizadas, ¿en qué archivo deben definirse todos los `metadatos` de la acción?
Ejemplos de metadatos: nombre, descripción, salidas o entradas requeridas
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions
1. [x] En el archivo `action.yml` o `action.yaml` en el repositorio de la acción
1. [ ] En el archivo `README` del repositorio
> Aunque es una buena práctica hacerlo, no es un requisito para que la acción funcione
1. [ ] Se edita en la interfaz de usuario de GitHub Marketplace al publicarlo para compartir
1. [ ] En el archivo `action.yml` o `action.yaml` en el repositorio de la acción, pero no es necesario si la acción no está destinada a ser compartida y utilizada por el público
> Todas las acciones requieren el archivo de metadatos.
### Un flujo de trabajo se ejecutó inicialmente en el `commit A` y falló. Solucionaste el flujo de trabajo con el siguiente `commit B`. Cuando vuelvas a ejecutar ese flujo de trabajo, ¿se ejecutará con el código de qué commit?
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#about-re-running-workflows-and-jobs
1. [x] Se ejecutará con el código de `commit A`
1. [ ] Se ejecutará con el código de `commit B`
> Volver a ejecutar un flujo de trabajo utiliza el mismo SHA del commit y la referencia Git del evento original que desencadenó la ejecución del flujo de trabajo.
1. [ ] No puedes volver a ejecutar flujos de trabajo en GitHub Actions. Tienes que desencadenar un nuevo flujo de trabajo que se ejecutará con los últimos cambios
1. [ ] Desencadenará dos flujos de trabajo, uno con el código de `commit A` y otro con el código de `commit B`
### ¿Cómo puedes requerir aprobaciones manuales por parte de un mantenedor si la ejecución del workflow está dirigida al entorno `production`?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] Usando reglas de protección de despliegue
1. [ ] Configurando los revisores requeridos en el workflow de `production`
1. [ ] Usando reglas de protección de rama
1. [ ] Las aprobaciones manuales no son compatibles con GitHub Actions
### ¿Qué es cierto sobre los entornos?
> Cada trabajo en un workflow puede referenciar un único entorno.
1. [x] Cada trabajo en un workflow puede referenciar un único entorno.
1. [ ] Cada workflow puede referenciar un único entorno.
1. [ ] Cada trabajo en un workflow puede referenciar un máximo de dos entornos.
1. [ ] Cada workflow puede referenciar un máximo de dos entornos.
### Al usar GitHub Actions para acceder a recursos en uno de los proveedores de nube (como AWS, Azure o GCP), la forma más segura y recomendada de autenticar es
> https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
1. [x] Usando OIDC
1. [ ] Usando Vault
1. [ ] Almacenar claves de acceso en `secrets`
> No se recomienda usar claves de acceso de larga duración en caso de filtraciones de seguridad o ataques como [inyección de scripts](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections)
1. [ ] Almacenar claves de acceso en `variables`
> No se deben almacenar valores sensibles en `variables`
### Tu repositorio público de código abierto contiene un workflow con un activador de evento `pull_request`. ¿Cómo puedes requerir aprobaciones para la ejecución de workflows activados desde forks de tu repositorio?
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#about-workflow-runs-from-public-forks
1. [x] Configurar aprobaciones obligatorias para ejecuciones de forks en el repositorio
1. [ ] Configurar reglas de protección de despliegue para el repositorio
> Las reglas de protección de despliegue se usan para proteger entornos
1. [ ] Configurar reglas de protección de ramas para el repositorio
1. [ ] El workflow no se activará para forks si se usa el evento `pull_request`. Si deseas hacerlo, deberías usar el activador de evento `fork_pull_request` con el indicador `require-approval`.
### ¿Cuál de las siguientes variables de entorno predeterminadas contiene el nombre de la persona o aplicación que inició la ejecución del workflow?
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
1. [ ] `GITHUB_USER`
1. [ ] `GITHUB_REPOSITORY`
1. [ ] `GITHUB_WORKFLOW`
1. [x] `GITHUB_ACTOR`
### ¿Cuáles de las siguientes son variables de entorno predeterminadas en GitHub Actions? (Selecciona tres.)
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
- [x] `GITHUB_REPOSITORY`
- [x] `GITHUB_WORKFLOW`
- [x] `GITHUB_ACTOR`
- [ ] `GITHUB_USER`
- [ ] `GITHUB_ORGANIZATION`
- [ ] `GITHUB_TOKEN`
### Tu organización define un secreto `SomeSecret`, sin embargo, cuando haces referencia a ese secreto en un workflow usando `${{ secrets.SomeSecret }}` proporciona un valor diferente al esperado. ¿Cuál podría ser la razón de esto?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
1. [x] El secreto `SomeSecret` también está declarado en el ámbito del repository
1. [ ] El secreto `SomeSecret` también está declarado en el ámbito del enterprise
> Si un secreto con el mismo nombre existe en múltiples niveles, el secreto en el nivel más bajo tiene prioridad.
1. [ ] La expresión `${{ secrets.SomeSecret }}` solo se usa para secretos con ámbito de repository
1. [ ] Necesitas usar la GitHub API para acceder a secretos con ámbito de organization
### ¿Cuál es una forma correcta de imprimir un mensaje de depuración?
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-setting-a-debug-message
1. [x] `echo "::debug::Watch out here!"`
1. [ ] `echo ":debug:Watch out here!"`
1. [ ] `echo "::debug::message=Watch out here!"`
1. [ ] `echo "Watch out here!" >> $GITHUB_DEBUG`
### ¿Cómo pueden las organizaciones que utilizan GitHub Enterprise Server habilitar la sincronización automática de las GitHub Actions de terceros alojadas en GitHub.com con su instancia de GitHub Enterprise Server?
> https://docs.github.com/en/[email protected]/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect
1. [x] Utilizando GitHub Connect
1. [ ] GitHub Enterprise Server tiene acceso a todas las GitHub.com Actions por defecto
> GitHub Actions en GitHub Enterprise Server está diseñado para funcionar en entornos sin acceso completo a internet. Por defecto, los workflows no pueden usar acciones de GitHub.com ni del GitHub Marketplace.
1. [ ] Utilizando la herramienta actions-sync
> https://docs.github.com/en/[email protected]/admin/github-actions/managing-access-to-actions-from-githubcom/manually-syncing-actions-from-githubcom#about-the-actions-sync-tool
1. [ ] GitHub Enterprise Server no puede utilizar GitHub.com Actions debido a su naturaleza on-premise y la falta de acceso a internet
### ¿Dónde puedes encontrar los registros de conectividad de red para un GitHub self-hosted-runner?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#checking-self-hosted-runner-network-connectivity
1. [x] En la carpeta `_diag` directamente en la máquina del runner
1. [ ] En GitHub.com en la página específica de ese Runner
1. [ ] En los registros de ejecución de un trabajo que se ejecutó en ese Runner
1. [ ] En los registros de ejecución de un trabajo que se ejecutó en ese Runner con el registro de depuración habilitado
### ¿Cómo puedes validar que tu self-hosted-runner de GitHub puede acceder a todos los servicios requeridos de GitHub?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#checking-self-hosted-runner-network-connectivity
1. [x] Usando un script proporcionado por GitHub en la máquina del runner
1. [ ] Intentando acceder a la máquina del runner por `ssh` para validar la conectividad de red
1. [ ] Usando el workflow predefinido de GitHub Actions `network-connectivity.yml`
1. [ ] GitHub validará automáticamente la conectividad de red cuando la aplicación del runner sea instalada en la máquina del runner
### ¿Cuál es la forma correcta de activar un job solo si la variable de configuración `MY_VAR` tiene el valor de `MY_VALUE`?
> https://docs.github.com/en/actions/learn-github-actions/contexts#example-usage-of-the-vars-context
1. [x] Creando la siguiente condición a nivel del job
```yaml
my-job:
if: ${{ vars.MY_VAR == 'MY_VALUE' }}
```
1. [ ] Creando la siguiente condición a nivel del job
```yaml
my-job:
if: ${{ vars.MY_VAR }} == 'MY_VALUE'
```
> Esto siempre se evaluará como True
1. [ ] No es posible porque las variables de configuración no pueden usarse en condiciones `if`
> Eso es cierto para `secrets`, pero no para las variables de configuración
1. [ ] No es posible porque las variables de configuración no pueden usarse en condiciones `if` a nivel de job
> Eso es cierto para `secrets`, pero no para las variables de configuración
### Para ejecutar un `step` solo si el secreto `MY_SECRET` ha sido configurado, puedes:
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-secrets
1. [x] Configurar el secreto `MY_SECRET` como una variable de entorno a nivel de job, y luego referenciar esa variable de entorno para ejecutar condicionalmente ese step.
```yaml
my-job:
runs-on: ubuntu-latest
env:
my_secret: ${{ secrets.MY_SECRET }}
steps:
- if: ${{ env.my_secret != '' }}
```
1. [ ] Creando la siguiente condición a nivel de job:
```yaml
my-job:
runs-on: ubuntu-latest
if: ${{ secrets.MY_SECRET == '' }}
```
> los secretos no se pueden referenciar directamente en condiciones if:
1. [ ] Creando la siguiente condición a nivel de step:
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET == '' }}
```
> los secretos no se pueden referenciar directamente en condiciones if:
1. [ ] Creando la siguiente condición a nivel de step:
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET }}
```
> los secretos no se pueden referenciar directamente en condiciones if:
### ¿Cómo puedes usar la API de GitHub para descargar los registros de ejecución de un workflow?
> https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#download-workflow-run-logs
1. [x] `GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `POST /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `HEAD /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `PUT /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
### ¿Cómo puedes usar la API de GitHub para crear o actualizar un secret del repository?
> https://docs.github.com/en/rest/actions/secrets?create-or-update-a-repository-secret=&apiVersion=2022-11-28#create-or-update-a-repository-secret
1. [x] `PUT /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `POST /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `HEAD /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `GET /repos/{owner}/{repo}/actions/secrets/{secret_name}`
### ¿Cómo puedes sobrescribir un GitHub Secret `API_KEY` a nivel de organización con un valor diferente al trabajar dentro de un repositorio? (Selecciona dos.)
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
- [x] Creando un secreto de repositorio con el mismo nombre `API_KEY`
- [x] Creando un secreto de entorno con el mismo nombre `API_KEY`
- [ ] Creando un secreto de empresa con el mismo nombre `API_KEY`
- [ ] Creando un secreto de empresa con el nombre `OVERRIDE_API_KEY`
- [ ] Creando un secreto de repositorio con el nombre `OVERRIDE_API_KEY`
- [ ] Creando un secreto de entorno con el nombre `OVERRIDE_API_KEY`
- [ ] Creando un secreto de repositorio con el nombre `REPOSITORY_API_KEY`
- [ ] Creando un secreto de entorno con el nombre `ENVIRONMENT_API_KEY`
### ¿Qué componentes se pueden reutilizar dentro de una GitHub Organization? (Selecciona cuatro.)
- [x] Secrets
- [x] Variables de configuración
- [x] Self Hosted Runners
- [x] Plantillas de Workflow
- [ ] Artifacts
> Los artifacts se utilizan para preservar datos después de que un job ha finalizado y/o compartir esos datos con otro job dentro del mismo workflow.
- [ ] Cache
> La cache puede reutilizarse entre workflows dentro de un mismo repository.
- [ ] Environment Variables
> Las variables de entorno pueden asignarse a un step, un job o un workflow. No pueden compartirse entre workflows/repositories ni organizations.
### ¿Cuántos trabajos se ejecutarán en el siguiente workflow?
```yaml
jobs:
matrix-job:
runs-on: ubuntu-latest
strategy:
matrix:
pet: [cat, dog]
color: [pink, brown]
include:
- color: white
pet: dog
steps:
- run: echo "Hello ${{ matrix.color }} ${{ matrix.pet }}"
```
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x] 5
1. [ ] 4
1. [ ] 6
1. [ ] 7
### ¿Cuál de las siguientes variables de entorno predeterminadas contiene el nombre completo (por ejemplo, `octocat/hello-world`) del repository donde se está ejecutando el workflow?
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
1. [x] `GITHUB_REPOSITORY`
1. [ ] `GITHUB_REPOSITORY_ID`
1. [ ] `GITHUB_REPOSITORY_OWNER`
1. [ ] `GITHUB_REPOSITORY_OWNER_ID`
### En un flujo de trabajo que tiene múltiples jobs, todos ejecutándose en runners alojados por GitHub, ¿es cierto que todos los jobs están garantizados para ejecutarse en la misma máquina del runner?
> https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job#choosing-github-hosted-runners
1. [x] No
1. [ ] Sí
> Cada job se ejecuta en una instancia nueva de una imagen del runner especificada por runs-on
### ¿Cuál es la cantidad máxima de workflows reutilizables que se pueden llamar desde un solo archivo de workflow?
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
1. [x] 20
1. [ ] 5
1. [ ] 1
1. [ ] 10
### ¿Qué es un runner auto-alojado?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
1. [x] Un runner auto-alojado es un sistema que despliegas y gestionas para ejecutar trabajos de GitHub Actions en GitHub.com
1. [ ] Un runner auto-alojado es un sistema para cargar código en un servidor privado
1. [ ] Un runner auto-alojado es un sistema para poder crear cargas de trabajo automáticamente
1. [ ] Un runner auto-alojado es un sistema para gestionar pull requests de los usuarios de la organización
### ¿Cuál de las siguientes afirmaciones es correcta acerca de GitHub Workflows y Actions?
> https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
1. [ ] Cada acción se compone de uno o más workflows, los cuales están compuestos por uno o más jobs, y cada job se compone de uno o más pasos.
1. [ ] Cada workflow se compone de una o más acciones, las cuales están compuestas por uno o más jobs, y cada job se compone de uno o más pasos.
1. [x] Cada workflow se compone de uno o más jobs, los cuales están compuestos por uno o más pasos, y cada paso es una acción o un script.
1. [ ] Cada acción se compone de uno o más jobs, los cuales están compuestos por uno o más pasos, y cada paso es un workflow.
### ¿En qué commit y rama se ejecutan los workflows programados en GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] Los workflows programados se ejecutan en el commit específico de la rama modificada más recientemente.
> incorrecto, tanto el commit específico como la rama modificada más recientemente
1. [ ] Los workflows programados se ejecutan en el commit específico de la rama principal.
> incorrecto, tanto el commit específico como la rama principal
1. [x] Los workflows programados se ejecutan en el último commit de la rama predeterminada del repository.
1. [ ] Los workflows programados se ejecutan en el último commit de la rama principal.
> el último commit es correcto, pero la rama principal no lo es
### ¿Cuál es la sintaxis correcta para configurar el directorio para todos los comandos `run` en un workflow?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory
1. [x] configurar `working-directory` bajo `defaults.run`
```yaml
defaults:
run:
shell: bash
working-directory: ./scripts
```
1. [ ] configurar `directory` bajo `defaults.run`
```yaml
defaults:
run:
shell: bash
directory: ./scripts
```
1. [ ] configurar `working-directory` bajo `job`
```yaml
defaults:
run:
shell: bash
job:
working-directory: ./scripts
```
1. [ ] configurar `directory` bajo `job`
```yaml
defaults:
run:
shell: bash
job:
directory: ./scripts
```
### ¿Cómo puedes reutilizar un flujo de trabajo definido en múltiples repositorios? (Elige dos.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [ ] Copiando el archivo del flujo de trabajo en cada repositorio
- [x] Usando plantillas de flujo de trabajo
- [ ] Creando una acción reutilizable
- [x] Definiendo el flujo de trabajo en un repositorio central
### ¿Cómo puedes asegurarte de que un job se ejecute solo en una rama específica?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#using-filters
1. [x] Usando el filtro branches
1. [ ] Usando el filtro runs-on
1. [ ] Usando el filtro jobs
1. [ ] Usando la palabra clave branch
### ¿Qué hace la palabra clave `needs` en un workflow de GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] Especifica las dependencias de un job
1. [ ] Define variables de entorno
1. [ ] Configura el entorno
1. [ ] Desencadena un job basado en un evento
### ¿Qué palabra clave te permite definir variables de entorno en un flujo de trabajo de GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenv
1. [x] env
1. [ ] vars
1. [ ] secrets
1. [ ] config
### ¿Cuál es el propósito de la palabra clave `with` en un flujo de trabajo de GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith
1. [ ] Definir variables de entorno
1. [x] Especificar parámetros de entrada para una acción
1. [ ] Configurar dependencias
1. [ ] Activar otro flujo de trabajo
### ¿Cuál de las siguientes sintaxis de GitHub Actions se utiliza para ejecutar múltiples comandos en un solo paso?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#example-of-a-multiline-string
1. [ ] Usar && para encadenar comandos
1. [ ] Definir comandos en un array
1. [x] Usar una cadena multilínea con |
1. [ ] Separar comandos con un punto y coma ;
### ¿Cómo puedes almacenar en caché las dependencias para acelerar la ejecución del flujo de trabajo?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows#about-caching-workflow-dependencies
1. [ ] Usando la palabra clave cache
1. [x] Usando la acción actions/cache
1. [ ] Al almacenarlas en el repositorio
1. [ ] Usando la palabra clave store
### ¿Qué hace la palabra clave `matrix` en un flujo de trabajo de GitHub Actions?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-a-matrix-for-your-jobs
1. [x] Permite definir múltiples configuraciones de trabajo para ejecutarse en paralelo
1. [ ] Establece variables de entorno para el trabajo
1. [ ] Activa flujos de trabajo basados en un horario
1. [ ] Define secretos para el flujo de trabajo
### ¿Cuál de los siguientes puede utilizarse para limitar el número de trabajos concurrentes que se ejecutan en un flujo de trabajo de GitHub Actions?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-concurrency
1. [x] concurrency
1. [ ] limit
1. [ ] max-jobs
1. [ ] parallelism
### ¿Cuál es el tiempo de espera predeterminado para un trabajo de GitHub Actions?
> https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
1. [ ] 30 minutos
1. [ ] 60 minutos
1. [ ] 120 minutos
1. [x] 360 minutos
### ¿Cómo puedes especificar el sistema operativo para un trabajo en GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on
1. [ ] Usando la palabra clave os
1. [x] Usando la palabra clave runs-on
1. [ ] Usando la palabra clave platform
1. [ ] Usando la palabra clave env
### En un workflow de GitHub Actions, ¿cómo especificas una versión específica de Node.js para usar en un job?
> https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs#specifying-the-nodejs-version
1. [x]
```yaml
uses: actions/setup-node@v4
with:
node-version: 20
```
1. [ ]
```yaml
uses: actions/node-setup@v4
with:
node-version: 20
```
1. [ ]
```yaml
uses: setup-node@v4
with:
version: 20
```
1. [ ]
```yaml
uses: setup-node@v4
with:
node: 20
```
### ¿Cómo referencias un secreto almacenado en GitHub Secrets en un workflow?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow
1. [x] ${{ secrets.SECRET_NAME }}
1. [ ] ${{ secret.SECRET_NAME }}
1. [ ] ${{ env.SECRET_NAME }}
1. [ ] ${{ config.SECRET_NAME }}
### ¿Cuál es el shell predeterminado utilizado por GitHub Actions en los runners de Windows?
> https://github.blog/changelog/2019-10-17-github-actions-default-shell-on-windows-runners-is-changing-to-powershell/
1. [ ] bash
1. [ ] sh
1. [x] powershell
1. [ ] cmd
### ¿Cuáles de las siguientes afirmaciones son verdaderas sobre agregar un self-hosted runner en GitHub Actions? (Elige tres).
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-a-repository
- [x] Puedes agregar un self-hosted runner a un repository
- [x] Puedes agregar un self-hosted runner a una organization
- [x] Puedes agregar un self-hosted runner a un enterprise
- [ ] No puedes agregar un self-hosted runner a un workflow
> No puedes agregar al nivel de workflow
- [ ] No puedes agregar un self-hosted runner a un step
> No puedes agregar al nivel de step
### Seleccione la variable de entorno predeterminada que contiene el sistema operativo del runner que ejecuta el trabajo
> https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables
1. [x] `RUNNER_OS`
1. [ ] `GITHUB_RUNNER_OS`
1. [ ] `RUNNER_ARCH`
1. [ ] `RUNNER_NAME`
### ¿Cómo maneja una pérdida de caché la acción `actions/cache` en GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [ ] requiriendo intervención manual para crear una nueva caché
1. [ ] buscando una caché en otros repositorios
1. [x] creando automáticamente una nueva caché si el trabajo se completa con éxito
1. [ ] terminando el flujo de trabajo si ocurre una pérdida de caché
### ¿Cómo puedes especificar el horario de un flujo de trabajo de GitHub Actions para que se ejecute solo en días laborables?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] agregar una condición en el archivo YAML del flujo de trabajo para los días laborables
1. [ ] no es posible en GitHub Actions
1. [ ] usar el disparador de evento on: schedule: weekdays
1. [x] usar el disparador de evento on: schedule: cron
### ¿Cuál es el enfoque recomendado para almacenar secretos de más de 48 KB?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#limits-for-secrets
1. [ ] evitar almacenar secretos grandes por completo para garantizar la seguridad
1. [ ] los secretos de más de 48 KB no se pueden almacenar
1. [x] cifrar y almacenar los secretos en el repository pero mantener la frase de descifrado como un secreto
1. [ ] almacenar secretos grandes directamente como secretos del repository para evitar limitaciones
### Selecciona funciones de verificación de estado en GitHub Actions
> https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
1. [x] `success()`, `always()`, `cancelled()` y `failure()`
1. [ ] `completed()`, `always()`, `cancelled()` y `failure()`
1. [ ] `status()`, `always()`, `cancelled()` y `failure()`
1. [ ] `state()`, `always()`, `cancelled()` y `failure()`
### ¿Cómo aseguras que el paso `Upload Failure test report` se ejecute solo si el paso `Run Tests` falla?
> https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
1. [x]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: failure() && steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: always() && steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
### ¿Qué contexto contiene información sobre el evento que desencadenó la ejecución de un workflow?
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-event-information
1. [x] `github.event`
1. [ ] `github.repository`
1. [ ] `github.job`
1. [ ] `jobs.<job_id>.result`
### En GitHub Actions, si defines tanto los filtros de ramas como de rutas, ¿cuál es el efecto en la ejecución del flujo de trabajo?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore
1. [x] el flujo de trabajo solo se ejecutará cuando se cumplan tanto `branches` como `paths`
1. [ ] el flujo de trabajo se ejecutará cuando se cumpla cualquiera de `branches` o `paths`, pero solo aplicará el filtro correspondiente
1. [ ] el flujo de trabajo se ejecutará cuando se cumpla cualquiera de `branches` o `paths`
1. [ ] el flujo de trabajo no se ejecutará cuando se cumplan tanto `branches` como `paths`
### ¿Cuál es la práctica recomendada para tratar las variables de entorno en GitHub Actions, independientemente del sistema operativo y la shell utilizada?
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-environment-variable
1. [x] tratar las variables de entorno como sensibles a mayúsculas y minúsculas
1. [ ] usar solo letras mayúsculas para los nombres de las variables de entorno
1. [ ] ignorar la sensibilidad a mayúsculas y minúsculas, ya que GitHub Actions lo maneja automáticamente
1. [ ] depender del comportamiento del sistema operativo en uso
### ¿Cuál de las siguientes afirmaciones describe con precisión el comportamiento de los trabajos de workflow al referenciar las reglas de protección de un entorno?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] los trabajos del workflow no comenzarán hasta que se cumplan todas las reglas de protección del entorno
1. [ ] los trabajos del workflow nunca comenzarán si el entorno tiene reglas de protección
1. [ ] los trabajos del workflow comenzarán de inmediato, independientemente de las reglas de protección del entorno
1. [ ] los trabajos del workflow solo comenzarán si se cumplen algunas de las reglas de protección del entorno
### ¿Cuál es el propósito del parámetro `restore-keys` en `actions/cache` en GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [x] proporcionar claves alternativas para usar en caso de que no se encuentre una coincidencia en la caché
1. [ ] indicar si ocurrió una coincidencia en la caché
1. [ ] especificar la ubicación de los archivos en caché
1. [ ] habilitar la funcionalidad de caché entre sistemas operativos
### ¿Qué variable deberías configurar como `true` para habilitar el registro de depuración de pasos?
> https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging
1. [x] `ACTIONS_STEP_DEBUG`
1. [ ] `ACTIONS_JOB_DEBUG`
1. [ ] `ACTIONS_RUNNER_DEBUG`
1. [ ] `ACTIONS_WORKFLOW_DEBUG`
### ¿Qué configuración es adecuada para desencadenar un workflow que se ejecute en eventos de webhook relacionados con acciones de check_run?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#check_run
1. [x]
```yaml
on:
check_run:
types: [rerequested, completed]
```
1. [ ]
```yaml
on:
check_run:
types: [started]
```
1. [ ]
```yaml
on:
check_run:
type: [closed]
```
1. [ ]
```yaml
on:
check_run:
filter: [requested]
```
### ¿Cuál es el propósito de la palabra clave `timeout-minutes` en un paso?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes
1. [x] limita el tiempo de ejecución de un paso individual
1. [ ] define el intervalo de tiempo para comandos individuales dentro de un paso
1. [ ] establece el tiempo de espera para eventos externos antes de proceder al siguiente paso
1. [ ] especifica la duración máxima que se permite ejecutar un job
### Dave está creando un flujo de trabajo con plantillas para su organización. ¿Dónde debe almacenar Dave los archivos del flujo de trabajo y los archivos de metadatos asociados para el flujo de trabajo con plantillas?
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
1. [x] dentro de un directorio llamado `workflow-templates` dentro de un repositorio llamado `.github`
1. [ ] dentro de un directorio llamado `workflow-templates` dentro del repositorio actual
1. [ ] dentro de un directorio llamado `.github/org-templates`
1. [ ] dentro de un directorio llamado `.github/workflow-templates`
### Dave quiere ser notificado cuando se cree un comentario en un issue dentro de un repositorio de GitHub. ¿Qué disparador de evento debería usarse en la configuración del workflow?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment
1. [x] `issue_comment`
1. [ ] `issues.comment`
1. [ ] `issues`
1. [ ] `comment`
### ¿Qué nivel de acceso se requiere en un repositorio de GitHub para eliminar archivos de registro de ejecuciones de flujo de trabajo?
> https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### ¿Qué es verdadero acerca de la siguiente configuración del workflow si se activa en el repositorio `octo/my-dev-repo`?
```yaml
name: deploy-workflow
on: [push]
jobs:
production-deploy:
if: github.repository == 'octo/my-prod-repo'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
```
> https://docs.github.com/en/actions/using-jobs/using-conditions-to-control-job-execution
1. [x] el trabajo `production-deploy` será marcado como omitido
1. [ ] el trabajo `production-deploy` generará un error
1. [ ] el trabajo `production-deploy` ejecutará tres pasos
1. [ ] el trabajo `production-deploy` se ejecutará si la `node-version` es `14`
### ¿Cómo puedes acceder a los valores actuales de las variables en una matriz dentro de un trabajo en el ejemplo a continuación:
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x] referencia variables a través del contexto `matrix` con una sintaxis como `matrix.version` y `matrix.os`
1. [ ] usando la sintaxis `matrix.property`
1. [ ] usando la palabra clave `context` dentro de la configuración del trabajo
1. [ ] accediendo a las variables directamente con la sintaxis `version` y `os`
### ¿Qué nivel de permiso se requiere para volver a ejecutar los workflows?
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### ¿Cuándo puedes eliminar ejecuciones de workflows? (selecciona dos)
> https://docs.github.com/en/actions/managing-workflow-runs/deleting-a-workflow-run
- [x] Cuando la ejecución del workflow se ha completado
- [x] Cuando la ejecución del workflow tiene dos semanas
- [ ] Cuando la ejecución del workflow tiene 10 días
- [ ] Cuando la ejecución del workflow está en curso
### ¿Quién puede eludir las reglas de protección de implementación configuradas para forzar la implementación (por defecto)?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#allow-administrators-to-bypass-configured-protection-rules
1. [x] Administradores del repository
1. [ ] Cualquiera con permiso de escritura en el repository
1. [ ] Cualquiera con permiso de lectura en el repository
### ¿Cómo puedes omitir la siguiente ejecución del workflow cuando haces un commit o creas un PR?
```yaml
name: Build
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
name: Extract artifact version
...
```
>https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs
1. [x] Incluyendo cualquiera de las siguientes palabras clave en el mensaje del commit o en el título del pull-request:
```yaml
[skip ci]
[ci skip]
[no ci]
[skip actions]
[actions skip]
```
1. [ ] Proporcionar `SKIP_WORKFLOW` en el mensaje del commit
1. [ ] El workflow anterior se ejecutará en cada evento de push o pull request en todos los casos
### ¿Cómo puedes determinar si una acción es una acción de contenedor observando su archivo action.yml?
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-docker-container-actions
1. [x] `runs.using` tiene `docker` como valor
1. [ ] `runs.using` tiene `container` como valor
1. [ ] `runs.using` tiene `Dockerfile` como valor
1. [ ] `runs.main` tiene `container` como valor
### ¿Cuál es la sintaxis correcta para especificar un script de limpieza en una acción de contenedor?
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspost-entrypoint
1. [x]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
post-entrypoint: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
post: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
after: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
after-entrypoint: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
cleanup: 'cleanup.sh'
```
### ¿Qué es verdadero sobre las variables predeterminadas? (elige tres)
> https://docs.github.com/en/actions/reference/workflows-and-actions/variables
- [x] Las variables de entorno predeterminadas son configuradas por GitHub y no definidas en un workflow
- [x] La mayoría de las variables de entorno predeterminadas tienen una propiedad de contexto correspondiente
- [x] Actualmente, el valor de la variable de entorno predeterminada CI puede ser sobrescrito, pero no se garantiza que esto siempre sea posible
- [ ] Puedes agregar una nueva variable de entorno predeterminada añadiendo el prefijo “GITHUB_” a ella
- [ ] Las variables de entorno predeterminadas siempre tienen el prefijo “GITHUB_”
- [ ] Las variables de entorno predeterminadas pueden ser accedidas utilizando el contexto env
### ¿Cuáles son los alcances definidos para las variables personalizadas en un workflow? (elige tres)
> https://docs.github.com/en/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow
- [x] Todo el workflow, utilizando `env` en el nivel superior del archivo del workflow
- [x] Los contenidos de un job dentro de un workflow, utilizando `jobs.<job_id>.env`
- [x] Un paso específico dentro de un job, utilizando `jobs.<job_id>.steps[*].env`
- [ ] Todos los jobs dentro de un workflow, utilizando `jobs.env`
- [ ] Todo el workflow, utilizando `custom.env` en el nivel superior del archivo del workflow
- [ ] Un entorno específico en el repository, utilizando `environment.<environment_id>.env` en el nivel superior del archivo del workflow
### ¿Qué se debe agregar a `actions/checkout` si `my-org/my-private-repo` es un repositorio privado diferente al que contiene el flujo de trabajo actual?
```yaml
name: deploy-workflow
on: [push]
jobs:
my-job:
runs-on: ubuntu-latest
steps:
- name: "Checkout GitHub Action"
uses: actions/checkout@v4
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
> https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#example-using-an-action-inside-a-different-private-repository-than-the-workflow
1. [x] Crear un secreto de GitHub `MY_ACCESS_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ secrets.MY_ACCESS_TOKEN }}
```
1. [ ] Crear un input `MY_ACCESS_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ MY_ACCESS_TOKEN }}
```
1. [ ] La variable de entorno `GITHUB_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: $GITHUB_TOKEN
```
1. [ ] Dejarlo tal como está, ya que los tokens de acceso se pasarán automáticamente
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
### Dada la siguiente configuración, ¿cuántos trabajos ejecutará GitHub Actions cuando se evalúe esta matriz?
```yaml
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node: [14, 16]
include:
- os: macos-latest
node: 18
- os: ubuntu-latest
node: 14
```
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow#expanding-or-adding-matrix-configurations
1. [ ] 4 trabajos
1. [x] 5 trabajos
1. [ ] 6 trabajos
1. [ ] 7 trabajos
1. [ ] No se ejecutará ningún trabajo porque la sintaxis es inválida.
### ¿A qué niveles se pueden definir las variables de entorno? (Elija tres)
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables
- [x] Nivel de Workflow
- [x] Nivel de Job
- [x] Nivel de Step
- [ ] Nivel de Action
### ¿Cómo debe un trabajo dependiente hacer referencia al valor `output1` producido por un trabajo llamado `job1` anteriormente en el mismo workflow?
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs
1. [x] `${{needs.job1.outputs.output1}}`
1. [ ] `${{job1.outputs.output1}}`
1. [ ] `${{needs.job1.output1}}`
1. [ ] `${{depends.job1.output1}}`
### ¿Qué sintaxis de comando de flujo de trabajo establece correctamente una variable de entorno llamada 'API_VERSION' con el valor '2.1' para los pasos posteriores en un trabajo de GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable
1. [x] `echo "API_VERSION=2.1" >> "$GITHUB_ENV"`
1. [ ] `echo "API_VERSION=2.1" >> "$GITHUB_OUTPUT"`
1. [ ] `export API_VERSION=2.1 >> "$GITHUB_ENV"`
1. [ ] `set-env name=API_VERSION value=2.1`
Detalles
¿Te resultó útil esta prueba práctica?
Deja una ⭐ en el repository y considera retribuir a la comunidad:
- contribuyendo con una o más preguntas de examen simuladas (toma minutos)