# Opciones avanzadas para autobuild y autotest


> [!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:

```yaml
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](#hooks-de-fase-de-compilacion-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](https://releases.ubuntu.com/), que incluye intérpretes como Perl o Python, y utilidades como `git` o `curl`. Consulta la [documentación de Ubuntu](https://ubuntu.com/) 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](/docker-hub/repos/manage/builds/advanced/))
* `hooks/post_push` (solo se usa al ejecutar una regla de compilación o una [compilación automatizada](/docker-hub/repos/manage/builds/advanced/))

### 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.

```console
$ 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](/reference/cli/docker/buildx/build/#build-arg) 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.

```console
$ 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:

    ```console
    $ 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:

    ```console
    $ git fetch --unshallow origin
    ```