Compartir comentarios
Las respuestas se generan en base a la documentación.

Opciones avanzadas para autobuild y autotest

Tabla de contenidos
Warning

Las compilaciones automatizadas (Automated Builds) de Docker Hub son una función obsoleta. Se retirará por completo el 1 de abril de 2027.

Note

Las compilaciones automatizadas requieren una suscripción a Docker Pro, Team o Business.

Las siguientes opciones te dejan personalizar tus procesos de compilación y pruebas automatizadas.

Variables de entorno para compilar y probar

El proceso de compilación establece varias variables de entorno de utilidad, las cuales están disponibles durante las compilaciones automatizadas, las pruebas automatizadas y la ejecución de hooks.

Note

Estas variables de entorno solo están disponibles para los procesos de compilación y prueba, y no afectan al entorno de ejecución de tu servicio.

  • SOURCE_BRANCH: el nombre de la rama o de la etiqueta que se está probando actualmente.
  • SOURCE_COMMIT: el hash SHA1 del commit que se está probando.
  • COMMIT_MSG: el mensaje del commit que se está probando y compilando.
  • DOCKER_REPO: el nombre del repositorio de Docker que se está compilando.
  • DOCKERFILE_PATH: el dockerfile que se está compilando actualmente.
  • DOCKER_TAG: la etiqueta del repositorio de Docker que se está compilando.
  • IMAGE_NAME: el nombre y la etiqueta del repositorio de Docker que se está compilando. (Esta variable es una combinación de DOCKER_REPO:DOCKER_TAG).

Si estás utilizando estas variables de entorno de compilación en un archivo docker-compose.test.yml para pruebas automatizadas, decláralas en el entorno de tu servicio sut como se muestra a continuación:

services:
  sut:
    build: .
    command: run_tests.sh
    environment:
      - SOURCE_BRANCH

Invalidar comandos de compilación, prueba o subida

Docker Hub te deja invalidar y personalizar los comandos build, test y push durante los procesos de compilación y prueba automatizados utilizando hooks. Por ejemplo, podrías usar un hook de compilación para establecer argumentos de compilación utilizados únicamente durante el proceso de compilación. También puedes configurar hooks de fase de compilación personalizados para realizar acciones entre estos comandos.

Important

Usa estos hooks con precaución. El contenido de estos archivos de hook reemplaza a los comandos básicos de docker, por lo que debes incluir un comando similar de build, test o push en el hook o tu proceso automatizado no se completará.

To override these phases, create a folder called hooks in your source code repository at the same directory level as your Dockerfile. Create a file called hooks/build, hooks/test, or hooks/push and include commands that the builder process can execute, such as docker and bash commands (prefixed appropriately with #!/bin/bash).

Para invalidar estas fases, crea una carpeta llamada hooks en tu repositorio de código fuente en el mismo nivel de directorio que tu Dockerfile. Crea un archivo llamado hooks/build, hooks/test o hooks/push e incluye los comandos que el proceso de compilación pueda ejecutar, como comandos docker y bash (con el prefijo correspondiente #!/bin/bash).

Estos hooks se ejecutan en una instancia de Ubuntu, que incluye intérpretes como Perl o Python, y utilidades como git o curl. Consulta la documentación de Ubuntu para obtener la lista completa de intérpretes y utilidades disponibles.

Hooks de fase de compilación personalizados

Puedes ejecutar comandos personalizados entre las fases del proceso de compilación mediante la creación de hooks. Los hooks te dejan proporcionar instrucciones adicionales a los procesos de autobuild y autotest.

Crea una carpeta llamada hooks en tu repositorio de código fuente al mismo nivel de directorio que tu Dockerfile. Coloca en esa carpeta los archivos que definen los hooks. Los archivos de hook pueden incluir tanto comandos docker como comandos bash, siempre que lleven el prefijo correspondiente #!/bin/bash. El compilador ejecuta los comandos de los archivos antes y después de cada paso.

Están disponibles los siguientes hooks:

  • hooks/post_checkout
  • hooks/pre_build
  • hooks/post_build
  • hooks/pre_test
  • hooks/post_test
  • hooks/pre_push (solo se usa al ejecutar una regla de compilación o una compilación automatizada)
  • hooks/post_push (solo se usa al ejecutar una regla de compilación o una compilación automatizada)

Ejemplos de hooks de compilación

Invalidar la fase "build" para establecer variables

Docker Hub te deja definir variables de entorno de compilación ya sea en los archivos de hook o desde la interfaz de compilación automatizada, a las que luego puedes hacer referencia en los hooks.

El siguiente ejemplo define un hook de compilación que utiliza argumentos de docker build para establecer la variable CUSTOM basándose en el valor de la variable definida mediante los ajustes de compilación de Docker Hub. $DOCKERFILE_PATH es una variable que proporcionas con el nombre del Dockerfile que quieres compilar, e $IMAGE_NAME es el nombre de la imagen que se está compilando.

$ docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME .
Important

Un archivo hooks/build invalida el comando básico docker build utilizado por el compilador, por lo que debes incluir un comando de compilación similar en el hook o la compilación automatizada fallará.

Consulta la documentación de docker build para aprender más sobre las variables en tiempo de compilación de Docker.

Subir a múltiples repositorios

Por defecto, el proceso de compilación sube la imagen únicamente al repositorio donde están configurados los ajustes de compilación. Si necesitas subir la misma imagen a múltiples repositorios, puedes configurar un hook post_push para añadir etiquetas adicionales y subir la imagen a más repositorios.

$ docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT
$ docker push $DOCKER_REPO:$SOURCE_COMMIT

Clones de repositorios de origen o ramas

Cuando Docker Hub descarga una rama de un repositorio de código fuente, realiza un clon superficial (shallow clone), es decir, clona únicamente la punta de la rama especificada. Esto tiene la ventaja de minimizar la cantidad de transferencia de datos necesaria desde el repositorio y acelerar la compilación, ya que solo descarga el código mínimo necesario.

Como resultado, si necesitas realizar una acción personalizada que dependa de una rama diferente, como un hook post_push, no podrás cambiar (checkout) a esa rama a menos que realices una de las siguientes acciones:

  • Puedes obtener una descarga superficial de la rama de destino haciendo lo siguiente:

    $ git fetch origin branch:mytargetbranch --depth 1

  • También puedes convertir el clon en "no superficial" (unshallow), lo que recupera todo el historial de Git (y puede llevar mucho tiempo o transferir muchos datos) utilizando la opción --unshallow en el fetch:

    $ git fetch --unshallow origin