UC: as a developer I want to be able to test code w/o nsjail
bug: flaky test `test_go_job`
```
running 1 test
test worker::tests::test_go_job ... FAILED
failures:
---- worker::tests::test_go_job stdout ----
received killpill for worker 0
thread 'worker::tests::test_go_job' panicked at 'assertion failed: `(left == right)`
left: `Object {"error": String("Error during execution of the script:\n\ngo: error obtaining buildID for go tool compile: pipe2: too many open files\ngo: error obtaining buildID for go tool compile: pipe2: too many open files\ngo: error obtaining buildID for go tool compile: pipe2: too many open files")}`,
right: `String("hello world")`', src/worker.rs:2434:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
workaround: disable nsjail
* reorganize handle_child
There were a couple issues with the current implementation:
1. When reading stdout and stderr from the child, as soon as we hit EOF
on one we would stop reading from both (line 1420). This could lead
to the return value not being read from the job program.
2. Lines read from stdout and stderr are put into a channel and read
elsewhere with `rx.recv()` (line 1497) but that channel isn't read
until empty. It is only read in the `while !done.load(...)` (line
1449) loop and that loop can stop after any `.store(true, ...)`.
Which happens when the child exits, when the job is cancelled, when
either stdout or stderr reach EOF...
This can be verified by putting `dbg!(rx.recv().await)` or a similar
assertion after the while loop before returning from that function.
It shows the channel still containing log lines on rare occasions.
I was pretty careful in this to maintain the current behaviour; adding
comments to express intention.
One difference in this is that some regular intervals (cancel check and
ping update) should be more regular?
Before...
> at 00ms wait for 10ms
> at 10ms do things for 3ms
> at 13ms wait again for *10ms*
> at 23ms do things again ...
With change...
> at 00ms wait for 10ms
> at 10ms do things for 3ms
> at 13ms wait again but for *7ms*
> at 20ms do things again ...
Which I'm guessing is preferable but I could be wrong.
* renames; interpolate values in log messages
* do `append_logs()` in tokio::task
* tokio::time::interval & close pipe after limit
* clean up comments
Flow observes `suspend` setting and will wait for resume messages sent for the job before continuing to the next step in a flow.
Adds endpoints under workspaces at `/jobs/<cancel|resume>/<job-uuid>` to either cancel or resume the job with a payload. For POST requests to the endpoint, payload is a JSON document. For GET requests to the endpoints, the payload is a base64url encoded JSON document as the value of the payload query parameter.
* progress
* progress
* all in one
* frontend
* small nits
* go job test
* go.sum is optional
* add golang-go to backend test image
Co-authored-by: sqwishy <somebody@froghat.ca>
It was possible to run them using a webhook, but not through an endpoint.
This PR aims to fix that so the user can target a specific version of
the script to run.
Jakub Kołodziejczak
Ruben Fiszel
sqwishy
ex0ns