This of course needs SSH access to the flamenco.io website.
Run `hugo --serve` from the `web/flamenco-io-site` directory to simply
run an in-memory copy of the site, and browse it locally at
http://localhost:1313/
Add a `-withBlender` CLI argument for a unit test, to aid in debugging
T99438.
Run the test with `go test ./internal/worker/find_blender/ -args -withBlender`
to actually fail when the file association with `.blend` files cannot be
found.
Note that this doesn't rely on Blender being runnable, but it does rely
on _something_ being associated with .blend files.
Building this site requires Hugo (not yet included in the README or in the
installation of dependencies in the Makefile). Still very much work in
progress, this is basically the [Geekdocks theme][1] + one page.
[1]: https://geekdocs.de/
Fix an issue with the hourly auto-reloading, where the `reload()` call
somehow was called on "an object that doesn't implement the Location
interface".
Include the worker's "last seen" timestamp in the worker summary, details,
and SocketIO updates.
This is different from the "updated" timestamp, which indicates the last
time the worker entry in the database was updated (which could also be
in response to a status change request from the web interface).
Change all API URL paths from `/api/…` to `/api/v3/…`. This ensures that
old Flamenco v2 clients/workers stop working when the new Manager is in
place. This also allows redirecting API calls based on the URL, also for
future upgrades.
Do a refresh of the web interface once per hour. This is just to make sure
that long-lived displays (like the TV in the hallway at Blender HQ) pick
up on HTML/JS/CSS changes eventually.
In the `simple-blender-render` job type settings, hide the `chunk_size`
setting from the web frontend, and show the `blendfile` setting instead.
The actual blend file being rendered is important to know, whereas the
chunk size can be inferred from the task names anyway.
Add a "Last Rendered" view to the webapp.
The Manager now stores (in the database) which job was the last
recipient of a rendered image, and serves that to the appropriate
OpenAPI endpoint.
A new SocketIO subscription + accompanying room makes it possible for
the web interface to receive all rendered images (if they survive the
queue, which discards images when it gets too full).
Add an operation to get the last-rendered image from whatever job received
such output from a Worker, and add a SocketIO subscription type to receive
updates about all jobs' last-rendered images.
These are necessary for a global last-rendered image display.
After processing an image in the "last-rendered" processor, a SocketIO
object is sent to clients to indicate the last-rendered image needs to
be (re)loaded.
This also moves the previously existing "done callback" from a single
function to a per-image callback, so that it can be called with the
right information in there, and only when that particular image is
actually done processing.
The notification message sent via SocketIO also contains the necessary
info to render the image, so that the web client doesn't have to call
the `fetchJobLastRenderedInfo` operation.
`SocketIOLastRenderedUpdate` objects are meant to be broadcast to SocketIO
clients (i.e. the web interface). They are sent to the job-specific room,
just like task updates.
It doesn't update automatically yet (still needs SocketIO notifications),
and there is no check yet for whether there is actually any last-rendered
image at all, but at least there is a component that shows the image.
Shaman prevents duplicate checkout directories, and communicates the actual
location back to the client. This wasn't used by the add-on though, so
the Flamenco job definition would point to the wrong files.
