Custom property in image name breaks hierarchy determination

[cybe]

Hey,

for my use case I'm including the current branch name within the generated image name. So I use something like FROM {{.DEFAULT_PULL_REGISTRY}}/base/{{.BRANCH}}:{{.BASE_VERSION}} in child images (Full minimal testcase). When determining the hierarchy, this property does not seem to be evaluated properly:

$ docker-bakery build -s major -c config.json -d base/Dockerfile.template -p BRANCH=master

Dockerfiles hierarchy discovered in .
├── scratch
│   └── base
└── {{.BRANCH}}
    └── child

As a result, only base gets build, because child is not being determined as a child of base.

[jaroslaw-bochniak]

Hi, sorry for late replay. Hierarchy of images is tightly related to naming of the folder. In your case The hierarchy is broken because during analysing process the image base/master:xxx is not detected in directory structure. Only the base directory is present therefore docker-bakery assumes that this image (base/master) is an external one.

As a workaround for your case you could use the name of the branch as a part of the image version and not the name. For example you could keep the current directory structure but update the config to:

"defaultBuildCommand": "docker build --tag {{.DEFAULT_PUSH_REGISTRY}}/{{.IMAGE_NAME}}:{{.IMAGE_VERSION}}-{{.BRANCH}} {{.DOCKERFILE_DIR}}",

and the Dockerfile.template of the child image to FROM {{.DEFAULT_PULL_REGISTRY}}/base:{{.BASE_VERSION}}-{{.BRANCH}}

With this configuration I was able to build your structure:

$ docker-bakery build -s major -c config.json -d base/Dockerfile.template -p BRANCH=master
RootDir not defined in config, applying config parent dir: .
Obtaining image latest versions from git remote tags
Analyzing Dockerfile.template files
Dockerfiles hierarchy discovered in .
└── scratch
    └── base
        └── child

====================================================================
Working with major scope of: base version: 0.0.0 => 1.0.0
Config properties:
        ...
	BASE_VERSION=1.0.0
	BRANCH=master
	DEFAULT_PULL_REGISTRY=dummy.example.net
	DEFAULT_PUSH_REGISTRY=dummy.example.net
	DOCKERFILE_DIR=/Users/jb/Sources/smart/bakery-testcase/base
	IMAGE_NAME=base
	IMAGE_VERSION=1.0.0
Templating base/Dockerfile.template to /Users/jb/Sources/smart/bakery-testcase/base/Dockerfile
Executing: docker build --tag dummy.example.net/base:1.0.0-master /Users/jb/Sources/smart/bakery-testcase/base
Sending build context to Docker daemon  4.096kB
Step 1/2 : FROM scratch
 --->
Step 2/2 : ENV BRANCH=master
 ---> Using cache
 ---> 91176b4d409d
Successfully built 91176b4d409d
Successfully tagged dummy.example.net/base:1.0.0-master
Triggering dependant build of child
====================================================================
Working with major scope of: child version: 0.0.0 => 1.0.0
Config properties:
         ...
	BASE_VERSION=1.0.0
	BRANCH=master
	CHILD_VERSION=1.0.0
	DEFAULT_PULL_REGISTRY=dummy.example.net
	DEFAULT_PUSH_REGISTRY=dummy.example.net
	DOCKERFILE_DIR=/Users/jb/Sources/smart/bakery-testcase/child
	IMAGE_NAME=child
	IMAGE_VERSION=1.0.0
Templating child/Dockerfile.template to /Users/jb/Sources/smart/bakery-testcase/child/Dockerfile
Executing: docker build --tag dummy.example.net/child:1.0.0-master /Users/jb/Sources/smart/bakery-testcase/child
Sending build context to Docker daemon  4.096kB
Step 1/2 : FROM dummy.example.net/base:1.0.0-master
 ---> 91176b4d409d
Step 2/2 : ENV CHILD_BRANCH=master
 ---> Using cache
 ---> 394d43520f80
Successfully built 394d43520f80
Successfully tagged dummy.example.net/child:1.0.0-master
====================================================================
Processed 2 image(s) in 2.319443859s:
	base 0.0.0 => 1.0.0
	child 0.0.0 => 1.0.0

I hope it helps.

[cybe]

Hi @jaroslaw-bochniak! I very much appreciate your reply, but I actually moved on and implemented my own mechanism. I achieved support for dynamic branch information as part of the image name (and not only within the tag).