Ignore those files regardless of the path. Previously they were only
ignored in the project root, but I want to create several worker
configurations in a subdirectory for testing.
A task's "activity" field is a string that describes the last-performed
operation on the task. In Flamenco 2, a Worker's "last activity" is the
timestamp at which it was last seen. Using the same term for different
things is confusing, and thus gets removed until the Worker's "last seen"
functionality is reimplemented.
A task can exist in the database but not have any log stored on disk yet.
This is now returned as `204 No Content` instead of an internal server
error.
The web interface is also adjusted to cope with this.
Show workers with their status, and allow clicking on a worker to activate
it and show its details (which currently is limited to just its ID). Does
include Vue Router handling of the active worker ID and CSS classes for
worker statuses.
This basically copies the `JobsTable` component to `workers/WorkersTable`.
The intention is that all the jobs-specific components will move into a
`jobs` subdirectory at some point.
The "fix" is just setting the height to 50% instead of 100%, as the latter
will make it as big as the entire column; that causes the scrollbar to
show, as the column title isn't taken into account.
add `-delay` CLI argument, which adds a random delay of around 250ms to
all HTTP responses.
The web interface is quite asynchronous in nature, and having more
randomness and more visible delays in there will help development.
This CLI argument should not be used in production.
The `JobDetails` component now emits a `reshuffled` event whenever its
contents have changed, so that other components can respond to any changes
in available space. This event now triggers a resize of the tasks table
on the next DOM tick (so that the new sizes of the HTML elements are
available).
The `TasksTable` component also recomputes the table size when the task
status filters change (because that might have triggered a show/hide of
the filter bar). It also computes the available height slightly differently
so that it's all done relative to the tabulator element.
There is just one TODO left, which is a hard-coded offset of 12 that
should be obtained dynamically from somewhere -- no idea where it comes
from or why it's necessary.
Calculate the Tasks List height by subtracting its offsetTop from
the Jobs Details column height.
Known issues:
There is a glitch in which the height can be sometimes longer or shorter
than expected, due to asynchronous loading of other components in Job Details
(such as Job Settings or table filters).
Do not use pink for queued/requeueing. Pink in Blender is used to indicate
something going wrong (missing textures, broken shaders). Use a shade of
blue instead which is closer in hue to green which means completed.
The code to fetch the task log tail is moved from `JobsView.vue` to
`TaskLog.vue`, as that knows exactly when it's shown & hidden.
The subscriptions to the task log updates will have to be managed in the
same way; that's for another commit.
Clicking on a job/task in their respective lists will now always activate
it, regardless of where on the row was clicked.
Managing the filters by clicking on the status was a nice idea, but was
confusing in practice.
It returns 2048 bytes at most. It'll likely be less than that, as it will
ignore the first bytes until the very first newline (to avoid returning
cut-off lines). If the log file itself is 2048 bytes or smaller, return the
entire file.
Add a small wrapper around github.com/google/uuid. That way it's clearer
which functionality is used by Flamenco, doesn't link most of the code to
any specific UUID library, and allows a bit of customisation.
The only customisation now is that Flamenco is a bit stricter in the
formats it accepts; only the `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` is
accepted. This makes things a little bit stricter, with the advantage
that we don't need to do any normalisation of received UUID strings.
Implement task log broadcasting via SocketIO. The logs aren't shown in the
web interface yet, but do arrive there in a Pinia store. That store is
capped at 1000 lines to keep memory requirements low-ish.
