Dockerfile using "FROM <image> as base" not handled

[dbrumley]

Just debugged a challenge where a student wrote:

FROM ubuntu as base
<rest was correct>

When you run cmgr playtest <problem>, you get a very hard-to-understand message:

error creating build: aborting because no build image identified picoctf/18739f24/image-forensics/1

After enabling debug it became more clear what the problem was: somehow the image got tagged as "picoctf/18739f24/image-forensics/1-base", so the run failed.

Figured this out with gdb.

cmgr: [INFO:  version: unknown]
cmgr: [INFO:  challenge directory: /home/dbrumley/cmgr/challenges]
cmgr: [INFO:  artifacts directory: /home/dbrumley/cmgr/artifacts]
cmgr: [INFO:  connected to docker (API v1.47)]
cmgr: [INFO:  searching /home/dbrumley/cmgr/challenges/aburkhol/challenge-1 for challenges]
cmgr: [DEBUG:  Found challenge Markdown at /home/dbrumley/cmgr/challenges/aburkhol/challenge-1/problem.md]
cmgr: [DEBUG:  processing markdown: section='Description' start=11 end=14]
cmgr: [DEBUG:  processing markdown: section='Details' start=15 end=18]
cmgr: [DEBUG:  found template in range [17, 77] (len(string) = 82]
cmgr: [DEBUG:  processing markdown: section='Hints' start=19 end=22]
cmgr: [DEBUG:  processing markdown: section='Attributes' start=23 end=25]
cmgr: [DEBUG:  challenge options: cmgr.ChallengeOptions{NetworkOptions:cmgr.NetworkOptions{}, ContainerOptions:cmgr.ContainerOptions{Init:false, Cpus:"", Memory:"", Ulimits:[]string(nil), PidsLimit:0, ReadonlyRootfs:false, DroppedCaps:[]string(nil), NoNewPrivileges:false, DiskQuota:"", CgroupParent:""}, Overrides:map[string]cmgr.ContainerOptions{"":cmgr.ContainerOptions{Init:false, Cpus:"", Memory:"", Ulimits:[]string(nil), PidsLimit:0, ReadonlyRootfs:false, DroppedCaps:[]string(nil), NoNewPrivileges:false, DiskQuota:"", CgroupParent:""}}}]
cmgr: [DEBUG:  Dockerfile at /home/dbrumley/cmgr/challenges/aburkhol/challenge-1/Dockerfile: true]
cmgr: [DEBUG:  dockerfile[87:91] base]
cmgr: [DEBUG:  found 0 ports]
cmgr: [DEBUG:  onePort=false]
cmgr: [INFO:  found challenge picoctf/18739f24/image-forensics]
cmgr: [DEBUG:  /tmp/221229692.tar]
cmgr: [DEBUG:  /home/dbrumley/cmgr/challenges/aburkhol/challenge-1/Dockerfile]
cmgr: [DEBUG:  /home/dbrumley/cmgr/challenges/aburkhol/challenge-1/container_instructions.txt]
cmgr: [DEBUG:  /home/dbrumley/cmgr/challenges/aburkhol/challenge-1/puffin.jpg]
cmgr: [DEBUG:  Opening &{0  map[] 897795681 flag{%s} [] false 0 picoctf/18739f24/image-forensics [] manual-1ec035c482f027e8 -1}]
cmgr: [DEBUG:  Running select...]
cmgr: [DEBUG:  Build of picoctf/18739f24/image-forensics has ID 1]
cmgr: [DEBUG:  creating image picoctf/18739f24/image-forensics:1-base]
cmgr: [ERROR:  aborting because no build image identified picoctf/18739f24/image-forensics/1]
error creating build: aborting because no build image identified picoctf/18739f24/image-forensics/1

[dmartin]

If you name any build stage (such as base), then cmgr assumes that you will name the rest of your build stages (either with specific host names which are then # LAUNCHed, or with one having the explicit name challenge which will be implicitly launched).

On the other hand, if no stages are named (other than potentially builder), then it assumes that the final unnamed stage should be built and launched as an image/host named challenge.

I agree this is very confusing behavior. We can probably at least output a better error message if neither of those conditions are met.