Try to get the `.editorconfig` and `.prettierrc` files as close as possible
to the formatting that was used in Flamenco. Because these files weren't
here during most of Flamenco's development so far, having them caused quite
a few changes in the webapp files.
No functional changes intended.
When the worker is started with `-restart-exit-code 47` or has
`restart_exit_code=47` in `flamenco-worker.yaml`, it's marked as
'restartable'. This will enable two worker actions 'Restart
(immediately)' and 'Restart (after task is finished)' in the Manager web
interface. When a worker is asked to restart, it will exit with exit
code `47`. Of course any positive exit code can be used here.
As it was decided that the name "tags" would be better for the clarity
of the feature, all files and code named "cluster" or "worker cluster"
have been removed and replaced with "tag" and "worker tag". This is only
a name change, no other features were touched.
This addresses part of #104204.
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104223
As a note to anyone who already ran a pre-release version of Flamenco
and configured some worker clusters, with the help of an SQLite client
you can migrate the clusters to tags. First build Flamenco Manager and
start it, to create the new database schema. Then run these SQL queries
via an sqlite commandline client:
```sql
insert into worker_tags
(id, created_at, updated_at, uuid, name, description)
select id, created_at, updated_at, uuid, name, description
from worker_clusters;
insert into worker_tag_membership (worker_tag_id, worker_id)
select worker_cluster_id, worker_id from worker_cluster_membership;
```
The support is still fairly minimal. Clusters cannot be managed via the
webapp yet, so the API has to be used directly for that. Workers can be
assigned to clusters via the webapp though.
Brave (and maybe other browseres) refuse to set the 'User-Agent' header
in XMLHTTPRequests, and are vocal about this in the debug log. Since the
OpenAPI code generator always outputs a custom 'User-Agent' header, I've
added some JS code to strip that off when constructing an API client.
Add "remove worker" button to the worker details panel. It will
show a little warning when the worker is still running, and also has an
explanation of what removing a worker actually means.
* Use full-width form
Fitting an input inside a <dl> makes it jump around
* Add button to toggle schedule on/off
* Add button to cancel editing the schedule
* Use time type inputs for Start/End Time fields
* Add help text to "Days of Week" to explain it's only the first 2 letters
No functional change, just name the components with their type first,
so that all 'link' related components are more discoverable and next
to each other.
The Task details component already linked to the Worker it was assigned
to last, and now the Worker links back to the task.
There's only one task shown in the Worker details. If the Worker is
actively working on a task, that one's shown. Otherwise it's the
last-updated task that was assigned to the worker.
Copy-paste of TasksTable `recalcTableHeight`.
Even though the function does not work well 100%, it's better than not
having the table resize.
When the issue gets fixed, it should be copied over to TasksTable and JobsTable.
When data is updated, resize columns in the job/task/worker tables. For
example, status change requests of Workers require more space, for example
going from `awake` to `awake → offline`.
The 720px was almost filling up the entire height, making it hard to add
anything new at the top. Soon it should be auto-resizing anyway, making
this less relevant.
UI/UX needs improvements, but there now are some buttons to manage Workers.
They request forced status changes, so nothing lazy yet. Still have to
consider how to include that in the UI. Could probably follow the
Flamenco 2 Manager design.
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.
