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.
Replace the Vue v2 webapp with a Vue v3 one, and embed the OpenAPI
client in the webapp itself (instead of being its own npm project).
- Vue v2.x -> v3.x
- Tabulator v4.x -> v5.1
- Moment JS -> replaced with Luxon JS
- Vue CLI/UI -> replaced with Vite
This adds a JS client for the OAPI interface, and introduces the SocketIO
stuff into Flamenco Manager itself.
To build & run:
- in `web/manager-api` run `npm install`
- in `web/manager-api` run `npm link`
- in `web/app` run `npm install`
- in `web/app` run `npm link flamenco-manager`
- in `web/app` run `yarn serve`
This may not be a complete list, but at least some of those steps are
necessary.
Instead of having the Python code generator as a separate shell script,
include it in the Makefile. There are now three make targets:
- generate-go: only generate Go code, for the Worker & Manager
- generate-py: only generate Python code, for the Blender add-on
- generate: run both
Generated code is to be committed to Git anyway, so there is no need to
regenerate it on every build.
The code can be regenerated explicitly by running `make generate`.
Git wants to see native line-ends in source files, but the code generators
we use always write UNIX line-ends. `make generate` on Windows now passes
generated files through `unix2dos`. This allows regenerating files without
Git listing them as modified.
The Makefile started as a standard file I use for multiple Go projects,
but it was aimed at having only one executable to build. I've removed
everything that assumes a single executable, and kept the parts that are
actually used now.
The build chain got a bit confused when doing things from scratch, as
`test_support.go` was used in the non-test builds. Renaming it to
`support_test.go` was the easiest way to avoid that.
