docs(nx-dev): promote setting up CI to top-level Getting Started

## Current Behavior Setting Up CI page lives at end of tutorial series. Low traffic, buried. ## Expected Behavior Top-level Getting Started entry. Short, focused on remote cache via `nx connect`. `llm_only` block routes agents to `nx-cloud onboard connect-workspace`. Tutorial series renumbered 8 -> 7. Old URL 301s to new. ## Related Issue(s) Fixes DOC-503
2026-05-11 15:58:04 -04:00
14 changed files with 133 additions and 197 deletions
@@ -83,6 +83,11 @@ to = "/docs/technologies/angular/migration/angular"
 from = "/docs/getting-started/nx-cloud"
 to = "/docs/features/ci-features"

+# DOC-503: CI page moved out of tutorials to top-level Getting Started
+[[redirects]]
+from = "/docs/getting-started/tutorials/self-healing-ci-tutorial"
+to = "/docs/getting-started/setup-ci"
+
 # Rewrite for base path handling (keeps URL the same)
 [[redirects]]
 from = "/docs/*"
@@ -35,6 +35,7 @@ const learnGroups: SidebarItems = [
      },
      { label: 'AI integrations', link: 'getting-started/ai-setup' },
      { label: 'Editor setup', link: 'getting-started/editor-setup' },
+      { label: 'Setting up CI', link: 'getting-started/setup-ci' },
      {
        label: 'Tutorials',
        collapsed: false,
@@ -67,10 +68,6 @@ const learnGroups: SidebarItems = [
            label: 'Reducing boilerplate',
            link: 'getting-started/tutorials/reducing-configuration-boilerplate',
          },
-          {
-            label: 'Setting up CI',
-            link: 'getting-started/tutorials/self-healing-ci-tutorial',
-          },
          {
            label: 'Gradle monorepo',
            link: 'getting-started/tutorials/gradle-tutorial',
@@ -518,7 +518,7 @@ Not all tasks might be cacheable though. You can configure the `cache` settings

 Here are some things you can dive into next:

- [Set up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial) with remote caching and self-healing
+- [Set up CI](/docs/getting-started/setup-ci) with remote caching and self-healing
 - Read more about [how Nx compares to the Angular CLI](/docs/technologies/angular/guides/nx-and-angular)
 - Learn more about the [underlying mental model of Nx](/docs/concepts/mental-model)
 - Learn about popular generators such as [how to setup Tailwind](/docs/technologies/angular/guides/using-tailwind-css-with-angular-projects)
@@ -5,7 +5,7 @@ sidebar:
  order: 5
 ---

-{% llm_copy_prompt title="Tutorial 5/8: Enable and configure caching" %}
+{% llm_copy_prompt title="Tutorial 5/7: Enable and configure caching" %}
 Help me set up caching in my Nx workspace.
 Use my existing workspace and projects for hands-on examples.

@@ -31,7 +31,6 @@ The examples below use Vite and Vitest, but the concepts apply to any tool. Subs
 5. **Caching** (you are here)
 6. [Understanding your workspace](/docs/getting-started/tutorials/understanding-your-workspace)
 7. [Reducing boilerplate](/docs/getting-started/tutorials/reducing-configuration-boilerplate)
-8. [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial)

 {% /aside %}

@@ -220,7 +219,7 @@ This command guides you through creating a free Nx Cloud account and stores an a

 When a teammate or CI pipeline has already run a task with the same inputs, you get the cached result instantly, even on a fresh checkout.

-For more on how remote caching works, see [remote cache (Nx Replay)](/docs/features/ci-features/remote-cache). To set up CI with Nx Cloud, see [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial).
+For more on how remote caching works, see [remote cache (Nx Replay)](/docs/features/ci-features/remote-cache). To set up CI with Nx Cloud, see [Setting up CI](/docs/getting-started/setup-ci).

 ## Learn more

@@ -5,7 +5,7 @@ sidebar:
  order: 3
 ---

-{% llm_copy_prompt title="Tutorial 3/8: Configure tasks for your projects" %}
+{% llm_copy_prompt title="Tutorial 3/7: Configure tasks for your projects" %}
 Help me configure tasks (build, test, lint, serve) for my Nx workspace projects.
 Use my existing workspace and projects for hands-on examples.

@@ -29,7 +29,6 @@ The examples below use Vite and Vitest, but the concepts apply to any tool. Subs
 5. [Caching](/docs/getting-started/tutorials/caching)
 6. [Understanding your workspace](/docs/getting-started/tutorials/understanding-your-workspace)
 7. [Reducing boilerplate](/docs/getting-started/tutorials/reducing-configuration-boilerplate)
-8. [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial)

 {% /aside %}

@@ -5,7 +5,7 @@ sidebar:
  order: 1
 ---

-{% llm_copy_prompt title="Tutorial 1/8: Set up an Nx workspace" %}
+{% llm_copy_prompt title="Tutorial 1/7: Set up an Nx workspace" %}
 Help me learn Nx step by step using this tutorial series.

 If my current directory already has nx.json, skip setup and teach me using my existing workspace.
@@ -32,7 +32,6 @@ Nx works with any repo structure and plays well with tools you already use: pnpm
 5. [Caching](/docs/getting-started/tutorials/caching)
 6. [Understanding your workspace](/docs/getting-started/tutorials/understanding-your-workspace)
 7. [Reducing boilerplate](/docs/getting-started/tutorials/reducing-configuration-boilerplate)
-8. [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial)

 {% /aside %}

@@ -5,7 +5,7 @@ sidebar:
  order: 2
 ---

-{% llm_copy_prompt title="Tutorial 2/8: Understand project dependencies" %}
+{% llm_copy_prompt title="Tutorial 2/7: Understand project dependencies" %}
 Help me understand how my Nx workspace tracks dependencies between projects.
 Use my existing workspace and projects for hands-on examples.

@@ -29,7 +29,6 @@ As your workspace grows, projects start depending on each other and on external
 5. [Caching](/docs/getting-started/tutorials/caching)
 6. [Understanding your workspace](/docs/getting-started/tutorials/understanding-your-workspace)
 7. [Reducing boilerplate](/docs/getting-started/tutorials/reducing-configuration-boilerplate)
-8. [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial)

 {% /aside %}

@@ -481,7 +481,7 @@ Not all tasks might be cacheable though. You can configure the `cache` settings

 Here are some things you can dive into next:

- [Set up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial) with remote caching and self-healing
+- [Set up CI](/docs/getting-started/setup-ci) with remote caching and self-healing
 - Learn more about the [underlying mental model of Nx](/docs/concepts/mental-model)
 - Learn how to [migrate your existing project to Nx](/docs/guides/adopting-nx/adding-to-existing-project)
 - [Setup Storybook for our shared UI library](/docs/technologies/test-tools/storybook/guides/overview-react)
@@ -5,7 +5,7 @@ sidebar:
  order: 7
 ---

-{% llm_copy_prompt title="Tutorial 7/8: Reduce configuration with plugins" %}
+{% llm_copy_prompt title="Tutorial 7/7: Reduce configuration with plugins" %}
 Help me reduce configuration boilerplate in my Nx workspace.
 Use my existing workspace and projects for hands-on examples.

@@ -31,7 +31,6 @@ The examples below use Vite and Vitest, but the concepts apply to any tool. Subs
 5. [Caching](/docs/getting-started/tutorials/caching)
 6. [Understanding your workspace](/docs/getting-started/tutorials/understanding-your-workspace)
 7. **Reducing boilerplate** (you are here)
-8. [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial)

 {% /aside %}

@@ -380,5 +379,5 @@ Stick with explicit configuration when:

 {% cards cols=2 %}
 {% card title="Previous: Understanding Your Workspace" description="Explore projects, graphs, and debug issues" url="/docs/getting-started/tutorials/understanding-your-workspace" /%}
-{% card title="Next: Setting Up CI" description="Configure CI with remote caching and self-healing" url="/docs/getting-started/tutorials/self-healing-ci-tutorial" /%}
+{% card title="Set Up CI" description="Connect Nx Cloud for remote caching and self-healing CI" url="/docs/getting-started/setup-ci" /%}
 {% /cards %}
@@ -5,7 +5,7 @@ sidebar:
  order: 4
 ---

-{% llm_copy_prompt title="Tutorial 4/8: Run tasks across your workspace" %}
+{% llm_copy_prompt title="Tutorial 4/7: Run tasks across your workspace" %}
 Help me run tasks in my Nx workspace efficiently.
 Use my existing workspace and projects for hands-on examples.

@@ -29,7 +29,6 @@ The examples below use Vite and Vitest, but the concepts apply to any tool. Subs
 5. [Caching](/docs/getting-started/tutorials/caching)
 6. [Understanding your workspace](/docs/getting-started/tutorials/understanding-your-workspace)
 7. [Reducing boilerplate](/docs/getting-started/tutorials/reducing-configuration-boilerplate)
-8. [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial)

 {% /aside %}

@@ -1,174 +0,0 @@
---
-title: 'Setting Up CI'
-description: Configure CI for your Nx workspace with remote caching, affected commands, distributed task execution, and self-healing to keep your pipeline fast and reliable.
-sidebar:
-  label: 'Setting Up CI'
-filter: 'type:Guides'
---
-
-{% llm_copy_prompt title="Tutorial 8/8: Set up CI with Nx Cloud" %}
-Help me set up CI for my Nx workspace.
-
-Connect to Nx Cloud with `nx connect`, generate a CI workflow with `nx g @nx/workspace:ci-workflow`, and walk me through remote caching, affected commands, and self-healing CI.
-
-Stay on-topic: only teach what's covered on this page. Do not introduce concepts from later tutorials.
-
-Tutorial: {pageUrl}
-{% /llm_copy_prompt %}
-
-Connect your workspace to Nx Cloud, generate a CI workflow, and enable remote caching, affected commands, distributed task execution, and self-healing to keep your pipeline fast and reliable.
-
-{% aside type="note" title="Tutorial Series" %}
-
-1. [Crafting your workspace](/docs/getting-started/tutorials/crafting-your-workspace)
-2. [Managing dependencies](/docs/getting-started/tutorials/managing-dependencies)
-3. [Configuring tasks](/docs/getting-started/tutorials/configuring-tasks)
-4. [Running tasks](/docs/getting-started/tutorials/running-tasks)
-5. [Caching](/docs/getting-started/tutorials/caching)
-6. [Understanding your workspace](/docs/getting-started/tutorials/understanding-your-workspace)
-7. [Reducing boilerplate](/docs/getting-started/tutorials/reducing-configuration-boilerplate)
-8. **Setting up CI** (you are here)
-
-{% /aside %}
-
-This tutorial assumes you have a [GitHub account](https://github.com) and [Node.js](https://nodejs.org) v20.19 or later.
-
-## Connect to Nx Cloud
-
-### Don't have a workspace yet?
-
-Create a workspace, GitHub repository, and Nx Cloud connection in one step:
-
-{% call_to_action variant="default" title="Create a new Nx workspace" url="https://cloud.nx.app/create-nx-workspace?utm_source=nx-dev&utm_medium=ci-tutorial&utm_campaign=try-nx-cloud" description="Setup takes less than 2 minutes" /%}
-
-This also generates a CI workflow, so you can skip ahead to [Remote caching](#remote-caching).
-
-### Connect an existing workspace
-
-If you already have an Nx workspace, connect it to Nx Cloud:
-
-{% aside type="note" title="Prerequisites for nx connect" %}
-Your workspace must be pushed to a Git provider (GitHub, GitLab, Bitbucket, or Azure DevOps) before running `nx connect`. After connecting, Nx Cloud opens a PR that adds `nxCloudId` to `nx.json`. Merge this PR before proceeding so CI runs appear on the Nx Cloud dashboard.
-{% /aside %}
-
-```shell
-nx connect
-```
-
-This creates an Nx Cloud account (if you don't have one) and connects your workspace. Once connected, you can see your workspace in your [Nx Cloud organization](https://cloud.nx.app/orgs).
-
-The access token is stored in `nx.json` and should be committed to your repository. It only grants cache read/write access, not admin access to your Nx Cloud organization.
-
-## Generate a CI workflow
-
-If your workspace already has a CI workflow (e.g., `.github/workflows/ci.yml`), skip to [Remote caching](#remote-caching).
-
-Generate a CI workflow for GitHub Actions:
-
-```shell
-nx add @nx/workspace
-nx g @nx/workspace:ci-workflow --ci=github
-```
-
-The `@nx/workspace` package provides the CI workflow generator. Once installed, the generator creates a `.github/workflows/ci.yml` file. It also supports CircleCI, GitLab CI, Azure Pipelines, and Bitbucket Pipelines. Pass a different `--ci` value or run `nx g @nx/workspace:ci-workflow --help` to see all options.
-
-{% aside type="note" title="Generated output may differ" %}
-The generated workflow may differ from the example below depending on your workspace setup and Nx version. The key elements (affected command, remote caching, fix-ci) will be present.
-{% /aside %}
-
-```yaml
-# .github/workflows/ci.yml
-name: CI
-
-on:
-  push:
-    branches:
-      - main
-  pull_request:
-
-permissions:
-  actions: read
-  contents: read
-
-jobs:
-  main:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          filter: tree:0
-          fetch-depth: 0
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: 'npm'
-
-      - run: npm ci
-
-      - run: npx nx affected -t lint test build
-
-      - run: npx nx fix-ci
-        if: always()
-```
-
-This workflow includes several Nx CI features out of the box. The sections below explain each one.
-
-## Remote caching
-
-When Nx Cloud is connected, task results are cached remotely. If a task has already run with the same inputs (on any machine or CI run), the result is replayed instantly instead of running again.
-
-This means:
-
- The second CI run on a PR is faster because unchanged tasks hit the cache
- Developers pulling the latest `main` get cached results from CI
- Build artifacts like `dist/` and test coverage are restored from cache, not recomputed
-
-For more details, see [remote cache (Nx Replay)](/docs/features/ci-features/remote-cache).
-
-## Running only affected tasks
-
-The generated workflow uses `nx affected` instead of `nx run-many`. This compares the PR's changes against the base branch and only runs tasks for projects that could be impacted:
-
-```shell
-nx affected -t lint test build
-```
-
-Nx determines the base and head commits using `NX_BASE` and `NX_HEAD` environment variables. The generated CI workflow configures these automatically through the `fetch-depth: 0` checkout, which gives Nx access to the full git history for comparison.
-
-On a PR, Nx compares the PR branch against `main` (or whatever `defaultBase` is set to in `nx.json`). On a push to `main`, it compares against the previous commit.
-
-For more details, see [affected](/docs/features/ci-features/affected).
-
-## Distributing tasks across machines
-
-For larger workspaces, you can distribute task execution across multiple machines using Nx Agents. Instead of running all tasks on a single CI runner, Nx Cloud coordinates the work across a fleet of agents:
-
-```yaml
-# Add to your CI workflow
- run: npx nx start-ci-run --distribute-on="3 linux-medium-js"
-```
-
-Nx Agents automatically split tasks across the available agents, respecting task dependencies and maximizing parallelism. No configuration changes to your tasks are needed.
-
-For more details, see [distribute task execution (Nx Agents)](/docs/features/ci-features/distribute-task-execution).
-
-## Self-healing CI
-
-The `npx nx fix-ci` command at the end of the workflow enables self-healing CI. When a task fails, Nx Cloud analyzes the failure and suggests a fix that you can apply directly from your editor (via [Nx Console](/docs/getting-started/editor-setup)).
-
-This is useful for catching flaky tests, configuration drift, and other issues that can be auto-remediated without manual debugging.
-
-For more details, see [self-healing CI](/docs/features/ci-features/self-healing-ci).
-
-## Next steps
-
- [Remote cache (Nx Replay)](/docs/features/ci-features/remote-cache): how remote caching works
- [Affected](/docs/features/ci-features/affected): how Nx determines what changed
- [Distribute task execution (Nx Agents)](/docs/features/ci-features/distribute-task-execution): run tasks across multiple machines
- [Self-healing CI](/docs/features/ci-features/self-healing-ci): automatic failure detection and fixes
- [AI integration](/docs/getting-started/ai-setup): enhance CI with AI-powered workflows
-
-{% cards cols=2 %}
-{% card title="Previous: Reducing Configuration Boilerplate" description="Automate task configuration with plugins" url="/docs/getting-started/tutorials/reducing-configuration-boilerplate" /%}
-{% /cards %}
@@ -626,7 +626,7 @@ After this first release, you can remove the `--first-release` flag and just run

 Here are some things you can dive into next:

- [Set up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial) with remote caching and self-healing
+- [Set up CI](/docs/getting-started/setup-ci) with remote caching and self-healing
 - Learn more about the [underlying mental model of Nx](/docs/concepts/mental-model)
 - Learn how to [migrate your existing project to Nx](/docs/guides/adopting-nx/adding-to-existing-project)
 - [Learn more about Nx release for publishing packages](/docs/features/manage-releases)
@@ -5,7 +5,7 @@ sidebar:
  order: 6
 ---

-{% llm_copy_prompt title="Tutorial 6/8: Explore and debug your workspace" %}
+{% llm_copy_prompt title="Tutorial 6/7: Explore and debug your workspace" %}
 Help me explore and debug my Nx workspace.
 Use my existing workspace and projects for hands-on examples.

@@ -29,7 +29,6 @@ As your workspace grows to dozens or hundreds of projects, you need tools to exp
 5. [Caching](/docs/getting-started/tutorials/caching)
 6. **Understanding your workspace** (you are here)
 7. [Reducing boilerplate](/docs/getting-started/tutorials/reducing-configuration-boilerplate)
-8. [Setting up CI](/docs/getting-started/tutorials/self-healing-ci-tutorial)

 {% /aside %}

@@ -0,0 +1,115 @@
+---
+title: Setting Up CI
+description: Connect your Nx workspace to Nx Cloud to enable remote caching and self-healing CI in minutes.
+sidebar:
+  order: 7
+  label: Setting Up CI
+filter: 'type:Guides'
+---
+
+{% llm_copy_prompt title="Set up CI with Nx Cloud" %}
+Help me set up CI for my Nx workspace with remote caching.
+
+Use the terminal-only flow so we stay inside the agent loop. `nx connect` is the browser-based flow and drops us out of the agentic flow, so do not run it. Use `nx-cloud onboard connect-workspace` instead.
+
+Before touching anything, verify the workspace state:
+
+**A. Is Nx installed?**
+
+- Check for `nx.json` and `nx` in `package.json` devDeps.
+- Confirm `node_modules` exists. If not, install deps using the package manager that matches my lockfile (`pnpm install`, `npm install`, or `yarn`).
+- If `nx.json` is missing entirely, ask me before running `npx nx@latest init`.
+
+**B. Do I have common tasks configured?** (sanity check for new workspaces)
+Run `nx show projects` and `nx show project <name>` for one project. If common tasks like `test`, `build`, or `lint` are missing, this is probably a brand-new workspace. Walk me through [Configuring tasks](/docs/getting-started/tutorials/configuring-tasks) before continuing. In an established Nx repo this is almost always fine and you can move on.
+
+**C. Is there an existing CI workflow?**
+
+- **Yes, and it already calls `nx run` or `nx run-many`**: Likely already set up. Confirm with me before changing anything.
+- **Yes, but it calls raw commands** (`npm test`, `npm run build`, `npx jest`, etc.): Work with me to update it. Propose minimal edits swapping raw commands for `nx run-many -t <task>` or `nx run <project>:<task>`, and add a final `npx nx fix-ci` step. Show me the diff and wait for approval before writing.
+- **No**: Run `nx g @nx/workspace:ci-workflow --ci=<provider>`. Detect the provider from `git remote -v` (github.com -> `github`, gitlab.com -> `gitlab`, etc.). Ask me if it is still ambiguous. The generator wires up the CI task runner, remote caching, and `nx fix-ci`.
+
+Then connect to Nx Cloud:
+
+1. Run `npx nx-cloud onboard connect-workspace` and parse the JSON.
+2. If the response includes an `actionRequired` payload (typically GitHub authorization), surface the message and any URLs to me and stop. Do not retry blindly.
+3. Confirm `nxCloudId` is written to `nx.json`. If it is not, surface the JSON error to me instead of retrying.
+
+Stage the generated or edited files but do not commit on my behalf. Stay on topic: this page is about getting remote cache running in CI. For deeper coverage link to {pageUrl} and to [/docs/features/ci-features/remote-cache](/docs/features/ci-features/remote-cache).
+
+Page: {pageUrl}
+{% /llm_copy_prompt %}
+
+Local cache speeds up your machine. Remote cache speeds up everyone's machine, including CI. Connecting your workspace to Nx Cloud is the fastest way to keep CI fast as your repo grows.
+
+## Why connect to Nx Cloud
+
+Most CI runs spend a lot of time with runners sitting half-idle. Nx Cloud uses your task graph to keep them busier, so the same job finishes in less time. For the deeper theory, see [mental model](/docs/concepts/mental-model).
+
+Once connected you get:
+
+- **Cache hits across machines.** Results computed by a teammate or by an earlier CI run are replayed instead of recomputed.
+- **Higher runner utilization.** The orchestrator stacks tasks so big jobs don't strand half a runner idle.
+- **Self-healing CI.** Nx Cloud analyzes failures and proposes fixes you can apply from your editor.
+- **Optional Nx Agents.** Distribute task execution across machines without rewriting your workflow.
+
+## Connect your workspace
+
+{% aside type="note" title="Prerequisites" %}
+Push your workspace to a Git provider (GitHub, GitLab, Bitbucket, or Azure DevOps) before connecting. Nx Cloud uses the remote to identify the workspace.
+{% /aside %}
+
+From your workspace root, run:
+
+```shell
+nx connect
+```
+
+Follow the prompts. `nx connect` opens a PR that adds `nxCloudId` to `nx.json`. Merge it to turn on remote cache, and your CI runs show up on the [Nx Cloud dashboard](https://cloud.nx.app/orgs).
+
+### Terminal-only alternative
+
+There's also a terminal-only flow that skips the browser:
+
+```shell
+npx nx-cloud onboard connect-workspace
+```
+
+This detects the repo from your git remotes, creates or selects an organization, writes `nxCloudId` to `nx.json`, and returns JSON. If GitHub authorization is required, the response contains an `actionRequired` payload instead of failing.
+
+See the [Nx Cloud CLI reference](/docs/reference/nx-cloud-cli) for all `nx-cloud onboard` subcommands.
+
+{% llm_only %}
+Use `npx nx-cloud onboard connect-workspace` to connect the workspace. Do not run `nx connect`: it is the browser-based flow and drops you out of the agent loop.
+{% /llm_only %}
+
+## Make sure CI invokes `nx`
+
+Remote cache only kicks in when CI runs your tasks through `nx`. If your workflow still calls raw commands like `npm test` or `npx jest`, those runs bypass the cache entirely. Swap them for `nx run-many -t <task>` (multiple projects) or `nx run <project>:<task>` (single project), and add `npx nx fix-ci` at the end for self-healing.
+
+If your workspace has been on Nx for a while, this is almost always already done. If you just added Nx (e.g. via `nx init`), your existing CI is probably still calling raw commands and needs updating.
+
+### No CI workflow yet?
+
+Generate one:
+
+```shell
+nx add @nx/workspace
+nx g @nx/workspace:ci-workflow --ci=github
+```
+
+Supported `--ci` values: `github`, `circleci`, `gitlab`, `azure`, `bitbucket-pipelines`. The generator wires up the CI task runner, remote caching, and `nx fix-ci` for self-healing.
+
+```yaml
+# .github/workflows/ci.yml (excerpt)
+- run: npx nx run-many -t lint test build
+- run: npx nx fix-ci
+  if: always()
+```
+
+## Next steps
+
+- [Remote cache (Nx Replay)](/docs/features/ci-features/remote-cache): how remote caching works, security model, eviction
+- [Self-healing CI](/docs/features/ci-features/self-healing-ci): auto-detect failures and propose fixes
+- [Distribute task execution (Nx Agents)](/docs/features/ci-features/distribute-task-execution): scale CI across machines
+- [Setup CI guide](/docs/guides/nx-cloud/setup-ci): end-to-end walkthrough with provider-specific examples