c6be698572
* Added endopint to return the logs from a run.
* Refactored the `pathVar & "/" & pathvar` pattern into `pathVar / pathVar`
using the `ospaths` module. Cleaner code, more resistant to extra `/` bugs.
* Added endpoints and core methods to list artifacts for a build, as well as to
retrieve specific artifacts.
* Fixed a problem with the `complete` status being overloaded. The problem was
that in the case of a multi-step build all of the prerequisite steps will
return a state of `complete` which will get recorded in the status file for
the run. The run will continue, but anyone watching the run state file (via
the API for example) had no definitive way to tell the difference between a
sub-step completing and the requested (last) step completing. This was caught
in the functional tests (race condition based on when it polls for the run
status). The fix was to introduce a new build state: `stepComplete`. The
inner `doRun` procedure uses this instead of `complete`. Now the only place
that `complete` is set is at the end of the original call to `run`, right
before the worker terminates. It checks the last result (from the originally
requested step) and if this result is `stepComplete` it "finishes" the build
by setting the state to `complete`. Because this is the only place where
`complete` is set, an observer is now guaranteed not to see `complete` until
all steps have run successfully.
* Fixed a long-standing bug with the request handling logic in error cases
(like requested resources not being available). Issue has something to do
with the way that `except` blocks become special when in an async context.
The main jester routes block invokes the handlers in an async context. The
effect is that one `except` block is fine, but adding more than one (to catch
different exception types, for example) causes the return type of the route
handler to change and not match what the outer block is expecting (a Future).
The fix here is to wrap any exception discrimination within a single outer
except block, re-raise the exception, and catch it inside this new
synchronous context. Ex:
```nim
try: someCall(mayFail)
except:
try: raise getCurrentException()
except ExceptionType1:
# do whatever...
except ExceptionType2:
# do whatever
except:
# general catch-all
return true
```
The return at the end is also part of the story. Jester's match handler
allows a route to defer making a decision about whether it matches. If you
return true from a route block Jester accepts the result as a matched route.
If you return false, Jester discards the result and looks for another
matching route. Normally this is taken care of by the `resp` templates
provided by Jester, but invoking those templates within the except blocks
also causes problems, so we manually setup the response and `return true` to
tell Jester that, yes this route matched, use this response.
* Moved the `/service/debug/ping` endpoint back to `/ping` and removed the
debug-only fence. I envision this as being useful as a simple healthcheck URL.
302 B
302 B
TODO
- Orchestration of docker containers for running builds.
- Write API docs.
NICE TO HAVE
- Use/create some json-schema -> nim code generator to auto-generate json handling code from schemas.
- Use some json-schema -> docs generator to document the API.
- Support unique UUID prefixes in URLs.