Document public CLI and clarify Orchestrator positioning#559
Document public CLI and clarify Orchestrator positioning#559frostebite merged 6 commits intomainfrom
Conversation
|
|
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (13)
📝 WalkthroughWalkthroughReworks Orchestrator docs to present a two-layer model (Standard GameCI + Orchestrator), consolidates incremental-sync content into the hot-runner protocol, and adds/rewrites comprehensive public GameCI CLI documentation (install, build, remote builds, plugins) and many cross-reference updates. ChangesOrchestrator Positioning & Hot-Runner Consolidation
Public GameCI CLI & Plugin Documentation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~28 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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. Comment |
|
Visit the preview URL for this PR (updated for commit 9bbb196): https://game-ci-5559f--pr559-docs-public-cli-orch-1ochl50o.web.app (expires Wed, 13 May 2026 15:14:27 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 1f0574f15f83e11bfc148eae8646486a6d0e078b |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/01-command-line.mdx (1)
58-76: ⚡ Quick winClarify command invocation for maintenance commands.
The section header states these commands are "available only on the standalone Orchestrator CLI," but the examples show
game-cicommands without the--pluginflag or any indication they're using the standalone CLI. This could confuse users about:
- Whether these commands work with the public
game-ciCLI- Whether they require the Orchestrator plugin
- Whether they require switching to the standalone Orchestrator CLI
Consider either:
- Updating the examples to show the full invocation path (e.g., with
--pluginif they work through the public CLI), or- Clarifying that users should switch to the standalone Orchestrator CLI for these commands and showing the correct invocation pattern
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/01-command-line.mdx` around lines 58 - 76, The examples show the standalone Orchestrator commands (game-ci list-resources, game-ci watch, game-ci garbage-collect) but don't indicate whether they run via the public game-ci CLI or require the standalone Orchestrator CLI; update the examples to be unambiguous by either (A) adding the required plugin flag to each example (e.g., append the appropriate --plugin=<orchestrator-plugin> / --provider-strategy flags) so they clearly run through the public game-ci CLI, or (B) changing the header to instruct users to switch to the standalone Orchestrator CLI and show the exact invocation pattern used by that standalone binary for the three commands (list-resources, watch, garbage-collect); ensure you update the header text and each command line (game-ci list-resources, game-ci watch, game-ci garbage-collect) to reflect the chosen invocation method.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/03-github-orchestrator/07-advanced-topics/12-hot-runner-protocol.mdx`:
- Around line 130-154: The two examples use inconsistent syncInputRef URIs
(direct-input: storage://my-remote/inputs/changes.tar.lz4 vs storage-pull:
storage://s3:my-bucket/job-inputs/changes.tar.lz4); pick a canonical form and
make both examples consistent (prefer the named-remote form like
storage://my-s3-remote/... ), update the storage-pull example to use that same
format, and add one short clarifying sentence after the examples that explains
the chosen form is a configured rclone remote name (e.g., my-s3-remote must be
configured to point to the desired S3/GCS/Blob bucket) and when you would
instead use an inline provider path if you support it.
In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx`:
- Around line 43-56: Clarify the binary name conflict: state whether the
Orchestrator package and the public CLI both install the same game-ci executable
or whether they are distinct binaries, and if distinct explain which one wins on
PATH and how to disambiguate; update the section around the two examples to
mention the package names (Orchestrator vs public CLI), the plugin identifier
`@game-ci/orchestrator/cli-plugin`, and give guidance such as using the public CLI
with --plugin, installing one globally vs using npx/NPX or explicit package bin
paths, or renaming/aliasing to avoid PATH clashes so readers know which game-ci
will run.
- Around line 63-68: Update the AWS example that uses game-ci/unity-builder@v4
with providerStrategy: aws to show GitHub Actions OIDC authentication: add a
workflow-level permissions entry granting id-token: write and include the
builder input for role-to-assume (and optional aws-region) instead of suggesting
secrets; locate the snippet around providerStrategy: aws in the example and
replace or augment it to demonstrate using role-to-assume for OIDC-based
credential exchange with the Unity builder.
In `@docs/04-cli/03-remote-builds.mdx`:
- Around line 136-137: Update the cross-reference link string in
docs/04-cli/03-remote-builds.mdx by replacing the incorrect relative path
"../github-orchestrator/providers/cli-provider-protocol" with the correct
relative path "../03-github-orchestrator/05-providers/12-cli-provider-protocol"
so the link points to the actual document; locate the link text "CLI provider
protocol" in that file and change only the URL portion to the new path to
preserve link text and formatting.
---
Nitpick comments:
In
`@docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/01-command-line.mdx`:
- Around line 58-76: The examples show the standalone Orchestrator commands
(game-ci list-resources, game-ci watch, game-ci garbage-collect) but don't
indicate whether they run via the public game-ci CLI or require the standalone
Orchestrator CLI; update the examples to be unambiguous by either (A) adding the
required plugin flag to each example (e.g., append the appropriate
--plugin=<orchestrator-plugin> / --provider-strategy flags) so they clearly run
through the public game-ci CLI, or (B) changing the header to instruct users to
switch to the standalone Orchestrator CLI and show the exact invocation pattern
used by that standalone binary for the three commands (list-resources, watch,
garbage-collect); ensure you update the header text and each command line
(game-ci list-resources, game-ci watch, game-ci garbage-collect) to reflect the
chosen invocation method.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f5877fa2-10de-4b46-a23c-bc8d95915d5b
📒 Files selected for processing (14)
docs/03-github-orchestrator/01-introduction-to-orchestrator/01-introduction.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/02-game-ci-vs-orchestrator.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/03-getting-started.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/01-command-line.mdxdocs/03-github-orchestrator/07-advanced-topics/12-hot-runner-protocol.mdxdocs/03-github-orchestrator/07-advanced-topics/14-incremental-sync-protocol.mdxdocs/03-github-orchestrator/07-advanced-topics/15-large-projects.mdxdocs/03-github-orchestrator/08-cli/01-getting-started.mdxdocs/03-github-orchestrator/08-cli/_category_.yamldocs/04-cli/02-build.mdxdocs/04-cli/03-remote-builds.mdxdocs/04-cli/04-configuration-and-plugins.mdxdocs/04-cli/_category_.yamldocs/04-cli/index.mdx
| - uses: game-ci/unity-builder@v4 | ||
| with: | ||
| editorMode: persistent | ||
| syncStrategy: direct-input | ||
| syncInputRef: storage://my-remote/inputs/changes.tar.lz4 | ||
| ``` | ||
|
|
||
| Benefits: | ||
| This supports workflows such as: | ||
|
|
||
| - No editor startup time (saves 30–120 seconds per build) | ||
| - Unity Library folder stays warm - only changed assets reimport | ||
| - Domain reload only when scripts change | ||
| - Run tests before committing local changes | ||
| - Build with an asset override | ||
| - Validate a generated config bundle | ||
| - Test a hotfix without opening a pull request | ||
|
|
||
| ### Hybrid | ||
| ### Storage Pull | ||
|
|
||
| Pool of persistent editors, scale up ephemeral instances for burst load: | ||
| Large overlays can be stored through rclone and referenced by URI: | ||
|
|
||
| ```yaml | ||
| editorMode: hybrid | ||
| syncStrategy: storage-pull | ||
| syncInputRef: storage://s3:my-bucket/job-inputs/changes.tar.lz4 | ||
| ``` | ||
|
|
||
| ## Runner Labels | ||
| rclone keeps this provider-neutral: S3, GCS, Azure Blob, local filesystem, WebDAV, SFTP, and other | ||
| storage backends can all carry job input. |
There was a problem hiding this comment.
Inconsistent syncInputRef URI format across direct-input and storage-pull examples.
The two URI examples use different formats for the same syncInputRef field:
- Line 134 (direct-input):
storage://my-remote/inputs/changes.tar.lz4— uses a logical rclone remote name - Line 150 (storage-pull):
storage://s3:my-bucket/job-inputs/changes.tar.lz4— embeds the rcloneprovider:bucketpath directly
A reader cannot tell which form is authoritative or whether both are accepted. If both formats are valid, a brief note explaining when to use each (named remote alias vs. inline provider path) would help. If only one is canonical, fix the other.
📝 Option: normalize to the named-remote form
syncStrategy: storage-pull
-syncInputRef: storage://s3:my-bucket/job-inputs/changes.tar.lz4
+syncInputRef: storage://my-s3-remote/job-inputs/changes.tar.lz4Then add a note that my-s3-remote must be a configured rclone remote (e.g., pointing to an S3 bucket).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/03-github-orchestrator/07-advanced-topics/12-hot-runner-protocol.mdx`
around lines 130 - 154, The two examples use inconsistent syncInputRef URIs
(direct-input: storage://my-remote/inputs/changes.tar.lz4 vs storage-pull:
storage://s3:my-bucket/job-inputs/changes.tar.lz4); pick a canonical form and
make both examples consistent (prefer the named-remote form like
storage://my-s3-remote/... ), update the storage-pull example to use that same
format, and add one short clarifying sentence after the examples that explains
the chosen form is a configured rclone remote name (e.g., my-s3-remote must be
configured to point to the desired S3/GCS/Blob bucket) and when you would
instead use an inline provider path if you support it.
| game-ci build \ | ||
| --target-platform StandaloneLinux64 | ||
| --target-platform StandaloneLinux64 \ | ||
| --provider-strategy aws | ||
| ``` | ||
|
|
||
| You can also specify the Unity version explicitly: | ||
| This command talks directly to the Orchestrator package. The public CLI equivalent is: | ||
|
|
||
| ```bash | ||
| game-ci build \ | ||
| --unity-version 2022.3.56f1 \ | ||
| game-ci \ | ||
| --plugin @game-ci/orchestrator/cli-plugin \ | ||
| remote build ./my-project \ | ||
| --provider-strategy aws \ | ||
| --target-platform StandaloneLinux64 | ||
| ``` |
There was a problem hiding this comment.
Clarify the binary name overlap between the standalone Orchestrator CLI and the public game-ci CLI.
Both code blocks use game-ci as the executable name:
# standalone Orchestrator CLI
game-ci build --target-platform StandaloneLinux64 --provider-strategy aws
# public CLI "equivalent"
game-ci --plugin `@game-ci/orchestrator/cli-plugin` remote build ./my-project ...If both packages install a binary called game-ci, they conflict on PATH. The page should clarify:
- Whether the standalone Orchestrator CLI and the public CLI are the same binary (e.g., the public CLI ships the
game-cicommand and Orchestrator is always a plugin) or two distinct binaries with the same name. - If distinct, which one takes precedence, and whether they can coexist.
Without this, a reader following the install instructions for both will have no way to tell which game-ci they are running.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx` around lines 43 -
56, Clarify the binary name conflict: state whether the Orchestrator package and
the public CLI both install the same game-ci executable or whether they are
distinct binaries, and if distinct explain which one wins on PATH and how to
disambiguate; update the section around the two examples to mention the package
names (Orchestrator vs public CLI), the plugin identifier
`@game-ci/orchestrator/cli-plugin`, and give guidance such as using the public CLI
with --plugin, installing one globally vs using npx/NPX or explicit package bin
paths, or renaming/aliasing to avoid PATH clashes so readers know which game-ci
will run.
| ```yaml | ||
| - uses: game-ci/unity-builder@v4 | ||
| with: | ||
| providerStrategy: aws | ||
| targetPlatform: StandaloneLinux64 | ||
| ``` |
There was a problem hiding this comment.
Add OIDC authentication setup to the providerStrategy: aws snippet.
The example references providerStrategy: aws without any credential configuration. Per project conventions, AWS examples should demonstrate GitHub Actions OIDC authentication (id-token: write permission and role-to-assume) rather than implying long-lived secrets.
📝 Suggested addition
+permissions:
+ id-token: write
+ contents: read
+
- uses: game-ci/unity-builder@v4
+ env:
+ AWS_ROLE_TO_ASSUME: ${{ secrets.AWS_ROLE_TO_ASSUME }}
with:
providerStrategy: aws
targetPlatform: StandaloneLinux64Based on learnings: AWS workflow examples under docs/03-github-orchestrator/ should use GitHub Actions OIDC authentication instead of long-lived secrets.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx` around lines 63 -
68, Update the AWS example that uses game-ci/unity-builder@v4 with
providerStrategy: aws to show GitHub Actions OIDC authentication: add a
workflow-level permissions entry granting id-token: write and include the
builder input for role-to-assume (and optional aws-region) instead of suggesting
secrets; locate the snippet around providerStrategy: aws in the example and
replace or augment it to demonstrate using role-to-assume for OIDC-based
credential exchange with the Unity builder.
| For protocol details, see | ||
| [CLI provider protocol](../github-orchestrator/providers/cli-provider-protocol). |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if the referenced CLI provider protocol documentation exists
echo "Searching for CLI provider protocol documentation..."
fd -e mdx -e md "cli-provider-protocol" docs/Repository: game-ci/documentation
Length of output: 188
Fix the cross-reference link path to match the actual documentation structure.
The link path ../github-orchestrator/providers/cli-provider-protocol is incorrect. The actual file is located at docs/03-github-orchestrator/05-providers/12-cli-provider-protocol.mdx. Update the link to ../03-github-orchestrator/05-providers/12-cli-provider-protocol to resolve correctly in Docusaurus.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/04-cli/03-remote-builds.mdx` around lines 136 - 137, Update the
cross-reference link string in docs/04-cli/03-remote-builds.mdx by replacing the
incorrect relative path "../github-orchestrator/providers/cli-provider-protocol"
with the correct relative path
"../03-github-orchestrator/05-providers/12-cli-provider-protocol" so the link
points to the actual document; locate the link text "CLI provider protocol" in
that file and change only the URL portion to the new path to preserve link text
and formatting.
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/03-github-orchestrator/07-advanced-topics/17-build-reliability.mdx (1)
315-323:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winInputs Reference table is missing the parameters introduced in the new sections.
orchestratorDebug,mode(garbage-collect),garbageMaxAge, anduseCleanupCronare all described or used in the Logging / Garbage Collection sections above but have no entries in the reference table. Readers consulting this table will have no place to look up defaults or descriptions for these inputs.📝 Suggested additions to the table
| `buildArchiveRetention` | Number of builds to retain per platform | `'3'` | +| `orchestratorDebug` | Enable verbose provider diagnostics (setup, env, disk, cache) | `'false'` | +| `mode` | Execution mode; set to `garbage-collect` to run stale-resource cleanup | `''` | +| `garbageMaxAge` | Age threshold (hours) for garbage collection | `'24'` | +| `useCleanupCron` | Create a CloudFormation-based cleanup cron on AWS when GC runs | `'false'` |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/03-github-orchestrator/07-advanced-topics/17-build-reliability.mdx` around lines 315 - 323, Add missing input rows to the Inputs Reference table for the new parameters: orchestratorDebug, mode (document the 'garbage-collect' option), garbageMaxAge, and useCleanupCron; for each row include a short Description matching the Logging / Garbage Collection sections (e.g., orchestratorDebug toggles verbose orchestration logs, mode selects operation mode such as 'garbage-collect', garbageMaxAge sets the retention age threshold for GC, useCleanupCron enables scheduled cleanup), and the appropriate Default values (e.g., orchestratorDebug `'false'`, mode `'garbage-collect'` or the module's default, garbageMaxAge the default duration used in GC, useCleanupCron `'false'`), so readers can look up these inputs directly from the table.docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/03-aws.mdx (1)
24-29:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftReplace long-lived AWS key secrets with OIDC across all three workflow examples.
The Minimal AWS Build (lines 24-29), Multi-Platform Matrix Build (lines 70-75), and Scheduled Garbage Collection (lines 185-190) all authenticate via
AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY. All three examples should instead demonstrate OIDC role assumption (no long-lived credentials stored as secrets). The Required Secrets table (lines 221-224) will also need updating to reflect the switch to OIDC.📝 Example replacement for the Minimal AWS Build credential step
- - name: Configure AWS Credentials - uses: aws-actions/configure-aws-credentials@v4 - with: - aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} - aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} - aws-region: eu-west-2 + - name: Configure AWS Credentials + uses: aws-actions/configure-aws-credentials@v4 + with: + role-to-assume: ${{ secrets.AWS_ROLE_ARN }} + aws-region: eu-west-2The calling job also needs
id-token: writepermission:jobs: build: runs-on: ubuntu-latest + permissions: + id-token: write + contents: readApply the same pattern to the Matrix Build and Garbage Collection workflows.
Based on learnings: all AWS workflow examples under
docs/03-github-orchestrator/should use GitHub Actions OIDC authentication (role-to-assumewithid-token: write) instead of long-livedAWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEYsecrets.Also applies to: 70-75, 185-190
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/03-aws.mdx` around lines 24 - 29, Replace the long-lived credentials usage in the three workflow examples by switching the aws-actions/configure-aws-credentials@v4 step (the "name: Configure AWS Credentials" block) to OIDC role assumption: remove aws-access-key-id and aws-secret-access-key inputs and instead supply role-to-assume (and optionally role-session-name) in that step, and add the calling job permission id-token: write so GitHub can request an OIDC token; apply this exact pattern to the Minimal AWS Build, Multi-Platform Matrix Build, and Scheduled Garbage Collection examples, and update the Required Secrets table to remove AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY (and document that no AWS long-lived secrets are required when using OIDC).
♻️ Duplicate comments (3)
docs/03-github-orchestrator/08-cli/01-getting-started.mdx (2)
63-68:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd OIDC-based AWS auth guidance to the Unity Builder AWS snippet.
The
providerStrategy: awsexample should show OIDC-based role assumption (or explicitly link to that setup) so it does not imply credential configuration is optional.Based on learnings: In the game-ci/documentation repository, all AWS workflow examples under docs/03-github-orchestrator/ should use GitHub Actions OIDC authentication (configure role-to-assume with required permissions, including id-token: write) instead of embedding or referencing long-lived AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY secrets.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx` around lines 63 - 68, Update the Unity Builder AWS snippet (the block that uses game-ci/unity-builder@v4 with providerStrategy: aws and targetPlatform: StandaloneLinux64) to demonstrate GitHub Actions OIDC role assumption instead of implying long‑lived credentials: show or link to configuration that requests id-token: write, configures a role-to-assume ARN, and uses the action's OIDC-based provider setup (or add a clearly marked note linking to a step-by-step OIDC setup doc) so readers know to configure role assumption and required permissions rather than using AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY.
48-55:⚠️ Potential issue | 🟠 Major | ⚡ Quick winClarify how to distinguish standalone vs public
game-cibinary invocation.Both examples use
game-ci, but the page does not explain how users verify which binary is onPATHwhen both are installed. Add a short disambiguation note (package source, precedence, and a safe invocation pattern).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx` around lines 48 - 55, Add a short disambiguation note explaining how to tell the standalone orchestrator binary from the public game-ci binary: describe how PATH precedence favors a local node_modules/.bin entry over a global install, note how to check which executable is being invoked (e.g., system which/where or checking npm/yarn global vs local bins), and recommend a safe invocation pattern such as using npx/yarn dlx or invoking the package directly via the `@game-ci/orchestrator-plugin` to guarantee the intended binary for commands like "game-ci --plugin `@game-ci/orchestrator-plugin` remote build" and the "remote build" flow.docs/04-cli/03-remote-builds.mdx (1)
136-137:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix the CLI provider protocol cross-reference path.
The link target appears incorrect and likely won’t resolve from this page. Please update it to the actual Orchestrator provider doc path.
Suggested fix
- [CLI provider protocol](../github-orchestrator/providers/cli-provider-protocol). + [CLI provider protocol](../03-github-orchestrator/05-providers/12-cli-provider-protocol).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/04-cli/03-remote-builds.mdx` around lines 136 - 137, The cross-reference for "CLI provider protocol" currently points to ../github-orchestrator/providers/cli-provider-protocol which is incorrect; update the link target so it resolves to the Orchestrator provider doc (replace the href in the markdown link `[CLI provider protocol](../github-orchestrator/providers/cli-provider-protocol)` with the correct path to the Orchestrator provider docs, e.g. `../orchestrator/providers/cli-provider-protocol` or the actual published doc path used in the repo) so the link text "CLI provider protocol" correctly navigates to the intended provider documentation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/03-github-orchestrator/07-advanced-topics/10-build-services.mdx`:
- Around line 27-37: Add an OIDC credential step before the unity-builder job:
insert a step named "Configure AWS Credentials" that uses
aws-actions/configure-aws-credentials@v4 and sets role-to-assume (e.g., ${ {
secrets.AWS_ROLE_ARN } }) and aws-region, so the existing unity-builder
invocation (the block containing providerStrategy: aws and
customJob/godot-export) runs under GitHub Actions OIDC rather than long-lived
keys; ensure the step matches the pattern used in 03-getting-started.mdx and
includes a comment referencing the AWS provider OIDC setup.
In `@docs/04-cli/04-configuration-and-plugins.mdx`:
- Around line 22-24: The example uses the inconsistent key cliOptions.plugin;
update it to the plural cliOptions.plugins so it matches other examples and the
actual parsed option name (replace cliOptions.plugin with cliOptions.plugins in
the example block), ensuring consistency with references to cliOptions.plugins
elsewhere in the docs.
In `@docs/04-cli/index.mdx`:
- Line 50: Update the PATH guidance to include the Windows equivalent alongside
the Unix one: keep the existing "~/.game-ci/bin" note and add the Windows user
bin path "%USERPROFILE%\\.game-ci\\bin" with a short PowerShell instruction to
add it to PATH (referencing the PATH environment variable and PowerShell's user
profile path), so Windows users who installed via PowerShell know which
directory to add to their PATH.
---
Outside diff comments:
In
`@docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/03-aws.mdx`:
- Around line 24-29: Replace the long-lived credentials usage in the three
workflow examples by switching the aws-actions/configure-aws-credentials@v4 step
(the "name: Configure AWS Credentials" block) to OIDC role assumption: remove
aws-access-key-id and aws-secret-access-key inputs and instead supply
role-to-assume (and optionally role-session-name) in that step, and add the
calling job permission id-token: write so GitHub can request an OIDC token;
apply this exact pattern to the Minimal AWS Build, Multi-Platform Matrix Build,
and Scheduled Garbage Collection examples, and update the Required Secrets table
to remove AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY (and document that no AWS
long-lived secrets are required when using OIDC).
In `@docs/03-github-orchestrator/07-advanced-topics/17-build-reliability.mdx`:
- Around line 315-323: Add missing input rows to the Inputs Reference table for
the new parameters: orchestratorDebug, mode (document the 'garbage-collect'
option), garbageMaxAge, and useCleanupCron; for each row include a short
Description matching the Logging / Garbage Collection sections (e.g.,
orchestratorDebug toggles verbose orchestration logs, mode selects operation
mode such as 'garbage-collect', garbageMaxAge sets the retention age threshold
for GC, useCleanupCron enables scheduled cleanup), and the appropriate Default
values (e.g., orchestratorDebug `'false'`, mode `'garbage-collect'` or the
module's default, garbageMaxAge the default duration used in GC, useCleanupCron
`'false'`), so readers can look up these inputs directly from the table.
---
Duplicate comments:
In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx`:
- Around line 63-68: Update the Unity Builder AWS snippet (the block that uses
game-ci/unity-builder@v4 with providerStrategy: aws and targetPlatform:
StandaloneLinux64) to demonstrate GitHub Actions OIDC role assumption instead of
implying long‑lived credentials: show or link to configuration that requests
id-token: write, configures a role-to-assume ARN, and uses the action's
OIDC-based provider setup (or add a clearly marked note linking to a
step-by-step OIDC setup doc) so readers know to configure role assumption and
required permissions rather than using AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY.
- Around line 48-55: Add a short disambiguation note explaining how to tell the
standalone orchestrator binary from the public game-ci binary: describe how PATH
precedence favors a local node_modules/.bin entry over a global install, note
how to check which executable is being invoked (e.g., system which/where or
checking npm/yarn global vs local bins), and recommend a safe invocation pattern
such as using npx/yarn dlx or invoking the package directly via the
`@game-ci/orchestrator-plugin` to guarantee the intended binary for commands like
"game-ci --plugin `@game-ci/orchestrator-plugin` remote build" and the "remote
build" flow.
In `@docs/04-cli/03-remote-builds.mdx`:
- Around line 136-137: The cross-reference for "CLI provider protocol" currently
points to ../github-orchestrator/providers/cli-provider-protocol which is
incorrect; update the link target so it resolves to the Orchestrator provider
doc (replace the href in the markdown link `[CLI provider
protocol](../github-orchestrator/providers/cli-provider-protocol)` with the
correct path to the Orchestrator provider docs, e.g.
`../orchestrator/providers/cli-provider-protocol` or the actual published doc
path used in the repo) so the link text "CLI provider protocol" correctly
navigates to the intended provider documentation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4538bd0c-d6a7-48bb-84e5-04b4c00d48c0
📒 Files selected for processing (27)
docs/03-github-orchestrator/01-introduction-to-orchestrator/01-introduction.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/02-game-ci-vs-orchestrator.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/03-getting-started.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/01-command-line.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/02-github-actions.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/03-aws.mdxdocs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/04-kubernetes.mdxdocs/03-github-orchestrator/04-jobs.mdxdocs/03-github-orchestrator/05-api-reference.mdxdocs/03-github-orchestrator/07-advanced-topics/01-caching.mdxdocs/03-github-orchestrator/07-advanced-topics/02-retained-workspace.mdxdocs/03-github-orchestrator/07-advanced-topics/03-custom-job.mdxdocs/03-github-orchestrator/07-advanced-topics/04-garbage-collection.mdxdocs/03-github-orchestrator/07-advanced-topics/06-logging.mdxdocs/03-github-orchestrator/07-advanced-topics/08-storage.mdxdocs/03-github-orchestrator/07-advanced-topics/10-build-services.mdxdocs/03-github-orchestrator/07-advanced-topics/14-incremental-sync-protocol.mdxdocs/03-github-orchestrator/07-advanced-topics/17-build-reliability.mdxdocs/03-github-orchestrator/07-advanced-topics/18-engine-plugins.mdxdocs/03-github-orchestrator/08-cli/01-getting-started.mdxdocs/03-github-orchestrator/08-cli/02-build-command.mdxdocs/04-cli/02-build.mdxdocs/04-cli/03-remote-builds.mdxdocs/04-cli/04-configuration-and-plugins.mdxdocs/04-cli/05-github-action.mdxdocs/04-cli/index.mdxdocs/10-faq/index.mdx
💤 Files with no reviewable changes (5)
- docs/03-github-orchestrator/07-advanced-topics/03-custom-job.mdx
- docs/03-github-orchestrator/07-advanced-topics/04-garbage-collection.mdx
- docs/03-github-orchestrator/07-advanced-topics/06-logging.mdx
- docs/03-github-orchestrator/07-advanced-topics/14-incremental-sync-protocol.mdx
- docs/03-github-orchestrator/07-advanced-topics/02-retained-workspace.mdx
✅ Files skipped from review due to trivial changes (2)
- docs/04-cli/05-github-action.mdx
- docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/02-github-actions.mdx
| ```yaml | ||
| - uses: game-ci/unity-builder@v4 | ||
| with: | ||
| providerStrategy: aws | ||
| customJob: | | ||
| - name: godot-export | ||
| image: barichello/godot-ci:4.3 | ||
| commands: | | ||
| godot --headless --export-release "Linux/X11" /build/output/game | ||
| gitPrivateToken: ${{ secrets.GITHUB_TOKEN }} | ||
| ``` |
There was a problem hiding this comment.
AWS example missing OIDC credential step.
The snippet uses providerStrategy: aws but provides no credential setup. Per the project learning, AWS examples under docs/03-github-orchestrator/ should demonstrate OIDC authentication with configure-aws-credentials rather than implying static keys.
Consider prefixing the snippet with the OIDC step (or at least an inline comment pointing to the provider setup guide), consistent with the pattern used in 03-getting-started.mdx:
📄 Suggested update
```yaml
+- name: Configure AWS Credentials
+ uses: aws-actions/configure-aws-credentials@v4
+ with:
+ role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
+ aws-region: eu-west-1
+ # See the AWS provider page for full OIDC setup
+
- uses: game-ci/unity-builder@v4
with:
providerStrategy: awsBased on learnings: "all AWS workflow examples under docs/03-github-orchestrator/ should use GitHub Actions OIDC authentication (configure role-to-assume with required permissions, including id-token: write) instead of embedding or referencing long-lived AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY secrets."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/03-github-orchestrator/07-advanced-topics/10-build-services.mdx` around
lines 27 - 37, Add an OIDC credential step before the unity-builder job: insert
a step named "Configure AWS Credentials" that uses
aws-actions/configure-aws-credentials@v4 and sets role-to-assume (e.g., ${ {
secrets.AWS_ROLE_ARN } }) and aws-region, so the existing unity-builder
invocation (the block containing providerStrategy: aws and
customJob/godot-export) runs under GitHub Actions OIDC rather than long-lived
keys; ensure the step matches the pattern used in 03-getting-started.mdx and
includes a comment referencing the AWS provider OIDC setup.
| cliOptions: | ||
| plugin: | ||
| - '@game-ci/orchestrator-plugin' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify which key is documented/implemented across the repo.
# Expected: one canonical key (likely `plugins`) in docs and code-facing references.
rg -n -C2 '\bcliOptions:\s*$|^\s+plugin[s]?:'Repository: game-ci/documentation
Length of output: 1586
🏁 Script executed:
# First, find the CLI implementation files
fd -t f '\.(ts|js)$' | head -20Repository: game-ci/documentation
Length of output: 628
🏁 Script executed:
# Search for where cliOptions or plugin config is parsed
rg -n 'cliOptions|plugin[s]?\s*:' --type ts --type js -A 2 -B 2 | head -100Repository: game-ci/documentation
Length of output: 489
🏁 Script executed:
# Look for CLI argument parser or config handler
rg -n -i 'plugin.*config|config.*plugin' --type ts --type js -A 2 -B 2 | head -100Repository: game-ci/documentation
Length of output: 301
🏁 Script executed:
# Look for package.json and any references to orchestrator or CLI packages
cat package.json | grep -A 5 -B 5 orchestratorRepository: game-ci/documentation
Length of output: 47
🏁 Script executed:
# Search for any references to the actual CLI repo or implementation links
rg -n 'orchestrator|@game-ci' --type json --type yaml --type md | head -30Repository: game-ci/documentation
Length of output: 131
🏁 Script executed:
# Look for configuration schema or type definitions
fd -t f '\.(ts|d\.ts|schema\)' -path '*config*' -o -path '*schema*' | head -20Repository: game-ci/documentation
Length of output: 234
🏁 Script executed:
# Read the full section from the config file around the inconsistency
sed -n '15,70p' docs/04-cli/04-configuration-and-plugins.mdxRepository: game-ci/documentation
Length of output: 1543
🏁 Script executed:
# Check if there are any other references to the plugin key in the entire file
cat docs/04-cli/04-configuration-and-plugins.mdx | wc -lRepository: game-ci/documentation
Length of output: 69
🏁 Script executed:
# Search for any explanatory text about configuration
rg -n -A 5 -B 5 'plugin' docs/04-cli/04-configuration-and-plugins.mdx | head -80Repository: game-ci/documentation
Length of output: 2434
Fix config key inconsistency: use plugins (plural), not plugin.
Line 23 uses cliOptions.plugin, but line 62 in the same file and line 145 in 03-remote-builds.mdx all use cliOptions.plugins. The first example will mislead users if plugins is the parsed option key. Update line 23 to use the consistent plural form.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/04-cli/04-configuration-and-plugins.mdx` around lines 22 - 24, The
example uses the inconsistent key cliOptions.plugin; update it to the plural
cliOptions.plugins so it matches other examples and the actual parsed option
name (replace cliOptions.plugin with cliOptions.plugins in the example block),
ensuring consistency with references to cliOptions.plugins elsewhere in the
docs.
| | `GAME_CI_VERSION` | Pin a release, for example `v0.1.0`. | latest | | ||
| | `GAME_CI_INSTALL` | Install directory for the `game-ci` executable. | `~/.game-ci/bin` | | ||
|
|
||
| After installation, make sure `~/.game-ci/bin` is on your `PATH`. |
There was a problem hiding this comment.
PATH guidance is Linux/macOS-only; add the Windows equivalent.
Line 50 references ~/.game-ci/bin, which only applies to Unix shells. Windows users arriving via the PowerShell install block have no guidance on which directory to add to their PATH.
📄 Suggested update
-After installation, make sure `~/.game-ci/bin` is on your `PATH`.
+After installation, make sure the install directory is on your `PATH`:
+- **Linux / macOS**: `~/.game-ci/bin`
+- **Windows**: `%USERPROFILE%\.game-ci\bin` (or the directory specified by `GAME_CI_INSTALL`)📝 Committable suggestion
‼️ 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.
| After installation, make sure `~/.game-ci/bin` is on your `PATH`. | |
| After installation, make sure the install directory is on your `PATH`: | |
| - **Linux / macOS**: `~/.game-ci/bin` | |
| - **Windows**: `%USERPROFILE%\.game-ci\bin` (or the directory specified by `GAME_CI_INSTALL`) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/04-cli/index.mdx` at line 50, Update the PATH guidance to include the
Windows equivalent alongside the Unix one: keep the existing "~/.game-ci/bin"
note and add the Windows user bin path "%USERPROFILE%\\.game-ci\\bin" with a
short PowerShell instruction to add it to PATH (referencing the PATH environment
variable and PowerShell's user profile path), so Windows users who installed via
PowerShell know which directory to add to their PATH.
There was a problem hiding this comment.
♻️ Duplicate comments (5)
docs/03-github-orchestrator/08-cli/01-getting-started.mdx (2)
43-56:⚠️ Potential issue | 🟠 Major | ⚡ Quick winBinary name overlap between the standalone CLI and the public
game-ciCLI remains unresolved.Both code blocks still use the same
game-ciexecutable without clarifying whether they are the same binary or two distinct binaries that conflict onPATH. Readers following both install paths will be unable to determine whichgame-cithey are running.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx` around lines 43 - 56, The docs show the same "game-ci" executable for both the standalone Orchestrator CLI and the public plugin-based CLI which creates ambiguity; update the text to disambiguate the binaries by either (a) stating that the standalone Orchestrator binary is a differently named executable (e.g., "game-ci-orchestrator") and show that name in the first code block, or (b) explicitly call out PATH precedence and how to invoke the Orchestrator package via its package-scoped binary versus the public "game-ci" with "--plugin `@game-ci/orchestrator-plugin`"; modify the two examples so one uses the unique standalone binary name (or a fully-qualified path) and the other uses "game-ci --plugin `@game-ci/orchestrator-plugin`" to remove confusion.
63-68:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd OIDC authentication to the
providerStrategy: awssnippet.The YAML example references
providerStrategy: awswith no credential configuration. Per project conventions, AWS examples underdocs/03-github-orchestrator/must demonstrate GitHub Actions OIDC authentication (id-token: write+role-to-assume) rather than implying long-lived secrets.Based on learnings: AWS workflow examples under
docs/03-github-orchestrator/should use GitHub Actions OIDC authentication instead of embedding or referencing long-livedAWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEYsecrets.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx` around lines 63 - 68, Update the AWS example to use GitHub Actions OIDC: add repository-level permissions "id-token: write" and remove any long-lived AWS secrets, and pass the target role via the unity-builder input "role-to-assume" (e.g., role-to-assume: arn:aws:iam::ACCOUNT_ID:role/YourGithubOIDCRole) while keeping providerStrategy: aws and targetPlatform: StandaloneLinux64; ensure the snippet shows that id-token permission is required and that "role-to-assume" is used instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY.docs/04-cli/index.mdx (1)
54-54:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd Windows PATH guidance alongside the Unix path.
Line 54 is Unix-only, but this page also documents Windows install. Please include
%USERPROFILE%\.game-ci\bin(orGAME_CI_INSTALL) for Windows users.Suggested minimal diff
-After installation, make sure `~/.game-ci/bin` is on your `PATH`. +After installation, make sure the install directory is on your `PATH`: +- **Linux / macOS**: `~/.game-ci/bin` +- **Windows**: `%USERPROFILE%\.game-ci\bin` (or the path set by `GAME_CI_INSTALL`)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/04-cli/index.mdx` at line 54, Update the sentence "After installation, make sure `~/.game-ci/bin` is on your `PATH`." to also include Windows guidance by adding the equivalent Windows path `%USERPROFILE%\.game-ci\bin` and mention the alternative `GAME_CI_INSTALL` variable (e.g., use `%GAME_CI_INSTALL%\bin` or `%USERPROFILE%\.game-ci\bin`) so Windows users know which path to add to their PATH environment variable; keep the wording concise and parallel to the Unix instruction.docs/04-cli/03-remote-builds.mdx (1)
141-142:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix the broken relative link for the CLI provider protocol.
Line 142 still points to
../github-orchestrator/providers/cli-provider-protocol, which does not match the documented file structure used elsewhere in this PR.Suggested minimal diff
-For protocol details, see -[CLI provider protocol](../github-orchestrator/providers/cli-provider-protocol). +For protocol details, see +[CLI provider protocol](../03-github-orchestrator/05-providers/12-cli-provider-protocol).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/04-cli/03-remote-builds.mdx` around lines 141 - 142, The relative link target "../github-orchestrator/providers/cli-provider-protocol" is incorrect; update the Markdown link in docs/04-cli/03-remote-builds.mdx to use the same relative path used elsewhere in this PR for the CLI provider protocol (locate other occurrences of the CLI provider protocol link and copy that exact href), replacing the current target so the link resolves correctly.docs/04-cli/04-configuration-and-plugins.mdx (1)
23-25:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUse
plugins(plural) in the config example for consistency.Line 24 uses
plugin, but the rest of the CLI docs/examples usecliOptions.plugins. Keeping this singular key here is likely to confuse copy/paste usage.Suggested minimal diff
cliOptions: - plugin: + plugins: - '@game-ci/orchestrator-plugin'🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/04-cli/04-configuration-and-plugins.mdx` around lines 23 - 25, Update the YAML example to use the plural key to match the rest of the docs: replace cliOptions.plugin with cliOptions.plugins so the snippet shows "cliOptions:\n plugins:\n - '@game-ci/orchestrator-plugin'"; ensure the example now references cliOptions.plugins consistently with other examples.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@docs/03-github-orchestrator/08-cli/01-getting-started.mdx`:
- Around line 43-56: The docs show the same "game-ci" executable for both the
standalone Orchestrator CLI and the public plugin-based CLI which creates
ambiguity; update the text to disambiguate the binaries by either (a) stating
that the standalone Orchestrator binary is a differently named executable (e.g.,
"game-ci-orchestrator") and show that name in the first code block, or (b)
explicitly call out PATH precedence and how to invoke the Orchestrator package
via its package-scoped binary versus the public "game-ci" with "--plugin
`@game-ci/orchestrator-plugin`"; modify the two examples so one uses the unique
standalone binary name (or a fully-qualified path) and the other uses "game-ci
--plugin `@game-ci/orchestrator-plugin`" to remove confusion.
- Around line 63-68: Update the AWS example to use GitHub Actions OIDC: add
repository-level permissions "id-token: write" and remove any long-lived AWS
secrets, and pass the target role via the unity-builder input "role-to-assume"
(e.g., role-to-assume: arn:aws:iam::ACCOUNT_ID:role/YourGithubOIDCRole) while
keeping providerStrategy: aws and targetPlatform: StandaloneLinux64; ensure the
snippet shows that id-token permission is required and that "role-to-assume" is
used instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY.
In `@docs/04-cli/03-remote-builds.mdx`:
- Around line 141-142: The relative link target
"../github-orchestrator/providers/cli-provider-protocol" is incorrect; update
the Markdown link in docs/04-cli/03-remote-builds.mdx to use the same relative
path used elsewhere in this PR for the CLI provider protocol (locate other
occurrences of the CLI provider protocol link and copy that exact href),
replacing the current target so the link resolves correctly.
In `@docs/04-cli/04-configuration-and-plugins.mdx`:
- Around line 23-25: Update the YAML example to use the plural key to match the
rest of the docs: replace cliOptions.plugin with cliOptions.plugins so the
snippet shows "cliOptions:\n plugins:\n - '@game-ci/orchestrator-plugin'";
ensure the example now references cliOptions.plugins consistently with other
examples.
In `@docs/04-cli/index.mdx`:
- Line 54: Update the sentence "After installation, make sure `~/.game-ci/bin`
is on your `PATH`." to also include Windows guidance by adding the equivalent
Windows path `%USERPROFILE%\.game-ci\bin` and mention the alternative
`GAME_CI_INSTALL` variable (e.g., use `%GAME_CI_INSTALL%\bin` or
`%USERPROFILE%\.game-ci\bin`) so Windows users know which path to add to their
PATH environment variable; keep the wording concise and parallel to the Unix
instruction.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 995fc18b-8729-43a4-b15c-bcb64e8dd8d3
📒 Files selected for processing (8)
docs/03-github-orchestrator/01-introduction-to-orchestrator/04-examples/01-command-line.mdxdocs/03-github-orchestrator/08-cli/01-getting-started.mdxdocs/04-cli/02-build.mdxdocs/04-cli/03-remote-builds.mdxdocs/04-cli/04-configuration-and-plugins.mdxdocs/04-cli/05-github-action.mdxdocs/04-cli/_category_.yamldocs/04-cli/index.mdx
2 participants
Summary
Validation
Summary by CodeRabbit