* Output from the main strawboss executable is properly directed to stdout
and stderr.
* Added threshold logging to strawboss core functions.
* Fixed a bug in the way dependent steps were detected and executed.
The logic for checking if prior steps had already been executed was only
executed once when the initial step was prepared, not for any of the
dependent steps. This logic has been moved into the main work block for
executing steps.
* Renamed `initiateRun` to `run` and `runStep` to `doRun` to be more accurate.
* Dependent steps get their owng, independent copy of the workspace.
* Updated the test project to provide a test target.
* Implemented periodic maintenance window.
* Moved worker creation into the core module.
* Worker processes no longer create run requests, but read queued requests from
the file system.
* Build status and logs have been moved into the StrawBoss data directory.
* An initial build status is recorded when the job is queued.
* Build status is recorded for build references as well as actual versions.
So there will be a build status for "master", for example, that is
overwritten whenever "master" is built for that step.
* RunRequests now include a timestamp.
* Added a Run object to contain both a RunRequest and the corresponding
BuildStatus for that run.
* API endpoints that talk about runs now return Run objects instead of
RunRequests.
* Moved all data layer operations into the core module so that the
"database API" only lives in one place.
* Rename artifactsRepo -> buildDataDir to be more explicit about the fact that
it holds more than just the artifacts.
* Revert removal of run ids.
* Move Worker definition into core as part of making the core responsible for
accepting run requests.
* Make the core module more responsible for internal details of data structure
and storage. External callers should not need to construct paths to
artifacts, versions, etc. but should be able to call method in the core
module to do this work for them.
* The working directory no longer contains anything but the checked-out code.
All StrawBoss-specific data is stored by StrawBoss elsewhere.
* Add a regular maintenance cycle to the server module.
StarBoss is meant for building things checked into the repo It is also designed
around repeatable builds. So it makes the assumption that running a build step
for a specific version of a project will always result in the same output. So
runs are identified by the project, build step, and version.
We were expecting to find the path to the `strawboss` binary implicitly from
the environment, which meant that configuration was also implicit, and required
more setup. Now the path to the binary is explicit in the StrawBoss runtime
configuration, and the path to the configuration file can also be explicitly given.
