The data is still the same, but the names of the properties have changed
a bit so that they're more generic, declarative, instead of specific to
one bit of functionality.
The goal is to have the `evalInfo.description` field usable for the
'evaluate now' button in the add-on as well. That way it should be
clearer what that does.
This commit just updates the OpenAPI definition.
Refactor the job settings. The `autoevalLockable` boolean is now
replaced with an `evalOnSubmit` nested object:
```
evalOnSubmit: {
showButton: true,
placeholder: "Scene frame range",
},
```
This makes it possible to add a placeholder text, and later maybe some
other parameters. The `showButton: true` part always has to be there, as
the entire feature is disabled with `showButton: false`, in which case
it's better to just remove the entire `evalOnSubmit` sub-object
altogether. Still, I think it's preferred to have that `showButton:
true` in there, as it makes it more explicit what this section of the
settings is for.
This commit just contains the OpenAPI definition.
Add a new job setting option `autoevalLockable`. Setting this to `true` in
the job compiler's `JOB_TYPE` settings has the following effect:
- By default, the setting will not be editable in Blender's job submission
interface. Instead, a toggle button with a 'car' icon will be shown.
- When the 'car' button is toggled off, the setting becomes editable again.
In its default, uneditable state, the setting will be auto-evaluated before
submission.
This makes it possible to 'lock in' auto-evaluation. The main use case is
for the frame range of the render job. By default this will be locked to
the scene frame range, but it can still be overridden if a different
range is wanted.
This commit just contains the necessary OpenAPI change.
Make it explicit that the `version` property is for human consumption.
Also add a new `git` property so that all info from `version` is also
included in separate fields for machine consumption.
Remove the following statuses from `flamenco-openapi.yaml`:
- 'construction-failed'
- 'archiving'
- 'archived'
These were a leftover from Flamenco v2 and have never been used in
Flamenco v3.
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104215
Clusters can be created without UUID now. In that case, a random one will
be generated. The cluster will be returned by the creation call, so that
the caller can know that generated UUID.
Worker Clusters can be managed via the API, workers can be assigned to
any number of clusters (if not assigned to any, they'll pick up any task).
Jobs can be submitted with a cluster ID, in which case only workers that
are in that cluster or are clusterless will pick up its tasks.
Add a "what-would-delete-do" operation, to query the Manager about what
the deletion of a specific job would entail. For some jobs the job files
will also be deleted (if they were created with a new enough Flamenco),
otherwise they will remain untouched.
Also expand the `SocketIOJobUpdate` schema to include info about job
deletion.
Add fields to the job schemas (`SubmittedJob` and `Job`) to allow
storing the shaman checkout ID (so the Shaman checkout can be deleted
along with the job later).
Add an endpoint that mimicks the job submission endpoint, to see whether
the job survives the job compiler script. This can be used to fail early,
before actually sending files to the farm.
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.
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).
This will remove a worker by soft-deletion. Any task still assigned to
the worker will be requeued.
Note that this removal should only happen when the worker is offline, or
it will cause errors on the worker as its credentials will not be
accepted any more.
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.
The submitter's platform is used to perform two-way variable
replacement. The variables of that submitter's platform are looked up,
and their values are replaced with the variable names. This only applies
to the job's settings and metadata, and is only performed on prefixes.
For example, if the submitter's platform has a variable
`render = /shared/frames`, a job setting
`output = "/shared/frames/shot123"` will be stored as
`output = "{render}/shot123".
When a Worker gets a task of this job, `{render}` will be expanded to
the value appropriate for their platform, hence the "two-way" name.
Add examples to the `WorkerSignOn` and `WorkerStateChanged` schemas.
These will make it easier to test with SwaggerUI, as they reflect a worker
signing on with the default task types.
Change the `FlamencoVersion` schema definition so that it follows the style
of the other schema definitions:
- List properties before mentioning which are required.
- Put quotes around the property names, so that they stand out from the
other YAML keys.
