twotalesanimation
7f066c1372
Deploy / deploy (push) Successful in 7m28s
A formal review is shared as a flat, dated folder of the preview MOVs —
{deliveryRoot}/PRODUCER_REVIEWS/20260828_Producer_review, then _02, _03
for further reviews the same day. It reuses the delivery package's
machinery end to end: DeliveryPackage/DeliveryItem, the DELIVERY_BUILD
job, the same claim path and the same hardlink-or-copy builder, with
DeliveryPackage.kind telling the two apart.
Three things separate a review from a delivery:
A review never advances an Export. Reviews happen throughout a shot's
life, long before QC passes it, and the same version is routinely shown
twice — so nothing is marked PACKAGED, and markDelivered() refuses a
review package outright (the button is hidden too).
Selection is by shot, not by export. Shot Status → Bulk Actions → Build
MOV Review Package; the server resolves each shot to its newest export
that actually has a deliveryMovPath, which is not always its newest
export — a shot whose latest version is still rendering belongs in the
review as the version that can be watched. Shots with no MOV at all are
listed in the confirm dialog with the reason rather than silently
shrinking the folder.
The folder is exactly the MOVs. No CSV, no manifest.json written beside
them; the manifest still returns to the server, so the record of what was
shared is kept without cluttering the share. Names follow the same
client-naming rule as a delivery, so a shot reads identically in a review
folder and in the delivery that follows it.
Verification (DeliveryStage.BuildReviewItem) is proportional as it is for
EXRs, adapted to a single file with no validation-time digest: a hard
link is the source and needs nothing, a copy is checked against its
source by length always and by full hash under "always-hash". A missing
MOV fails the item here — in an EXR delivery the MOV is a viewing copy
beside the real deliverable, but in a review it is the deliverable, and a
review folder quietly one shot short is worse than one that says so.
Worker bumped to 1.6.0 for the new manifest field (DeliveryManifest.Kind).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
45 lines
1.8 KiB
XML
45 lines
1.8 KiB
XML
<Project Sdk="Microsoft.NET.Sdk.Worker">
|
|
|
|
<PropertyGroup>
|
|
<TargetFramework>net8.0</TargetFramework>
|
|
<Nullable>enable</Nullable>
|
|
<ImplicitUsings>enable</ImplicitUsings>
|
|
<RootNamespace>VFXReviewWorker</RootNamespace>
|
|
<AssemblyName>VFXReviewWorker</AssemblyName>
|
|
<!-- Single self-contained exe for render nodes: dotnet publish -r win-x64 (see README) -->
|
|
<InvariantGlobalization>true</InvariantGlobalization>
|
|
<!--
|
|
The version is a property of the build, not of the machine it lands on:
|
|
it is stamped here and read back from the assembly at runtime, so a
|
|
workstation cannot report a version it is not actually running. Bump on
|
|
every change that gets published. publish.ps1 appends the git SHA via
|
|
SourceRevisionId, giving "1.1.0+feb1c7b".
|
|
-->
|
|
<Version>1.6.0</Version>
|
|
</PropertyGroup>
|
|
|
|
<ItemGroup>
|
|
<PackageReference Include="Microsoft.Extensions.Hosting" Version="8.0.1" />
|
|
<PackageReference Include="Microsoft.Extensions.Hosting.WindowsServices" Version="8.0.1" />
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<InternalsVisibleTo Include="VFXReviewWorker.Tests" />
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<!--
|
|
Headless AE build script ships beside the exe. CopyToPublishDirectory is
|
|
set explicitly: CopyToOutputDirectory alone governs the build folder, and
|
|
an incremental publish then leaves the script out of a freshly-cleaned
|
|
publish directory. publish.ps1 copies it again and verifies, because the
|
|
exe cannot run a preview job without it.
|
|
-->
|
|
<Content Include="..\scripts\vfxr_build_preview.jsx" Link="scripts\vfxr_build_preview.jsx">
|
|
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
|
|
<CopyToPublishDirectory>Always</CopyToPublishDirectory>
|
|
</Content>
|
|
</ItemGroup>
|
|
|
|
</Project>
|