Make the red_amber_green.rb file part of the start-point #175
Description
Have a hidden "tab" next to 'output' called 'colour' which contains the rag lambda source.
This is passed "out of band" to web and then runner so it can never interfere with the real files.
Runner currently gets the lambda source with:
docker run --rm --entrypoint=cat #{IMAGE} /usr/local/bin/red_amber_green.rb
and then the lambda is then eval'd inside an empty binding (in the runner itself).
A good starting place would be to change this line so it actually runs the lambda inside a Ruby docker container that is passed stdout, stderr, status. It should be relatively simple to do this with the existing runner machinery which tar pipes the sources files directly from variables to /home/sandbox which is in a tmp-fs ramdisk. Try this and then run a ./run_tests.sh on a ruby-start-point with and without the mod and check the durations printed on the terminal. I think it should basically take the same time since the current implementation already has to do the docker-run-cat command above to get the lambda source anyway.
Another idea is that the image-augmenter could install ruby into all CDL images and the colour determination then gets rolled into the end of cyber_dojo_main.sh, which multiples a quad [stdout,stderr,status,colour] as its result. This would only be worthwhile if it was faster than making a second docker-run call.
I can then extend the start-point manifest to include the red-amber-green lambda file path, and ensure the read manifest contains the lambda source.
Then I can extend creator+web so that the lambda source becomes a 'secret' file, a bit like output having its own tab. It must not be allowed to interfere with the files the participant sees. Will also have to extend the start-points-base image as it will see the new manifest key as unknown
Then the lambda source can be passed through to runner.
There could be a new on/off config option of whether you wanted to see the tab for the colour lambda. Being able to control the initial on/off status via an env-var would be handy so you can actually edit it during the development cycle when making a new language+test-framework + language-start-point pair. But probably overkill, as start-points run_tests.sh file is sufficient.
In some ways, running the red-amber-green lambda in a container is actually better than running it directly in the runner. If the lambda had an infinite loop it would break runner entirely, but with this refactoring it will be subject to the same max-seconds timeout.