We want to differentiate between those RfCs explicitly marked as solved, those potentially solved since the author reached the maximum score, and those being unsolved where the author has not yet reached the full score yet.
Previously, the same runner could be used multiple times with different submissions simultaneously. This, however, yielded errors, for example when one submission time oud (causing the running to be deleted) while another submission was still executed.
Admin actions, such as the shell, can be still executed regardless of any other code execution.
Fixes CODEOCEAN-HG
FixesopenHPI/poseidon#423
Since both projects are developed together and by the same team, we also want to have the same code structure and utility methods available in both projects. Therefore, this commit changes many files, but without a functional change.
* We want to identify a user that has triggered a testrun. Previously (in regular operation), only submission author who were regular users were able to start a testrun. Now, we want to prepare a future where submission authors are programming groups. Still, a testrun is triggered by an individual user and not a group.
* Further, this commit fixes some missing foreign key constrains.
Raising the errors would crash the current thread. As this thread
contains the Eventmachine, that would influence other connections
as well. Attaching the errors to the connection and reading them
after the connection was closed ensures that the thread stays
alive while handling the errors in the main thread of the current
request.
These tests were blocking because of the newly introduced
EventLoop. The messages sent to the EventLoop are now mocked
and the EventLoop isn't blocking anymore in the tests.
In order to provide an alternative to Poseidon, a strategy for the
DockerContainerPool is added that is used by the runner model.
Co-authored-by: Sebastian Serth <Sebastian.Serth@hpi.de>
Timeouts are now handled correctly and the Runner automatically
creates the execution environment if it could not be found in
Poseidon. The runner is deleted locally if Poseidon returns
a bad request error.
The runner model is only a class responsible for storing information
now. Based on the configuration it picks a strategy for the runner
management. The Poseidon strategy is already implemented and tested.
The Docker strategy will follow.
