Ejecutar make una vez genera un error que sugiere que $(shell docker run -d $(IMAGE)) no funciona según lo previsto.
Sin embargo, ejecutar una segunda vez funciona de maravilla.
Parece que make build-image build-api hace que la compilación-api de destino no espere a que se complete la compilación de la imagen. ¿Debo introducir una ejecución retrasada? (el sueño infame :D)
$ cat Makefile .PHONY: build IMAGE := tensorflow-serving-grpc build: build-image build-api clean: -docker rmi -f $(IMAGE) build-image: docker build -t $(IMAGE) . build-api: CONTAINER_ID:=$(shell docker run -d $(IMAGE)) build-api: docker wait $(CONTAINER_ID) docker cp $(CONTAINER_ID):/usr/src/vendor ./ docker rm -f $(CONTAINER_ID)Si no espera, es porque permitió la ejecución en paralelo con la opción ejecútelo desde $(shell...). Debe evitarse el uso de $(shell ...) a menos que sepa lo que hace.-jN ,
También debe evitar la ejecución paralela de build-image y build-api declarando un requisito previo.
.ONESHELL: build-api: build-image set -e CONTAINER_ID=`docker run -d $(IMAGE)` docker wait $$(CONTAINER_ID) docker cp $$(CONTAINER_ID):/usr/src/vendor ./ docker rm -f $$(CONTAINER_ID)Tiene una variable específica de destino con un efecto secundario y supone incorrectamente que la variable no se expandirá hasta que se ejecute la regla. Cambiaría a usar una variable bash y concatenaría la receta para ejecutarla en un solo shell de la siguiente manera:
build-api: build-image CONTAINER_ID=$$(docker run -d $(IMAGE)); \ docker wait $${CONTAINER_ID}; \ docker cp $${CONTAINER_ID}:/usr/src/vendor ./; \ docker rm -f $${CONTAINER_ID}; Otra opción es crear un objetivo que cree la identificación del contenedor y la almacene en un archivo. Haga build-api dependa de este nuevo objetivo y, luego, en build-api , haga que cada línea de receta lea el valor del archivo.