(Sólo una sugerencia)

Por lo general, tenemos la siguiente estructura para construir nuestras imágenes acoplables:

 my-image/ ├── assets │  ├── entrypoint.sh │  └── install.sh ├── build.sh ├── Dockerfile ├── README.md └── VERSION

• build.sh : Aquí es donde debería invocar script_that_creates_magic_file.sh . Otras tareas comunes implican la descarga de archivos necesarios o la copia temporal de claves ssh del host. Finalmente, este script llamará a docker build .
• Dockerfile : como de costumbre, pero dependiendo de la cantidad de comandos que necesitemos ejecutar, es posible que tengamos un install.sh
• install.sh : Esto se copia y ejecuta dentro del contenedor, instala paquetes, elimina archivos innecesarios, etc. Sin estar 100% seguro, creo que este enfoque reduce la cantidad de capas evitando múltiples comandos en una sola RUN
• entrypoint.sh : Punto de entrada del contenedor. Nos permite realizar tareas cuando se inicia el contenedor (como analizar variables de entorno) e imprimir información de depuración

Considero que la estructura anterior es conveniente y autodocumentada, ya que todos los miembros del equipo pueden crear cualquier imagen (sin instrucciones/pasos especiales). El README está ahí para explicar lo que está haciendo la imagen... pero no te mentiré... por lo general está vacío... (o tiene un h1 para que lo muestre el gitlab) :)

Para responder a la pregunta; no, no hay una funcionalidad integrada para ejecutar un comando en el host antes de la docker build (es decir, no hay "ganchos" para activar scripts en el host).

Si proporciona más información sobre su caso de uso, posiblemente haya alternativas (por ejemplo, usar una combinación de --build-arg y docker compose)