The `require.XXX` functions are exactly the same as `assert.XXX`
functions + directly failing the test, so this refactor simplifies the
code quite a bit. Can be done in more areas than this.
No functional changes.
Simple Blender Render now no longer renders to an intermediate directory.
This not only simplifies the script, but it also opens the door for
selective re-running of individual tasks.
In the old situation, where the intermediate directory was renamed to
the desired name in the last task, rerunning tasks would fail because the
directory they expect to exist no longer exists. This is now resolved.
The original idea behind this job type was that it would work equally
well for videos as for images, but that was never really well tested.
It's currently broken, so this commit removes video support altogether.
Remove the `blender_cmd` setting, and just hard-code it to `{blender}`.
The Blender add-on was already passing this string, and it's very unlikely
that people are already writing custom add-ons to pass something different.
It provided flexibility that was untested, so it's better to simplify
things.
The example on the project website is incorrect:
```
task_types: blender, ffmpeg, file-management, misc
```
It results in an error:
```
loading configuration: yaml: unmarshal errors:\n line 2:
cannot unmarshal ||str "blender..." into []string
```
The fix seems to be adding square brackets around the list of comma
delineated tasks:
```
task_types: [blender, ffmpeg, file-management, misc]
```
This results in output with the confirmation that
`taskType=["blender","ffmpeg","file-management","misc"]`
`make update-version` now also updates
`web/project-website/data/flamenco.yaml` so that the new version is
listed as the latest one on flamenco.blender.org.
Note that such a change will only be visible online after publishing the
site with `make project-website`. Be sure to only do this after the
build has been uploaded there, to avoid dead links.
In the case where the current git HEAD matches the latest release tag,
the version reported by Flamenco was something like
`3.0-beta2-3.0-beta2`, where the first is `$VERSION` and the other is
`$GITHASH`.
This is now prevented, and `$GITHASH` will always be something that's
not a repeat of `$VERSION`.
Implement the `getSharedStorage` operation in the Manager, and use it in
the add-on to get the shared storage location in a way that makes sense
for the platform of the user.
Manifest task: T100196
This variable is used in tests to mock the current OS, but wasn't set
during normal operation of the Manager. This caused issues with the
two-way variable system.
Add an operation `getSharedStorage` that can return the shared storage
location, adjusted for the given audience & platform. This uses the
two-way variables system to adjust the Manager's configuration.
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.
Include a `shortversion` property in the `FlamencoVersion` schema, which
will just be the version number with the release phase (and not the git
hash, the number of commits since the last tag, and the `-dirty` suffix).
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.
This is now only written for Debian/Ubuntu and Windows, and not for other
Linux flavours or macOS. Also the Windows documentation is very minimal,
but at least contains the info I always tend to forget.
Split "executable" from "its arguments" in blender & ffmpeg commands.
Use `{blenderArgs}` variable to hold the default Blender arguments,
instead of having both the executable and its arguments in `{blender}`.
The reason for this is to support backslashes in the Blender executable
path. These were interpreted as escape characters by the shell lexer.
The shell lexer based splitting is now only performed on the default
arguments, with the result that `C:\Program Files\Blender
Foundation\3.3\blender.exe` is now a valid value for `{blender}`.
This does mean that this is backward incompatible change, and that it
requires setting up Flamenco Manager again, and that older jobs will not
be able to be rerun.
It is recommended to remove `flamenco-manager.yaml`, restart Flamenco
Manager, and reconfigure via the setup assistant.
There are Flamenco "commands" and CLI "commands", and it's nice to be
explicit about which is which. I'm sure this is needed in some other
areas as well.
Don't change backslashes to forward slashes on Windows. Trying to use
forward slashes everywhere was a mistake, and this is one of the steps to
make it right.
