Allow tests to create artifacts that are retrievable from server

[abailly]

• A test should be able to declare generated artifacts (e.g. files) that it can provide on demand
• When test completes, it sends list of artifacts to server
• Server can retrieve artifacts from tests when requested, e.g. through GUI or programatically during ovenUpdate phase

[ndmitchell]

A tweak, I'd definitely send the artifacts from the client to the server straight away - I always work on the assumption the client may have gone when we get around to the update.

Also, the Stdout of the test result should be an artifact.

[ndmitchell]

Hi @abailly - how useful would this be to you currently? Would it be a nice future cleanup? A meaningful improvement to the current state? Or not really that interesting given your workarounds?

[abailly]

Main use would be to host generated docker containers and allow deployer to retrieve them from CI server instead of from dockerhub. Definitely an improvement as having to rely on dockerhub is not that great: it is a bit slow and has limited interface, e.g. docker pull whereas we could have some more sophisticated retrieval strategies.

Moreover, we could also use this feature to retrieve various test results (eg. in "standard" JUnit format?).

[ndmitchell]

You could certainly use it to retrieve the stdout/stderr or a test result. Not sure what "standard" JUnit format is though. Also, it will be indexed by run id, which you can't compute yourself from patch/test/state.

[abailly]

Kinda standard because a couple of runners output that format which can be
easily interpreted by things like Jenkins. Just an example...

Le mardi 30 juin 2015, Neil Mitchell notifications@github.com a écrit :

You could certainly use it to retrieve the stdout/stderr or a test result.
Not sure what "standard" JUnit format is though. Also, it will be indexed
by run id, which you can't compute yourself from patch/test/state.

—
Reply to this email directly or view it on GitHub
#8 (comment).

Arnaud Bailly

twitter: abailly
skype: arnaud-bailly
linkedin: http://fr.linkedin.com/in/arnaudbailly/

[ndmitchell]

As part of #19 I switched to sending multipart pieces. Now all the underlying infrastructure work is done to make it feasible - still need to plumb it all through.

[abailly]

Could you point me at the location in source code where I should look to allow retrieval of "build artifacts"?

[ndmitchell]

The basic idea would be to switch Answer to contain outputs :: [(String, BigString)] instead of just stdout :: BigString, where by convention one of the entries would be [("stdout", stdout)]. You then have to modify the bits sending Answer to include all outputs, and modify the database to save all outputs. As an extra step, you may wish to modify the server to send a particular output, but it's less important since you could always grab them straight off the server via SSH or similar. Changing the type, and changing what fails to type check, should be feasible.

If you give it a try, and don't get anywhere, let me know. It's probably an hour or so for me to wire through, so I could probably slice out some time if it's important to you.

[abailly]

Probably found another way to do this...