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.
Add a HTTP redirect for the SIGGRAPH hands-on class. It redirects to
https://siggraph.stuvel.eu/ so that I can easily update the website while
at SIGGRAPH itself.
When the current `HEAD` is tagged, and the work directory is 'dirty', the
`GITHASH` variable now contains the actual Git hash. Before this change it
would only be the word "dirty".
Rename the add-on from `flamenco3-addon.zip` to `flamenco-addon.zip`.
It still contains the same files as before, and in Blender the name of
the add-on has not changed.
Change the package base name of the Go code, from
`git.blender.org/flamenco` to `projects.blender.org/studio/flamenco`.
The old location, `git.blender.org`, has no longer been use since the
[migration to Gitea][1]. The new package names now reflect the actual
location where Flamenco is hosted.
[1]: https://code.blender.org/2023/02/new-blender-development-infrastructure/
The 5.0 binaries that were bundled could no longer be downloaded from the
original URLs, so I took the opportunity to upgrade a minor version.
Unfortunately there is a discrepancy between the last version of FFmpeg
(according to https://ffmpeg.org/download.html#release_5.1) and the
binaries that are offered for download. Because of this, Linux is at 5.1.1,
where Windows and macOS (darwin) are on 5.1.2.
Fix an issue where a shared storage path on Linux, that maps via two-way
variables to a drive root on Windows, caused problems with the path
translation system.
Windows paths that consist only of a drive letter (`F:`) cannot just be
concatenated to a relative path, as that will result in `F:path\to\file`,
which is still a relative path of sorts. This is now handled correctly,
and should result in `F:\path\to\file`.
This fixes#104237.
Simplify the variable expansion code. Instead of using a separate goroutine
and two channels, use a struct + a simple function call.
No functional changes.
Simplify the code for the two-way variables' value-to-variable replacement.
Instead of using a goroutine and two channels, use a separate struct and
call a function on that directly.
No functional changes.
Change the default Manager name from "Flamenco Manager" to just "Flamneco".
The Manager is the central 'thing', and the web interface should just
show "Flamenco". There is no more Flamenco Server (which was a component
in Flamenco v2), and there is no other Flamenco component with a web
interface anyway.
Fix#99410: Web: fetch version on SocketIO reconnect (and maybe reload)
After losing the SocketIO connection and subsequently reconnecting, the
webapp should re-fetch the Flamenco Manager version and display it in
the top-right corner. If it's different from before, then it will log a
notification about the upgrade and refresh the entire page to ensure the
new version is loaded properly.
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104235
Instead of calling `useNotifs()` from the main body of `socket-status.js`,
defer that call until the notifications are actually used.
This decouples the two Pina stores at startup, making it possible to load
`socket-status.js` from `App.vue` without conflicts.
Instead of always performing the periodic integrity check, make it possible
to disable it or run it at different intervals.
Currently for the Blender Studio it's crunch time, so the check should
really only run when there is someone looking at the system (i.e. at
restarts for upgrade purposes).
`flamenco-worker -version` now shows the 'extended' version. This is just
the application version when running a release build. Otherwise it will
be like `3.3-alpha0 (v3.2-nn-ghhhhhh)`, where `nn` is the number of commits
since the last-tagged version (`v3.2` in this example), and `ghhhhhh` is
the Git hash. This can optionally be suffixed by `-dirty` if there were
any uncommitted changes when Flamenco was built.
In the tooltip of the 'evaluate now' button (the one with the Python
icon), include the description provided by the job type in its
`evalInfo.description` field. This makes it explicit what the button
will do when pressed.
Adjustment of the job settings property names, making them more widely
usable than just the 'use automatic values' button (also known as
'eval-on-submit').
The data is still the same, but the names of the properties have changed
a bit so that they're more generic, declarative, instead of specific to
one bit of functionality.
The goal is to have the `evalInfo.description` field usable for the
'evaluate now' button in the add-on as well. That way it should be
clearer what that does.
This commit just updates the OpenAPI definition.
Improve the usability of the 'eval-on-submit' toggle button:
- Add a placeholder text that can be shown instead of the input field. This
can be used to describe what the evaluated Python code will do. In the
case of the 'Simple Blender Render' job, this is set to 'Scene frame
range'.
- Change the way in which the job type has to declare this, both for
clarity and to add the extra placeholder string
Refactor the job settings. The `autoevalLockable` boolean is now
replaced with an `evalOnSubmit` nested object:
```
evalOnSubmit: {
showButton: true,
placeholder: "Scene frame range",
},
```
This makes it possible to add a placeholder text, and later maybe some
other parameters. The `showButton: true` part always has to be there, as
the entire feature is disabled with `showButton: false`, in which case
it's better to just remove the entire `evalOnSubmit` sub-object
altogether. Still, I think it's preferred to have that `showButton:
true` in there, as it makes it more explicit what this section of the
settings is for.
This commit just contains the OpenAPI definition.
Add a new job setting option `autoevalLockable`. Setting this to `true` in
the job compiler's `JOB_TYPE` settings has the following effect:
- By default, the setting will not be editable in Blender's job submission
interface. Instead, a toggle button with a 'car' icon will be shown.
- When the 'car' button is toggled off, the setting becomes editable again.
In its default, uneditable state, the setting will be auto-evaluated before
submission.
This makes it possible to 'lock in' auto-evaluation. The main use case is
for the frame range of the render job. By default this will be locked to
the scene frame range, but it can still be overridden if a different
range is wanted.
Add a new job setting option `autoevalLockable`. Setting this to `true` in
the job compiler's `JOB_TYPE` settings has the following effect:
- By default, the setting will not be editable in Blender's job submission
interface. Instead, a toggle button with a 'car' icon will be shown.
- When the 'car' button is toggled off, the setting becomes editable again.
In its default, uneditable state, the setting will be auto-evaluated before
submission.
This makes it possible to 'lock in' auto-evaluation. The main use case is
for the frame range of the render job. By default this will be locked to
the scene frame range, but it can still be overridden if a different
range is wanted.
This commit just contains the necessary OpenAPI change.
Configure auto-clrf for all text files. This should make it simpler to
develop Flamenco on Windows, as it makes Git depend less on its global
settings.
Due to an issue (which has been fixed in the previous commit), all tasks
in the database were deleted when starting Flamenco. This tool attempts
to recompile the job and recreate its tasks.
The statuses of the tasks are set based on the job status. Basically:
- job active → tasks queued
- job completed → tasks completed
- job cancelled / failed → tasks cancelled
- otherwise → tasks queued
To ensure that the tool is only used to create tasks from scratch, it
refuses to work on a job that still has tasks in the database.
There is an issue with the GORM auto-migration, in that it doesn't
always disable foreign key constraints when it should. Due to
limitations of SQLite, not all 'alter table' commands you'd want to use
are available. As a workaround, these steps are performed:
1. create a new table with the desired schema,
2. copy the data over,
3. drop the old table,
4. rename the new table to the old name.
Step #3 will wreak havoc with the database when foreign key constraint
checks are active, so no we temporarily deactivate them while performing
database migration.
