This commit does not introduce functional changes, besides renaming
every mention of 'wizard' with 'setup assistant'. In order to run the
manager setup assistant use:
./flamenco-manager -setup-assistant
The change was introduced to favor more neutral and descriptive working
for this functionality. Thanks to Sybren for helping to get this done!
Logging the URLs at which the Manager can be reached as the last thing
when starting up, in the hope that this makes them more noticable and
inviting to actually visit.
Add Makefile target for building release packages. There are individual
targets `release-package-{linux,darwin,windows}` for specific OSses. The
`release-package` targets just runs all of them.
The `release-package-darwin` builds only for AMD64/x64 CPUs, since there
are no static builds fo FFmpeg for that platform:
https://evermeet.cx/ffmpeg/apple-silicon-arm
Manifest Task: T99411
Flamenco now no longer uses the Git tags + hash for the application
version, but an explicit `VERSION` variable in the `Makefile`.
After changing the `VERSION` variable in the `Makefile`, run
`make update-version`.
Not every part of Flamenco looks at this variable, though. Most
importantly: the Blender add-on needs special handling, because that
doesn't just take a version string but a tuple of integers. Running
`make update-version` updates the add-on's `bl_info` dict with the new
version. If the version has any `-blabla` suffix (like `3.0-beta0`) it
will also set the `warning` field to explain that it's not a stable
release.
The OpenAPI generator is very noisy, so it now logs to a file instead
of to stdout. The file is git-ignored. This was easier than redirecting
to `/dev/null`, as that's not available on Windows.
Earlier versions of the code didn't have proper separation of SQLite
databases for the unit tests. Tests nowadays use separate in-memory
databases, so they can run in parallel just fine.
The flamenco.io website moves to flamenco.blender.org!
This commit updates the Makefile as follows:
- Rename 'site' to 'project-website', so the new command to deploy is
'make project-website'
- Move the website directory from 'flamenco-io-site' to
'project-website'
- Update the rsync command do reflect the new deployment destination
Shaman cannot handle cases where the storage path is a symlink (i.e. cases
where `filepath.EvalSymlinks(storagePath)` does not return `storagePath`).
This caused macOS devices to fail the unit tests, because macOS uses a
symlinked path for temporary files.
This commit changes the unit tests, to always use the real path instead of
the OS-provided symlink. This does *not* fix the actual issue in Shaman,
for that see T99965.
Increase verbosity (debug → info) when checkout dir traversal fails, and
add a trace-level log for each file that is still in use. There were some
issues with symlinks, where the wrong paths were compared (see T99965) and
this log made it visible what was going wrong.
Four Makefile targets have been added:
- `tools`, which evokes the other three
- `tools-linux`, `tools-darwin`, `tools-windows`, download FFmpeg and put
the `ffmpeg` executables into `./tools/ffmpeg-{OS}-{ARCH}`.
Downloaded tarball/ZIP files are stored in `tools/download`, and won't be
re-downloaded if they already exist.
Remove the `{ffmpeg}` variable from the default configuration, and its use
from the job compiler scripts. Now that the Worker can find its bundled
FFmpeg, it's no longer needed to configure its location on the Manager.
Worker will now try one of the following paths, relative to the flamenco-worker
executable, in order to find FFmpeg. If they cannot be found, `$PATH` is
searched for FFmpeg.
- `tools/ffmpeg-$GOOS-$GOARCH`
- `tools/ffmpeg-$GOOS`
- `tools/ffmpeg`
On Windows these paths will have a `.exe` suffix appended. `$GOOS` is the
operating system, like "linux", "darwin", "windows", etc. `$GOARCH` is the
architecture, like "amd64", "386", etc.
By accident I made the worker load `flamenco-worker.yaml` from the "local
files" directory (~/.local/share/flamenco on Linux) instead of the current
directory. This was incorrect, as that file is meant to contain
configuration that's shared between workers.
* Replace "OK!" with "successfully"
Remove exclamation mark since there is no need to call for attention.
Use "successfully" as it is more descriptive in this case than OK,
which can have other meanings.
* Try to be more descriptive by mentioning "executable", not just Path.
* Rename field placeholder "Blender Path" to "Path to Blender executable".
* Try to shorten certain lines while maintaining clarity.
* Use colons when appropriate.
