Skip to content

docs: orchestrator documentation — providers, build services, cloud#1

Closed
frostebite wants to merge 2 commits intomainfrom
docs/orchestrator-documentation
Closed

docs: orchestrator documentation — providers, build services, cloud#1
frostebite wants to merge 2 commits intomainfrom
docs/orchestrator-documentation

Conversation

@frostebite
Copy link
Member

@frostebite frostebite commented Mar 10, 2026

Summary

Combined documentation for the standalone @game-ci/orchestrator package, updated to reflect the new architecture where orchestrator is a separate package loaded via unity-builder's plugin interface.

  • Provider Plugins — built-in providers, CLI provider protocol, dynamic loading, provider interface
  • Build Services — submodule profiles, local build caching, custom LFS transfer agents, git hooks
  • Cloud Providers — GCP Cloud Run and Azure ACI with multi-storage backends (experimental)

All docs updated to show both GitHub Action usage (via unity-builder) and standalone CLI usage.

Consolidates

Test plan

  • Verify all internal doc links resolve correctly
  • Verify code examples are accurate for standalone architecture

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Documentation
    • Added comprehensive guides for standalone build services (submodule profiles, variant overlays, local build caching, custom transfer agents, and Git hooks), plus examples for CLI and CI usage.
    • Added experimental cloud providers docs for serverless Unity builds with multiple storage backends and usage snippets.
    • Added provider plugins documentation with configuration, dynamic loading, and streaming output examples.
  • New Features
    • Exposed several enterprise-facing services via the public API for build, cache, submodule, LFS and hooks workflows.

Consolidates documentation from individual unity-builder PRs into the
standalone orchestrator repository. Updated to reflect the standalone
package architecture with both Action and CLI usage examples.

Consolidates:
- game-ci/unity-builder#780 (CLI provider protocol and provider plugin system)
- game-ci/unity-builder#781 (submodule profiles, local caching, LFS agents, git hooks)
- game-ci/unity-builder#782 (GCP Cloud Run and Azure ACI with multi-storage backends)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@coderabbitai
Copy link

coderabbitai bot commented Mar 10, 2026

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: b4afa238-067c-4857-b4e1-ed5b9b727b73

📥 Commits

Reviewing files that changed from the base of the PR and between b7f269a and 60ebf55.

📒 Files selected for processing (1)
  • src/index.ts

📝 Walkthrough

Walkthrough

Adds three new documentation pages for build services, cloud providers, and provider plugins, and exposes five lazy-loaded enterprise service exports from the public API surface.

Changes

Cohort / File(s) Summary
Documentation — Build & Providers
docs/build-services.md, docs/cloud-providers.md, docs/provider-plugins.md
Adds three new docs describing standalone build services integration, experimental cloud providers (GCP Cloud Run Jobs, Azure Container Instances), provider plugin architecture, configuration options, storage backends, inputs, usage examples (GitHub Actions/CLI), and references.
Public API Exports
src/index.ts
Adds five new exported service entries to the public API surface: ChildWorkspaceService, LocalCacheService, SubmoduleProfileService, LfsAgentService, and GitHooksService (lazy-loaded via plugin interface).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I bound through pages, nibbling text with glee,
New services, clouds, and plugins for all to see,
Exports unwrapped, docs freshly sown,
A carrot of features — hop, build, and roam! 🥕

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately reflects the main change: adding comprehensive orchestrator documentation covering the three primary topics (providers/plugins, build services, and cloud providers) that are the core content of this PR.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch docs/orchestrator-documentation

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/build-services.md`:
- Around line 61-76: Docs reference a localCacheRoot input but the input model
(src/model/build-parameters.ts, the BuildParameters interface / parseInputs
logic around lines ~78-134) does not define or parse localCacheRoot; either add
localCacheRoot to the input model or remove it from the docs. Fix by extending
the BuildParameters type and the input parsing/validation code to include a
localCacheRoot field (with the same default/precedence behavior used in docs)
and ensure CLI/Action parsing reads it, or update docs/examples to stop
mentioning localCacheRoot if intentionally unsupported; reference the
BuildParameters interface and the parseInputs (or equivalent input parsing)
function in src/model/build-parameters.ts when implementing the change.
- Around line 103-108: The fenced code block in docs/build-services.md that
shows the git config commands (the lines starting with "git config
lfs.customtransfer.{name}.path", "git config lfs.customtransfer.{name}.args",
and "git config lfs.standalonetransferagent {name}") needs a language tag;
update the opening triple-backtick fence to ```bash so the block is explicitly
tagged as bash for linting and syntax highlighting.

In `@docs/cloud-providers.md`:
- Around line 41-50: The docs entry for gcpDiskSizeGb contradicts itself
(default 100 vs description "in-memory volume size (for in-memory, max 32)");
fix it by aligning the table with the actual validation used by the GCP Cloud
Run provider: examine the gcp-cloud-run provider code path that validates
gcpDiskSizeGb (the function/constant in that provider which enforces the max 32
in-memory rule) and either set the "Default" column to a valid default within
that range (e.g., 32) or update the description to reflect that larger defaults
are accepted if the provider allows 100; ensure the scope ("in-memory") and the
valid range match the provider validation and update the table cell for
gcpDiskSizeGb accordingly.

In `@docs/provider-plugins.md`:
- Around line 25-32: The fenced code block under the "Protocol" header is
missing a language tag which triggers docs lint MD040; update that block (the
triple-backtick fence containing "Invocation:  <executable> <subcommand>" etc.)
to include a language tag such as text (i.e., change ``` to ```text) so the
linter accepts the non-executable snippet.
- Around line 147-160: Update the docs so the ProviderInterface section matches
the real contract: state that the TypeScript ProviderInterface applies to
dynamic TS providers (CLI providers expose equivalent subcommands instead), and
update the method signatures to use the real parameter name defaultSecretsArray
for setupWorkflow and cleanupWorkflow (referencing ProviderInterface,
setupWorkflow, cleanupWorkflow, defaultSecretsArray); ensure runTaskInWorkflow
and other method names remain unchanged and the doc text clarifies the CLI vs TS
provider shape difference.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 6f90cc4d-8df9-4183-bd8f-76550db37115

📥 Commits

Reviewing files that changed from the base of the PR and between d1b91a9 and b7f269a.

📒 Files selected for processing (3)
  • docs/build-services.md
  • docs/cloud-providers.md
  • docs/provider-plugins.md

Comment on lines +61 to +76
### How it works

- Cache key: `{platform}-{version}-{branch}` (sanitized)
- Cache root: `localCacheRoot` > `$RUNNER_TEMP/game-ci-cache` > `.game-ci/cache`
- On restore: extracts `library-{key}.tar` / `lfs-{key}.tar` if they exist
- On save: creates tar archives of the Library and LFS folders
- Garbage collection removes cache entries that haven't been accessed recently

### Inputs

| Input | Default | Description |
|-------|---------|-------------|
| `localCacheEnabled` | `false` | Enable filesystem caching |
| `localCacheRoot` | — | Cache directory override |
| `localCacheLibrary` | `true` | Cache Unity Library folder |
| `localCacheLfs` | `true` | Cache LFS objects |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

localCacheRoot looks unsupported by the current inputs model.

This section documents localCacheRoot as an accepted input and even makes it part of the cache-root precedence, but src/model/build-parameters.ts:78-134 only shows localCacheEnabled, localCacheLibrary, and localCacheLfs for local caching. If localCacheRoot is not parsed anywhere else, the table and the CLI/Action examples below are misleading.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/build-services.md` around lines 61 - 76, Docs reference a localCacheRoot
input but the input model (src/model/build-parameters.ts, the BuildParameters
interface / parseInputs logic around lines ~78-134) does not define or parse
localCacheRoot; either add localCacheRoot to the input model or remove it from
the docs. Fix by extending the BuildParameters type and the input
parsing/validation code to include a localCacheRoot field (with the same
default/precedence behavior used in docs) and ensure CLI/Action parsing reads
it, or update docs/examples to stop mentioning localCacheRoot if intentionally
unsupported; reference the BuildParameters interface and the parseInputs (or
equivalent input parsing) function in src/model/build-parameters.ts when
implementing the change.

Comment on lines +103 to +108
Configures git to use a custom transfer agent via:
```
git config lfs.customtransfer.{name}.path <executable>
git config lfs.customtransfer.{name}.args <args>
git config lfs.standalonetransferagent {name}
```
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Tag this fenced block as bash.

It is currently an unlabeled code fence, which is a docs-lint failure waiting to happen.

📝 Suggested doc fix
-```
+```bash
 git config lfs.customtransfer.{name}.path <executable>
 git config lfs.customtransfer.{name}.args <args>
 git config lfs.standalonetransferagent {name}
</details>

<!-- suggestion_start -->

<details>
<summary>📝 Committable suggestion</summary>

> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

```suggestion
Configures git to use a custom transfer agent via:
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/build-services.md` around lines 103 - 108, The fenced code block in
docs/build-services.md that shows the git config commands (the lines starting
with "git config lfs.customtransfer.{name}.path", "git config
lfs.customtransfer.{name}.args", and "git config lfs.standalonetransferagent
{name}") needs a language tag; update the opening triple-backtick fence to
```bash so the block is explicitly tagged as bash for linting and syntax
highlighting.

Comment on lines +41 to +50
| Input | Default | Description |
|-------|---------|-------------|
| `gcpProject` | `$GOOGLE_CLOUD_PROJECT` | GCP project ID |
| `gcpRegion` | `us-central1` | Cloud Run region |
| `gcpStorageType` | `gcs-fuse` | Storage backend (see above) |
| `gcpBucket` | — | GCS bucket name (for gcs-fuse, gcs-copy) |
| `gcpFilestoreIp` | — | Filestore IP address (for nfs) |
| `gcpFilestoreShare` | `/share1` | Filestore share name (for nfs) |
| `gcpMachineType` | `e2-standard-4` | Machine type |
| `gcpDiskSizeGb` | `100` | In-memory volume size (for in-memory, max 32) |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Clarify gcpDiskSizeGb; the default and description contradict each other.

The table says the default is 100, but the description says this is the in-memory volume size with a max of 32. Those two statements cannot both be true. Please align the description, scope, and valid range with src/model/orchestrator/providers/gcp-cloud-run/index.ts:53-65 before merging, otherwise users do not know what values are actually valid.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/cloud-providers.md` around lines 41 - 50, The docs entry for
gcpDiskSizeGb contradicts itself (default 100 vs description "in-memory volume
size (for in-memory, max 32)"); fix it by aligning the table with the actual
validation used by the GCP Cloud Run provider: examine the gcp-cloud-run
provider code path that validates gcpDiskSizeGb (the function/constant in that
provider which enforces the max 32 in-memory rule) and either set the "Default"
column to a valid default within that range (e.g., 32) or update the description
to reflect that larger defaults are accepted if the provider allows 100; ensure
the scope ("in-memory") and the valid range match the provider validation and
update the table cell for gcpDiskSizeGb accordingly.

Comment on lines +25 to +32
### Protocol

```
Invocation: <executable> <subcommand>
Input: JSON on stdin
Output: JSON on stdout
Errors: stderr forwarded to orchestrator logs
```
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Add a language tag to this fenced block.

This trips MD040 in docs lint. Use text here if you want to keep it non-executable.

📝 Suggested doc fix
-```
+```text
 Invocation:  <executable> <subcommand>
 Input:       JSON on stdin
 Output:      JSON on stdout
 Errors:      stderr forwarded to orchestrator logs
</details>

<!-- suggestion_start -->

<details>
<summary>📝 Committable suggestion</summary>

> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

```suggestion
### Protocol

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/provider-plugins.md` around lines 25 - 32, The fenced code block under
the "Protocol" header is missing a language tag which triggers docs lint MD040;
update that block (the triple-backtick fence containing "Invocation: 
<executable> <subcommand>" etc.) to include a language tag such as text (i.e.,
change ``` to ```text) so the linter accepts the non-executable snippet.

Comment on lines +147 to +160
## Provider Interface

All providers (built-in, CLI, or dynamic) implement the same 7-method interface:

```typescript
interface ProviderInterface {
setupWorkflow(buildGuid, buildParameters, branchName, secrets): any;
runTaskInWorkflow(buildGuid, image, commands, mountdir, workingdir, environment, secrets): Promise<string>;
cleanupWorkflow(buildParameters, branchName, secrets): any;
garbageCollect(filter, previewOnly, olderThan, fullCache, baseDependencies): Promise<string>;
listResources(): Promise<ProviderResource[]>;
listWorkflow(): Promise<ProviderWorkflow[]>;
watchWorkflow(): Promise<string>;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Make this interface section match the real contract.

This section currently implies that CLI providers implement the TypeScript ProviderInterface directly, and the sample signatures for setupWorkflow / cleanupWorkflow do not match src/model/orchestrator/providers/provider-interface.ts:7-32 (defaultSecretsArray is part of the real contract). Anyone copying this into a TS provider will get the wrong shape. Tighten this to dynamic providers, or explicitly say CLI providers expose equivalent subcommands instead of the TS interface.

📝 Suggested doc fix
-## Provider Interface
-
-All providers (built-in, CLI, or dynamic) implement the same 7-method interface:
+## Provider Interface
+
+Dynamic providers loaded from a package/path must export a class that implements the TypeScript `ProviderInterface`. CLI providers expose equivalent operations through the CLI subcommands above.
 
 ```typescript
 interface ProviderInterface {
-  setupWorkflow(buildGuid, buildParameters, branchName, secrets): any;
+  setupWorkflow(buildGuid, buildParameters, branchName, defaultSecretsArray): any;
   runTaskInWorkflow(buildGuid, image, commands, mountdir, workingdir, environment, secrets): Promise<string>;
-  cleanupWorkflow(buildParameters, branchName, secrets): any;
+  cleanupWorkflow(buildParameters, branchName, defaultSecretsArray): any;
   garbageCollect(filter, previewOnly, olderThan, fullCache, baseDependencies): Promise<string>;
   listResources(): Promise<ProviderResource[]>;
   listWorkflow(): Promise<ProviderWorkflow[]>;
   watchWorkflow(): Promise<string>;
 }
</details>

<!-- suggestion_start -->

<details>
<summary>📝 Committable suggestion</summary>

> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

```suggestion
## Provider Interface

Dynamic providers loaded from a package/path must export a class that implements the TypeScript `ProviderInterface`. CLI providers expose equivalent operations through the CLI subcommands above.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/provider-plugins.md` around lines 147 - 160, Update the docs so the
ProviderInterface section matches the real contract: state that the TypeScript
ProviderInterface applies to dynamic TS providers (CLI providers expose
equivalent subcommands instead), and update the method signatures to use the
real parameter name defaultSecretsArray for setupWorkflow and cleanupWorkflow
(referencing ProviderInterface, setupWorkflow, cleanupWorkflow,
defaultSecretsArray); ensure runTaskInWorkflow and other method names remain
unchanged and the doc text clarifies the CLI vs TS provider shape difference.

Adds missing exports for ChildWorkspaceService, LocalCacheService,
SubmoduleProfileService, LfsAgentService, and GitHooksService.
These are required by unity-builder's plugin interface (loadEnterpriseServices).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@frostebite
Copy link
Member Author

Closing — documentation should go in game-ci/documentation repo instead, not a docs folder here.

@frostebite frostebite closed this Mar 10, 2026
@frostebite frostebite deleted the docs/orchestrator-documentation branch March 10, 2026 06:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant