Vue Router generates URLs for which there are no static files on the
filesystem (like `/jobs/{job ID}`). To make this work, the webapp's
`index.html` has to be served for such requests. The client-side JavaScript
then figures out how things fit together, and can even render a nice 404
page if necessary.
This shouldn't happen for non-webapp URLs, though. Because of this, the
entire webapp (including the "serve `index.html` if file not found logic)
is moved to a `/app/` base URL.
`make flamenco-manager` now also builds the webapp and embeds the static
files into the binary.
`make flamenco-manager_race` does NOT rebuild the static web files, to
help speed up of debug cycles. Run `make webapp-static` to rebuild the
webapp itself, if necessary, or run a separate web development server with
`yarn --cwd web/app run dev --host`.
Rename `pkg/api/flamenco-manager.yaml` to `flamenco-openapi.yaml`, to
distinguish the OpenAPI definition file from the Flamenco Manager
configuration file of the same name (but in a different directory).
No functional changes.
Regenerating code with `make clean` was somewhat useful when only Go code
was generated, because that didn't include the version number / git hash.
The Python and JS code do have that version/hash, so `make clean` became
a source-altering operation, which wasn't nice.
The version number used in the OpenAPI-generated code shouldn't contain
the `-dirty` suffix. In the common development workflow, those files
will always be dirty; because they're only committed after things are
locally working, the implementation has already been written.
Replace the Vue v2 webapp with a Vue v3 one, and embed the OpenAPI
client in the webapp itself (instead of being its own npm project).
- Vue v2.x -> v3.x
- Tabulator v4.x -> v5.1
- Moment JS -> replaced with Luxon JS
- Vue CLI/UI -> replaced with Vite
This adds a JS client for the OAPI interface, and introduces the SocketIO
stuff into Flamenco Manager itself.
To build & run:
- in `web/manager-api` run `npm install`
- in `web/manager-api` run `npm link`
- in `web/app` run `npm install`
- in `web/app` run `npm link flamenco-manager`
- in `web/app` run `yarn serve`
This may not be a complete list, but at least some of those steps are
necessary.
Instead of having the Python code generator as a separate shell script,
include it in the Makefile. There are now three make targets:
- generate-go: only generate Go code, for the Worker & Manager
- generate-py: only generate Python code, for the Blender add-on
- generate: run both
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.
The chat client itself is just a throwaway project. The SocketIO system
will be used to send realtime updates about jobs, tasks, and workers to
the web frontend.
