Build Pipeline Orchestrator

Unity build pipeline orchestration on Temporal and .NET 8: validate the project, fan out to platform builds in parallel, fan back in to a report. Running Unity several times over on one machine is the awkward part, because the licence and the Library folder both assume a single instance, so each build gets a cheap read-only copy of the project to work against. It ships with architecture decision records covering retry strategy, observability, graceful cancellation and project-copy strategy, and a simulation mode so the whole thing runs without Unity installed.

• Temporal workflows model the pipeline as durable state: validation, fan-out to parallel platform builds, then fan-in to a report.
• Each parallel build points at its own copy of the project rather than the original, so several Unity instances can run on one machine without contending over the same Library folder or licence.
• The copy duplicates only the directories Unity actually needs, read-only, which keeps it cheap enough to do per build rather than once per pipeline.
• Architecture decision records document retry strategy, observability, simulation mode, graceful cancellation and project-copy strategy.
• A simulation mode runs the orchestration end to end with no Unity installation, so the logic can be exercised anywhere.
• Mermaid architecture and sequence diagrams, and a justfile collecting every command in one place.

• Temporal instead of hand-rolled retry logic

  Builds are long, flaky and expensive to repeat. Durable execution gives retries, cancellation and visibility as properties of the platform rather than code I have to maintain.

• Simulation mode as a first-class feature

  Needing a Unity licence to test orchestration logic would have made the feedback loop painfully slow and the project impossible for anyone else to review. Simulating the build step decoupled the two entirely.

• Duplicate the project instead of serialising the builds

  Unity does not expect to be run several times over one project on one machine: the licence and the Library folder both assume a single instance. Serialising the builds would have made the parallel fan-out pointless, so each build gets its own read-only duplicate of just the directories Unity needs. That copy is quick, and the instances stop fighting each other.

• ADRs over a longer README

  Writing down the rejected options forced me to actually have reasons for the chosen one. Several decisions changed while I was writing the record for them.

The ADRs turned out to be the most useful thing in the repository, which was not what I expected when I started writing them. A README tells you what a system does. An ADR tells you which options were rejected and why, and that is the part you cannot reconstruct six months later. The other surprise was where the real problem lived: not in the orchestration, which Temporal largely handles, but in Unity's assumption that only one copy of it runs at a time. I did not get the role, but a week inside Unity's build tooling and its licensing model was worth having regardless.