Instead of returning an error "error doing X", just return "doing X". The
fact that it's returned as an error object says enough about that it's
an error.
This also makes it easier to chain error messages, without seeing the
word "error" in every part of the chain.
Add `crosspath.ToNative(path)`, which returns the path with platform-
native path separators. This is meant for use in the Worker, to convert
paths before attempting to use them.
Both Go's standard `path` and `path/filepath` packages are too limiting to
work well for Flamenco. The former assumes Linux/POSIX paths, the latter
only works with platform-native paths. Neither can work with Windows paths
on Linux, or Linux paths on Windows.
The on-disk database that was used before caused issues with tests running
in parallel. Not only is there the theoretical issue of tests seeing each
other's data (this didn't happen, but could), there was also the practical
issue of one test running while the other tried to erase the database file
(which fails on Windows due to file locking).
Where the PostgreSQL DB migration code could handle `NOT NULL` columns just
fine, SQLite has less table-altering functionality. As a result, migrations
have to copy entire database tables, which doesn't play well with
not-nullable columns.
Generated code is to be committed to Git anyway, so there is no need to
regenerate it on every build.
The code can be regenerated explicitly by running `make generate`.
Git wants to see native line-ends in source files, but the code generators
we use always write UNIX line-ends. `make generate` on Windows now passes
generated files through `unix2dos`. This allows regenerating files without
Git listing them as modified.
The Makefile started as a standard file I use for multiple Go projects,
but it was aimed at having only one executable to build. I've removed
everything that assumes a single executable, and kept the parts that are
actually used now.
The build chain got a bit confused when doing things from scratch, as
`test_support.go` was used in the non-test builds. Renaming it to
`support_test.go` was the easiest way to avoid that.
Direct copy of the Flamenco Server Python code, for handling the change
of a job's status to trigger status changes on its tasks.
Not yet connected to the rest of the Manager logic.
The task status change → job status change code is a direct port of the
Flamenco Server v2 code written in Python.
There is no job status change → task status changes logic yet, and the
tests are also far from complete.
