Skip to main content

Publicar e instalar un paquete con GitHub Actions

Puedes configurar un flujo de trabajo en GitHub Actions para publicar o instalar automáticamente un paquete desde GitHub Packages.

GitHub Packages está disponible con GitHub Free, GitHub Pro, GitHub Free para organizaciones, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server 3.0 o superior y GitHub AE.
GitHub Packages no está disponible para repositorios privados que pertenezcan a cuentas que utilicen planes tradicionales por repositorio. Las cuentas que utilicen los planes tradicionales por repositorio tampoco podrán acceder al Container registry ya que estas cuentas se facturan por repositorio. Para más información, vea "Productos de GitHub".

Acerca de GitHub Packages con GitHub Actions

GitHub Actions te ayuda a automatizar tus flujos de trabajo de desarrollo de software en el mismo lugar en el que almacenas código y colaboras con informes de problemas y solicitudes de extracción. Puedes escribir tareas individuales, llamadas acciones, y combinarlas para crear un flujo de trabajo personalizado. Con GitHub Actions puedes crear capacidades de integración continua (CI, por sus siglas en inglés) de extremo a extremo y de funcionamiento continuo (CD, por sus siglas en inglés) directamente en tu repositorio. Para más información, vea "Acerca de GitHub Actions".

Puedes ampliar las capacidades de CI y CD de tu repositorio publicando o instalando paquetes como parte de tu flujo de trabajo.

Autenticación en registros de paquetes con permisos detallados

Algunos registros de GitHub Packages admiten permisos detallados. Esto significa que puedes elegir permitir que los paquetes sean propiedad de un usuario o de una organización, o bien que estén vinculados a un repositorio. Para obtener una lista de los registros que admiten permisos detallados, consulta "Acerca de los permisos de GitHub Packages".

Para los registros que admiten permisos detallados, si en el flujo de trabajo se usa un personal access token para autenticarse en un registro, se recomienda encarecidamente actualizar el flujo de trabajo para usar el GITHUB_TOKEN. Para obtener instrucciones sobre cómo actualizar los flujos de trabajo que se autentican en un registro con un personal access token, consulta "Actualización de un flujo de trabajo que accede a un registro mediante un personal access token".

Para más información sobre GITHUB_TOKEN, vea "Autenticación en un flujo de trabajo". Para obtener más información sobre los procedimientos recomendados al usar un registro en acciones, consulta "Fortalecimiento de seguridad para Acciones de GitHub".

Autenticación en registros de paquetes con permisos del ámbito del repositorio

Algunos registros de GitHub Packages solo admiten permisos del ámbito del repositorio y no admiten permisos detallados. Para obtener una lista de estos registros, consulta "Acerca de los permisos de GitHub Packages".

Si quieres que el flujo de trabajo tenga acceso a un registro de GitHub Packages que no admita permisos detallados, recomendamos el uso del GITHUB_TOKEN que GitHub Enterprise Cloud crea automáticamente para el repositorio al habilitar GitHub Actions. Debes establecer los permisos para este token de acceso en el archivo del flujo de trabajo a fin de conceder acceso de lectura al ámbito contents y acceso de escritura al ámbito packages. En el caso de las bifurcaciones, a GITHUB_TOKEN se le concede acceso de lectura para el repositorio primario. Para más información, vea "Autenticación con GITHUB_TOKEN".

Puede hacer referencia al elemento GITHUB_TOKEN en el archivo de flujo de trabajo mediante el contexto {{secrets.GITHUB_TOKEN}}. Para más información, vea "Autenticación con GITHUB_TOKEN".

Acerca de los permisos y el acceso a los paquetes

Paquetes cuyo ámbito son los usuarios o las organizaciones

Los registros que admiten permisos detallados permiten a los usuarios crear y administrar paquetes como recursos independientes en el nivel de la organización. Los paquetes pueden pertenecer a una cuenta organizativa o personal, y puedes personalizar el acceso para cada uno de tus paquetes independientemente de los permisos del repositorio.

Todos los flujos de trabajo que acceden a los registros que admiten permisos detallados deben usar GITHUB_TOKEN en lugar de un personal access token. Para más información sobre los procedimientos recomendados de seguridad, vea "Fortalecimiento de la seguridad para Acciones de GitHub".

Paquetes cuyo ámbito son los repositorios

Cuando habilitas las Acciones de GitHub, GitHub instala una App GitHub en tu repositorio. El secreto GITHUB_TOKEN es un token de acceso de instalación de aplicación de GitHub. Puedes utilizar el token de acceso a la instalación para autenticarte en nombre de la GitHub App instalada en tu repositorio. Los permisos del token están limitados al repositorio que contiene tu flujo de trabajo. Para más información, vea "Permisos para GITHUB_TOKEN".

GitHub Packages permite insertar y extraer paquetes mediante el GITHUB_TOKEN disponible para un flujo de trabajo de GitHub Actions.

Configuración de acceso y permisos predeterminados para los contenedores que se modifican a través de los flujos de trabajo

Cuando creas, instalas, modificas o borras un contenedor a través de un flujo de trabajo, hay algunos permisos y configuraciones de acceso predeterminados que se utilizan para garantizar que los administradores tengan acceso al fluljo de trabajo. También puedes ajustar esta configuración de acceso.

Por ejemplo, de forma predeterminada si un flujo de trabajo crea un contenedor mediante GITHUB_TOKEN, después:

  • El contenedor hereda la visibilidad el modelo de permisos del repositorio en donde se ejecuta el flujo de trabajo.
  • Los administradores de repositorio donde se ejecuta el flujo de trabajo se convierten en los administradores del contenedor una vez que este se cree.

Estos son más ejemplos de cómo funcionan los permisos predeterminados para los flujos de trabajo que administran paquetes.

Tarea de flujo de trabajo de GitHub ActionsPermisos y acceso predeterminado
Descargar un contenedor existente- Si el contenedor es público, cualquier flujo de trabajo que se ejecute en cualquier repositorio puede descargar el contenedor.
- Si el contenedor es interno, todos los flujos de trabajo que se ejecuten en un repositorio que pertenezca a la cuenta de empresa podrán descargarlo. En el caso de las organizaciones propiedad de la empresa, puede leer cualquier repositorio de la empresa.
- Si el contenedor es privado, solo los flujos de trabajo que se ejecutan en repositorios a los que se les concede permiso de lectura en ese contenedor pueden descargar el contenedor.
Carga una versión nueva a un contenedor existente- Si el contenedor es privado, interno, o público, solo los flujos de trabajo que se ejecuten en repositorios que tengan el permiso de escritura en dicho contenedor podrán cargar versiones nuevas de este.
Borrar un contenedor o versiones de un contenedor- Si el contenedor es privado, interno o público, solo los flujos de trabajo que se ejecuten en los repositorios a los que se les otorga permiso de borrado podrán borrar las versiones existentes de este.

También puedes ajustar el acceso a los contenedores de forma más granular o ajustar el comportamiento de algunos de los permisos predeterminados. Para más información, vea "Configuración del control de acceso y la visibilidad de un paquete".

Publicar un paquete mediante una acción

Puedes utilizar GitHub Actions para publicar paquetes automáticamente como parte de tu flujo de integración contínua (IC). Este acercamiento a los despliegues contínuos (DC) te permite automatizar la creación de nuevas versiones de los paquetes si el código cumple con tus estándares de calidad. Por ejemplo, podrías crear un flujo de trabajo que ejecute pruebas de IC cada vez que un desarrollador suba código a alguna rama en particular. Si estas pruyebas pasan, el flujo de trabajo puede publicar una versión nueva del paquete en el GitHub Packages.

Los pasos de configuración varían de acuerdo con el cliente del paquete. Para obtener información general sobre cómo configurar un flujo de trabajo para GitHub Actions, vea "Configuración de un flujo de trabajo".

El siguiente ejemplo ilustra cómo puedes utilizar las GitHub Actions para crear y probar tu app y luego crear una imagen de Docker automáticamente y publicarla en el GitHub Packages.

Cree un archivo de flujo de trabajo en el repositorio (por ejemplo, .github/workflows/deploy-image.yml) y agregue el código YAML siguiente:

YAML
# <a name="this-workflow-uses-actions-that-are-not-certified-by-github"></a>Este flujo de trabajo usa acciones que no GitHub no certifica.
# <a name="they-are-provided-by-a-third-party-and-are-governed-by"></a>Estas las proporcionan entidades terceras y las gobiernan
# <a name="separate-terms-of-service-privacy-policy-and-support"></a>condiciones de servicio, políticas de privacidad y documentación de soporte
# <a name="documentation"></a>en línea.

# <a name="github-recommends-pinning-actions-to-a-commit-sha"></a>GitHub recomienda anclar acciones a un SHA de confirmación.
# <a name="to-get-a-newer-version-you-will-need-to-update-the-sha"></a>Para obtener una versión más reciente, debes actualizar el SHA.
# <a name="you-can-also-reference-a-tag-or-branch-but-the-action-may-change-without-warning"></a>También puedes hacer referencia a una etiqueta o rama, pero la acción puede cambiar sin ninguna advertencia.

name: Create and publish a Docker image

on:
 push:
   branches: ['release']

env:
 REGISTRY: ghcr.io
 IMAGE_NAME: ${{ github.repository }}

jobs:
 build-and-push-image:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     packages: write

   steps:
     - name: Checkout repository
       uses: actions/checkout@v3

     - name: Log in to the Container registry
       uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
       with:
         registry: ${{ env.REGISTRY }}
         username: ${{ github.actor }}
         password: ${{ secrets.GITHUB_TOKEN }}

     - name: Extract metadata (tags, labels) for Docker
       id: meta
       uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
       with:
         images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

     - name: Build and push Docker image
       uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
       with:
         context: .
         push: true
         tags: ${{ steps.meta.outputs.tags }}
         labels: ${{ steps.meta.outputs.labels }}

La configuración relevante se explica en la siguiente tabla. Para obtener detalles completos sobre cada elemento de un flujo de trabajo, vea "Sintaxis de flujo de trabajo para GitHub Actions".

```yaml on: push: branches: ['release'] ``` Configura el flujo de trabajo Create and publish a Docker image para que se ejecute cada vez que se inserta un cambio en la rama denominada release.
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
Define dos variables de ambiente personalizadas para el flujo de trabajo. Estas se utilizan para el dominio del Container registry y para un nombre para la imagen de Docker que compila este flujo de trabajo.
jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
Hay solo un job en este flujo de trabajo. Se configura para ejecutarse en la última versión disponible de Ubuntu.
```yaml permissions: contents: read packages: write ``` Establece los permisos concedidos a GITHUB_TOKEN para las acciones de este trabajo.
```yaml - name: Log in to the Container registry uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} ``` Crea un paso denominado Log in to the Container registry, que inicia sesión en el registro mediante la cuenta y la contraseña que publicarán los paquetes. Una vez que se publica, los paquetes pertenecerán a la cuenta que se define aquí.
```yaml - name: Extract metadata (tags, labels) for Docker id: meta uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} ``` En este paso se usa docker/metadata-action para extraer etiquetas que se aplicarán a la imagen especificada. id "meta" permite hacer referencia a la salida de este paso en un paso posterior. El valor images proporciona el nombre base para las etiquetas.
```yaml - name: Build and push Docker image ``` Crea un paso denominado Build and push Docker image. Este paso se ejecuta como parte del trabajo build-and-push-image.
```yaml uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc ``` Usa la acción build-push-action de Docker para compilar la imagen, en función de la propiedad Dockerfile del repositorio. Si la compilación es exitosa, sube la imagen al GitHub Packages.
```yaml with: ``` Envía los parámetros necesarios a la acción build-push-action. Estas se definen en líneas subsecuentes.
```yaml context: . ``` Define el contexto de la compilación como el conjunto de archivos que se ubican en la ruta específica. Para más información, vea "Uso".
```yaml push: true ``` Sube esta imagen al registro si se compila con éxito.
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
Agrega las etiquetas y marcadores que se exrayeron en el paso "meta".

Este flujo de trabajo nuevo se ejecutará automáticamente cada vez que inserte un cambio en una rama denominada release en el repositorio. Puede ver el progreso en la pestaña Acciones.

Unos minutos después de que se complete el flujo de trabajo, el paquete nuevo podrá visualizarse en tu repositorio. Para buscar los paquetes disponibles, vea "Visualización de los paquetes de un repositorio".

Instalar un paquete mediante una acción

Puedes instalar paquetes como parte de tu flujo de CI mediante GitHub Actions. Por ejemplo, podrías configurar un flujo de trabajo para que cada vez que un programador suba código a una solicitud de extracción, el flujo de trabajo resuelva las dependencias al descargar e instalar paquetes alojados por el GitHub Packages. Luego, el flujo de trabajo puede ejecutar pruebas de CI que requieran las dependencias.

Para instalar paquetes hospedados por GitHub Packages mediante GitHub Actions se necesita una configuración mínima o autenticación adicional cuando se usa un GITHUB_TOKEN. La transferencia de datos también es gratuita cuando una acción instala un paquete. Para más información, vea "Acerca de la facturación de GitHub Packages".

Los pasos de configuración varían de acuerdo con el cliente del paquete. Para obtener información general sobre cómo configurar un flujo de trabajo para GitHub Actions, vea "Configuración de un flujo de trabajo".

Actualización de un flujo de trabajo que accede a un registro mediante un personal access token

GitHub Packages admite el GITHUB_TOKEN para una autenticación más fácil y segura en los flujos de trabajo. Si usas un registro que admite permisos detallados y en el flujo de trabajo se usa un personal access token para autenticarse en el registro, se recomienda encarecidamente actualizar el flujo de trabajo para usar el GITHUB_TOKEN.

Para más información sobre GITHUB_TOKEN, vea "Autenticación en un flujo de trabajo".

Al usar GITHUB_TOKEN en lugar de un personal access token (classic) con el ámbito repo, aumenta la seguridad del repositorio, ya que no es necesario usar un personal access token de larga duración que ofrezca acceso innecesario al repositorio donde se ejecuta el flujo de trabajo. Para más información sobre los procedimientos recomendados de seguridad, vea "Fortalecimiento de la seguridad para Acciones de GitHub".

  1. Navega a la página de llegada de tu paquete.

  2. En la barra lateral de la izquierda, haga clic en Acceso a acciones. Opción "Acceso a acciones" en el menú de la izquierda

  3. Para asegurarte de que tu paquete de contenedor tenga acceso a tu flujo de trabajo, debes agregar el repositorio en donde se almacena el flujo de trabajo a tu contenedor. Haga clic en Agregar repositorio y busque el repositorio que quiera agregar. Botón "Agregar repositorio"

    Nota: Agregar un repositorio al contenedor mediante la opción de menú Acceso a acciones es diferente de conectar el contenedor a un repositorio. Para más información, vea "Garantía del acceso de flujo de trabajo al paquete" y "Conexión de un repositorio a un paquete".

  4. Opcionalmente, utiliza el menú desplegable de "rol", selecciona el nivel de acceso predeterminado que te gustaría que tuviera el repositorio en tu imagen de contenedor. Niveles de acceso de permisos para otorgar a los repositorios

  5. Abre tu archivo de flujo de trabajo. En la línea en la que inicias sesión para el registro, sustituye tu personal access token por ${{ secrets.GITHUB_TOKEN }}.

Por ejemplo, este flujo de trabajo publica una imagen de Docker en el Container registry y usa ${{ secrets.GITHUB_TOKEN }} para autenticarse.

YAML
name: Demo Push

on:   
  push:
    # Publish `master` as Docker `latest` image.
    branches:
      - master
      - seed

    # Publish `v1.2.3` tags as releases.
    tags:
      - v*

  # Run tests for any PRs.
  pull_request:

env:
  IMAGE_NAME: ghtoken_product_demo

jobs:
  # Push image to GitHub Packages.
  # See also https://docs.docker.com/docker-hub/builds/
  push:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

    steps:
      - uses: actions/checkout@v3

      - name: Build image
        run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"

      - name: Log in to registry
        # This is where you will update the personal access token to GITHUB_TOKEN
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u $ --password-stdin

      - name: Push image
        run: |
          IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME

          # Change all uppercase to lowercase
          IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
          # Strip git ref prefix from version
          VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
          # Strip "v" prefix from tag name
          [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
          # Use Docker `latest` tag convention
          [ "$VERSION" == "master" ] && VERSION=latest
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=$VERSION
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION