Return failure response code when the container stops with non-zero exit code about conjob

[ScottG489]

A few ideas I've settled on.

1. Don't return a stream. Why is it important for the user to see the text in real time anyways? All they really need to know is if it succeeded or failed. Anything else is superfluous.
2. Return the exit code at the end of the stream. This has 2 side effects:
   2a. Requires some kind of standard interface for the response (i.e. The build output is all the returned text except for the last line which is the status code they need to parse).
   2b. Requires the user to manually parse the response and determine if the job passed or failed
3. (Undesirable) Return a job identifier that the user could call again to get the exit code. (undesirable since it's two requests and makes the server stateful. Statefulness is one of the core philosophy of this application). I think this could take two approaches with the first being the only real option since
   3a. Return the job id to the user and as long as the job is running then the user can get the logs so far. This is less stateless because there isn't any permanent state that is being held and as soon as the job finishes that endpoint will no longer be valid
   3b. (BAD IDEA) Return the job id to the user and they can look up running jobs or jobs that finished running. Technically docker is handling the state for us here. However, I think we might want to consider automatically cleaning up jobs after they run which means these logs won't be around. However, if there's ever a method devised to only clean up jobs on a regular basis this may be more feasible because the logs may still be around. However, we have to make it clear to the user that there is no guarantee there logs will still be around as they may have been cleaned up. This may be an option down the road after other basic features of the server are solidified since it doesn't technically make the server stateful since docker is handling the state. But it still is by relation.

Note that between 1 and 2 it may be a good idea to settle on a standard interface for a response anyways such as JSON. Of course with the first option it wouldn't be required. However, we already require JSON input for the interface so this may align better there. However, counter to that is another core philosophy of this project is simplicity for the user. Although it would align the input and output interfaces it would make things slightly less simple since the user may need to parse the JSON returned.

[ScottG489]

I think I will go with idea # 1.

It is the simplest solution to implement. It also simplifies the response to not being a stream which I think is not necessarily a requirement. It may be somewhat expected as a feature of a CI server but I think that could be a bit of a deep seated idea/antipattern that you need to watch your CI jobs output as it runs. Usually the only reason you are watching a build is if you are worried about it failing or there is some problem. Since all of these builds can be run all the same locally using the docker container then it should be very infrequent that you need to troubleshoot build issues on the build server itself rather than running them locally and troubleshooting that way. Plus it's not like you won't be getting your job output; it will just have to wait until the job finishes.

I think eventually it could be a feature to the server that can be specified with a flag set in the request. However, I think that will look something like option # 2 which also requires changing the format of the response likely to a json object with the log output and the exit code. The complicated part about this is figuring out how to augment the output stream.

[ScottG489]

I'd like to point out that this ticket evolved from the original purpose. It was initially intended for only figuring out what error codes to return in the header. Then when it was realized that we had no control over the header when streaming a response we needed to figure out how to solve that problem first. The second issue has been solved by the commit and explained by the last comment.

Next is to solve the problem of what http status code to return. After thinking about it during work to fix the other issue, I think that a 400 is a good code to return. The biggest issue here is that it doesn't necessarily identify the issue as something with the build itself (e.g. if the user provided a bad image name). However, I don't think we necessarily need an error code to signify where the problem happened between the server or container. So maybe that really isn't that big of a deal anyways.

For now I will at least go with returning a 400 when the build itself returns a non-zero exit code.

[ScottG489]

Closed by 3600bb9

Other relevant commits:
1b1ab37