If Shaman is used to submit the job files, store the job's checkout ID
(i.e. the path relative to the checkout root) in the database. This will
make it possible in the future to remove the Shaman checkout along with
the job itself.
Job preparation (that is, constructing the data to be sent to the Flamenco
API) shouldn't fail, but in case it does, it should stop the rest of the
submission process.
Add support for Blender's `use_all_linked_data_direct` experimental
option. This is a workaround for an issue with BAT, for which a quick
solution is required by the Blender Studio (production crunch).
Flamenco writes the `.flamenco.blend` file with
`preferences.experimental.use_all_linked_data_direct` set to `True`, so
that BAT has an easier time finding linked assets.
If file has never been saved, Flamenco cannot create a temp copy to
submit. This caused an exception, which is now avoided by showing a
clear error message instead.
Maniphest Tasks: T102192
Differential Revision: https://developer.blender.org/D16358
BAT-packing is a multi-threaded operation, so messages about its progress
are queued up in a thread-safe manner. The modal operator was only handling
4 messages per second, causing major slowdowns when there are lots of
small files to be processed. This is now done much faster, and thus the
UI shouldn't lag behind of the actual submissions progress.
Before submitting a job, the add-on now checks the version of the Manager.
If this is not the same version of the add-on, a warning is shown and a
"Force Submit" button appears. This makes it both explicit that something
is iffy and still allows for pushing forward.
This is important when upgrading Flamenco, because I'm sure many people
will forget to actually redownload and reinstall the add-on.
Split the `comms.ping_manager()` function into two: one that returns the
version & config of the Manager, and the other that reports on it.
This will make it possible to do the former without the latter in certain
other situations where we want to refresh the manager info in the
background.
The etag prevents job submissions with old settings, when the job
compiler script has been edited. The etag is the SHA1 hash of the
`JOB_TYPE` dictionary (as defined by the JavaScript file). The hash is
computed in a way that's independent of the exact formatting in the
JavaScript file. Also the actual JS code itself is irrelevant, just the
`JOB_TYPE` dictionary is used.
Whenever the URL to Flamenco Manager is updated, check it and report.
This required moving the 'ping manager' code into a separate function, as
calling an operator from an RNA update callback is not a good idea.
Refactor the `FLAMENCO_OT_submit_job.poll()` function to actually use the
`job_types.active_job_type()` function instead of reimplementing similar
logic.
No functional changes.
When the to-be-submitted blend file is already stored in the shared
storage, and Shaman is disabled, the add-on now skips BAT-packing it.
Instead, the file is copied to `filename.flamenco.blend` and the path is
submitted as-is.
Manager always creates an implicit variable `{jobs}`. This used to be
Shaman-dependent, but now it's always there (has been for a while). This
is now reflected in an add-on comment, and in an extra unit test.
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.
This allows the Blender add-on to submit jobs at path
`{jobs}/path/file.blend`. Due to the nature of the system, the add-on
doesn't know (and shouldn't know) where exactly the Manager has its
Shaman storage.
- Addon switches between filesystem-packing and Shaman-packing
automatically, depending on whether the Manager has Shaman enabled.
- Actually using BAT for Shaman packing.
It doesn't work though, some error occurs when receiving Shaman response
from the Manager in the Addon.
Compute render output path when evaluating job settings, which is done
within the Flamenco add-on, instead of in the job compiler script. This
allows the UI to show the render path, rather than it only being known
after the job has been submitted.
The add-on code was copy-pasted from other addons and used the GPL v2
license, whereas by accident the LICENSE text file had the GNU "Affero" GPL
license v3 (instead of regular GPL v3).
This is now all streamlined, and all code is licensed as "GPL v3 or later".
Furthermore, the code comments just show a SPDX License Identifier
instead of an entire license block.
