FFmpeg was put in the wrong location in the release packages for Linux and
macOS. It should have been in a subdirectory called `tools` so that the
Worker finds it, but it was in the top-level directory of the package.
This is now fixed.
`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`.
`git describe --dirty --always` will produce a hash in the form
`{most recent tag}-{commits since that tag}-{hash}` with a `-dirty` suffix
when there are uncommitted changes. Since the app version and the most
recent tag already overlap, the app version is removed from the git hash
to avoid overly long hashes. They are now of the form `{commits since last
tag}-{hash}`.
Change path inside the Linux and macOS tarballs, so that they contain an
embedded `flamenco-3.x.y-xxxx/` directory with all the files (instead of
putting all the files in the root of the tarball).
`make publish-release-packages` uploads the release packages for the
current version of Flamenco. Note that it does NOT build those, so run
`make release-packages` beforehand.
Include `RELEASE_CYCLE` in the Makefile. This is mentioned at startup of
Manager and Worker, and reflects in the software version they report.
If `RELEASE_CYCLE == "release"`, Manager and Worker report their version
as `ApplicationVersion`. If it's any other string, the Git hash will get
appended.
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
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.
The generators always produce UNIX line-ends. This creates false file
modifications with Git on Windows. Convert them to DOS line-ends to avoid
this.
This was already done for the Go code; this commit just copies the approach
to the Python and JavaScript generators.
Build with `make stresser`. Run with:
./stresser -worker UUID -secret ABCXYZ
The worker ID and secret can be obtained from
`flamenco-worker-credentials.yaml`. If left empty, the stresser will
register as a new worker, and log the credentials to be used on the next
invocation.
This of course needs SSH access to the flamenco.io website.
Run `hugo --serve` from the `web/flamenco-io-site` directory to simply
run an in-memory copy of the site, and browse it locally at
http://localhost:1313/
Vue Router generates URLs for which there are no static files on the
filesystem (like `/jobs/{job ID}`). To make this work, the webapp's
`index.html` has to be served for such requests. The client-side JavaScript
then figures out how things fit together, and can even render a nice 404
page if necessary.
This shouldn't happen for non-webapp URLs, though. Because of this, the
entire webapp (including the "serve `index.html` if file not found logic)
is moved to a `/app/` base URL.
`make flamenco-manager` now also builds the webapp and embeds the static
files into the binary.
`make flamenco-manager_race` does NOT rebuild the static web files, to
help speed up of debug cycles. Run `make webapp-static` to rebuild the
webapp itself, if necessary, or run a separate web development server with
`yarn --cwd web/app run dev --host`.
Rename `pkg/api/flamenco-manager.yaml` to `flamenco-openapi.yaml`, to
distinguish the OpenAPI definition file from the Flamenco Manager
configuration file of the same name (but in a different directory).
No functional changes.
Regenerating code with `make clean` was somewhat useful when only Go code
was generated, because that didn't include the version number / git hash.
The Python and JS code do have that version/hash, so `make clean` became
a source-altering operation, which wasn't nice.
The version number used in the OpenAPI-generated code shouldn't contain
the `-dirty` suffix. In the common development workflow, those files
will always be dirty; because they're only committed after things are
locally working, the implementation has already been written.
