feat(misc): add onboarding a/b testing (#27217)

<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->

## Current Behavior
<!-- This is the behavior we have today -->

The onboarding message during `create-nx-workspace` is not ideal.

## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->

We are A/b testing some options for the `create-nx-workspace` onboarding
message.

## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->

Fixes #

(cherry picked from commit 341f2951a8)

.circleci/config.yml

@@ -86,6 +86,7 @@ jobs:
       NX_E2E_RUN_E2E: 'true'
       NX_CI_EXECUTION_ENV: 'linux'
       NX_CLOUD_DTE_V2: 'true'
+      NX_CLOUD_DTE_SUMMARY: 'true'
     steps:
       - checkout
       - nx/set-shas:
@@ -114,8 +115,7 @@ jobs:
             pnpm nx run-many -t check-imports check-commit check-lock-files check-codeowners documentation --parallel=1 --no-dte &
             pids+=($!)
 
-            (pnpm nx affected --targets=lint,test,build --base=$NX_BASE --head=$NX_HEAD --parallel=3 &&
-            pnpm nx affected --targets=e2e,e2e-ci --base=$NX_BASE --head=$NX_HEAD --parallel=1) &
+            pnpm nx affected --targets=lint,test,build,e2e,e2e-ci --base=$NX_BASE --head=$NX_HEAD --parallel=3 &
             pids+=($!)
 
             for pid in "${pids[@]}"; do

.nx/workflows/agents.yaml

@@ -11,17 +11,17 @@ launch-templates:
       NPM_CONFIG_PREFIX: '/home/workflows/.npm-global'
     init-steps:
       - name: Checkout
-        uses: 'nrwl/nx-cloud-workflows/v3.6/workflow-steps/checkout/main.yaml'
+        uses: 'nrwl/nx-cloud-workflows/v4/workflow-steps/checkout/main.yaml'
       - name: Cache restore
-        uses: 'nrwl/nx-cloud-workflows/v3.6/workflow-steps/cache/main.yaml'
-        env:
-          KEY: 'pnpm-lock.yaml'
-          PATHS: |
+        uses: 'nrwl/nx-cloud-workflows/v4/workflow-steps/cache/main.yaml'
+        inputs:
+          key: 'pnpm-lock.yaml'
+          paths: |
             node_modules
             ~/.cache/Cypress
             ~/.cache/ms-playwright
             ~/.pnpm-store
-          BASE_BRANCH: 'master'
+          base-branch: 'master'
       - name: Install e2e deps
         script: |
           sudo apt-get update

Cargo.lock

@@ -126,9 +126,9 @@ dependencies = [
 
 [[package]]
 name = "async-trait"
-version = "0.1.80"
+version = "0.1.81"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "c6fa2087f2753a7da8cc1c0dbfcf89579dd57458e36769de5ac750b4671737ca"
+checksum = "6e0c28dcc82d7c8ead5cb13beb15405b57b8546e93215673ff8ca0349a028107"
 dependencies = [
  "proc-macro2",
  "quote",
@@ -751,9 +751,9 @@ dependencies = [
 
 [[package]]
 name = "gix-path"
-version = "0.10.7"
+version = "0.10.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "23623cf0f475691a6d943f898c4d0b89f5c1a2a64d0f92bce0e0322ee6528783"
+checksum = "8d23d5bbda31344d8abc8de7c075b3cf26e5873feba7c4a15d916bce67382bd9"
 dependencies = [
  "bstr",
  "gix-trace",
@@ -2287,9 +2287,9 @@ dependencies = [
 
 [[package]]
 name = "time"
-version = "0.3.34"
+version = "0.3.36"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "c8248b6521bb14bc45b4067159b9b6ad792e2d6d754d6c41fb50e29fefe38749"
+checksum = "5dfd88e563464686c916c7e46e623e520ddc6d79fa6641390f2e3fa86e83e885"
 dependencies = [
  "deranged",
  "itoa",
@@ -2310,9 +2310,9 @@ checksum = "ef927ca75afb808a4d64dd374f00a2adf8d0fcff8e7b184af886c3c87ec4a3f3"
 
 [[package]]
 name = "time-macros"
-version = "0.2.17"
+version = "0.2.18"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "7ba3a3ef41e6672a2f0f001392bb5dcd3ff0a9992d618ca761a11c3121547774"
+checksum = "3f252a68540fde3a3877aeea552b832b40ab9a69e318efd078774a01ddee1ccf"
 dependencies = [
  "num-conv",
  "time-core",

community/approved-plugins.json

@@ -488,5 +488,10 @@
     "name": "@huge-nx/conventions",
     "description": "Plugin to generate and manage Nx workspaces by adhering to established workspace conventions.",
     "url": "https://github.com/jogelin/huge-nx"
+  },
+  {
+    "name": "nx-github-pages",
+    "description": "A small Nx plugin to make deploying static projects to GitHub Pages easy.",
+    "url": "https://github.com/agentender/nx-github-pages"
   }
 ]

docs/blog/2023-04-19-nx-cloud-3.md

@@ -90,7 +90,7 @@ Learn more at [enterprise](/enterprise).
 
 Nx Cloud has evolved a lot since we first released it in 2020, and is changing even more in 2023. To better adapt to Nx Cloud being a critical CI tool, we changed our pricing model to be more consistent and predictable for CI workloads.
 
-Nx Cloud’s previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The [new pricing model](https://nx.app/pricing) is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.
+Nx Cloud’s previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The [new pricing model](/pricing) is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.
 
 ![](/blog/images/2023-04-19/bodyimg8.webp)
 
@@ -100,7 +100,7 @@ Finally, the **Enterprise plan** is for companies that want full control over wh
 
 All these changes should allow developers to choose the plan that best suits their needs and budget more easily, ensuring a seamless and transparent experience regarding pricing and subscription management.
 
-Learn more at [https://nx.app/pricing](https://nx.app/pricing).
+Learn more at [https://nx.dev/pricing](/pricing).
 
 ## Coming Next
 

docs/blog/2024-03-20-why-speed-matters.md

@@ -2,7 +2,7 @@
 title: Monorepos - Why Speed Matters
 slug: 'monorepos-why-speed-matters'
 authors: ['Katerina Skroumpelou', 'Jeff Cross']
-tags: nx, nxdevtools, speed, ci
+tags: [nx, nxdevtools, speed, ci]
 cover_image: '/blog/images/2024-03-20/featured_img.png'
 ---
 

docs/blog/2024-03-21-reliable-ci.md

@@ -103,7 +103,7 @@ Nx Cloud introduces an entirely different model. Instead of the graph of VMs, th
 By adding the following line…
 
 ```shell
-npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js"
+npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js"
 ```
 
 ... you are telling Nx Cloud to create five Nx Agents to execute all the tasks from all the commands that will follow.

docs/blog/2024-05-08-nx-19-release.md

@@ -82,7 +82,7 @@ Notice how all tasks are now appropriately grouped in the `E2E (CI)` group!
 
 You can also find the same enhancements in Nx Cloud. Below is a view of all tasks in the [CI pipeline](https://staging.nx.app/runs/ctbAZfiLy3):
 
-[![Grouped e2e tests in Nx Cloud](/blog/images/2024-05-08/nx-cloud-atomizer-groupings.gif)](https://staging.nx.app/runs/ctbAZfiLy3)
+{% video-player src="/documentation/blog/media/2024-05-08/nx-cloud-atomizer-groupings.mp4" alt="Showing the Atomizer in Nx Cloud" link="https://staging.nx.app/runs/ctbAZfiLy3" /%}
 
 Notice how all e2e groups are collapsed by default to give a concise view, while allowing you to expand to see how each individual task is progressing!
 
@@ -160,7 +160,7 @@ Since Nx 18 release, we also started using Project Crystal inside of the Nx repo
 
 You can find a full list of fixes and features applied in this major release [here](https://github.com/nrwl/nx/releases/tag/19.0.0).
 
-[![Changelog for Nx 19](/blog/images/2024-05-08/fixes.gif)](https://github.com/nrwl/nx/releases/tag/19.0.0)
+{% video-player src="/documentation/blog/media/2024-05-08/fixes.mp4" alt="A display listing the Github changelog" /%}
 
 With Project Crystal landed now, we're also adjusting our priorities to place a higher importance on stability. You should see this reflected in Nx 19.
 
@@ -182,7 +182,7 @@ In February, we launched two big enhancements to Nx Cloud: the [Atomizer](/ci/fe
 
 Since then, the Atomizer has received a nice UI update (as we had seen earlier):
 
-[![Grouped e2e tests in Nx Cloud](/blog/images/2024-05-08/nx-cloud-atomizer-groupings.gif)](https://staging.nx.app/runs/ctbAZfiLy3)
+{% video-player src="/documentation/blog/media/2024-05-08/nx-cloud-atomizer-groupings.mp4" alt="Showing the Atomizer in Nx Cloud" link="https://staging.nx.app/runs/ctbAZfiLy3" /%}
 
 Since February, we also revamped our task distribution algorithms. This has resulted in a 5-20% (depending on the repo) increase in both speed and cost efficiency for our users.
 

docs/blog/2024-07-25-nx-19-5-update.md

@@ -0,0 +1,176 @@
+---
+title: 'Nx 19.5: StackBlitz, New Features, And More!!'
+slug: 'nx-19-5-adds-stackblitz-new-features-and-more'
+authors: ['Zack DeRose']
+cover_image: '/blog/images/2024-07-25/nx-19-5-thumbnail.png'
+tags: [nx, release]
+---
+
+## Table of Contents
+
+In this blog post:
+
+- [StackBlitz Support](#stackblitz-support)
+- [NEW: Pattern Support for `targetDefaults`](#new-pattern-support-for-targetdefaults)
+- [NEW: Individual Targets Can Now Opt Out of Parallelism](#new-individual-targets-can-now-opt-out-of-parallelism)
+- [Experimental: Gradle Test Atomization](#experimental-gradle-test-atomization)
+- [Support for React 19 (rc) and Angular 18.1](#support-for-react-19-rc-and-angular-181)
+- [NEW: Nx Cloud Hobby Tier](#new-nx-cloud-hobby-tier)
+- [Automatically Update Nx](#automatically-update-nx)
+- [Monorepo World Conference Speakers to Be Announced Soon!!](#monorepo-world-conference-speakers-to-be-announced-soon)
+
+## StackBlitz Support!!
+
+Nx now has support for Stackblitz. This means that you can create a StackBlitz with a whole Nx Workspace inside of it and run all Nx capabilities from their embedded terminal.
+
+[![Nx Workspace in Stackblitz](/blog/images/2024-07-25/react-app-in-stackblitz.jpg)](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx)
+
+[Check out the example](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx) above - you can use the standard command in the terminal:
+
+```shell
+> nx serve react-app
+```
+
+to develop your application inside of the stackblitz.
+
+We're excited for this as it opens up many interesting use-cases, including easier ways of sharing examples, better opportunities for reproduction of issues or bugs, and potential for us to use embedded examples in our documentation in the future.
+
+Web Assembly (or WASM) is the underlying technology being used here, so in addition to stackblitz any other tools built on a node context should now work as well.
+
+## NEW: Pattern Support for `targetDefaults`
+
+When using the Atomizer features of plugins like [`@nx/playwright`](/nx-api/playwright) and [`@nx/cypress`](/nx-api/cypress), you end up creating tasks with dynamic but predictable names.
+
+![Tasks Created With Atomizer](/blog/images/2024-07-25/e2e-task-names.jpg)
+
+Notice how the `e2e-ci--src/example.spec.ts` and `e2e-ci--src/test.spec.ts` tasks here are created by the `@nx/playwright` plugin based on the playwright spec files present in your workspace.
+
+We've now added pattern matching to `targetDefaults` task names as a way to target these dynamic tasks.
+
+The following will set all such tasks to depend on their `build` task:
+
+```json
+{
+  "targetDefaults": {
+    "e2e-ci--**/*": {
+      "dependsOn": ["build"]
+    }
+  }
+}
+```
+
+Note that our plugins will set sensible configurations here out of the box when creating new workspaces using our generators.
+
+Read more about [reducing configuration with `targetDefaults`](/recipes/running-tasks/reduce-repetitive-configuration#reduce-configuration-with-targetdefaults) and [how you can define task pipelines with `targetDefaults`](/features/run-tasks#defining-a-task-pipeline).
+
+## NEW: Individual Targets Can Now Opt Out of Parallelism
+
+One of our goals in changing the landscape of CI is to make CI more declarative - defining the what rather than the how.
+
+Unfortunately, to accomodate for port collisions on end-to-end test, we've long adjusted our generated ci script to look like this:
+
+```yml
+- run: npx nx affected -t lint test build
+- run: npx nx affected --parallel 1 -t e2e-ci
+```
+
+This is unfortunately more imperative, as we are starting to give instructions on how to run and order your CI, rather than defining what to run in our CI. In addition, these instructions will still run `lint`, `test`, and `build` targets first and wait until they all complete before then running `e2e-ci` - which leaves some inefficiencies on the table.
+
+To address this, all tasks now support a `parallelism` property. By setting this property to `false`, you can now inform the Nx task runner to not attempt to run a certain task in parallel. This way we can define parallelism as a property of a task, and move our task running to be more declarative again.
+
+Both our `@nx/playwright` and `@nx/cypress` plugins will now set `targetDefaults` for atomized tests to turn off `parallelism` from now on:
+
+```json
+{
+  // ...
+  "targetDefaults": {
+    "e2e-**/*": {
+      // ...
+      "parallelism": false
+    }
+  }
+}
+```
+
+This way we can simply run the command:
+
+```shell
+> nx run-many --targets=lint,test,e2e-ci,build
+```
+
+And in CI, Nx Agents will allow all tasks to run in parallel on the same machine, except for the atomized end-to-end tasks, which will only run in isolation.
+
+Learn more about how you can [Parallelize Tasks Across Multiple Machines Using Nx Agents](/ci/intro/tutorials/github-actions#parallelize-tasks-across-multiple-machines-using-nx-agents):
+
+{% youtube
+src="https://youtu.be/0YxcxIR7QU0"
+title="Faster e2e Tests!"
+width="100%" /%}
+
+## Experimental: Gradle Test Atomization
+
+Our new [`@nx/gradle` plugin](/nx-api/gradle) now supports Test Atomization out of the box.
+
+![Gradle Atomized](/blog/images/2024-07-25/gradle-atomized.jpg)
+
+This means that as you add tests in your gradle projects, we'll automatically create a new task for each test class, allowing you to distribute the execution of these tasks in your CI pipeline, just like with our `@nx/playwright` and `@nx/cypress` plugins.
+
+## Support for React 19 (rc) and Angular 18.1
+
+Nx 19.5 adds support for the React 19 release candidate and updated our Angular package to support the latest Angular minor version: 18.1.
+
+When using our `@nx/angular` package, we'll automatically update you to the latest angular version when you run our migration. Using the `--interactive` flag you can choose to opt in or out of the latest Angular version:
+
+```shell
+> nx migrate latest --interactive
+✔ Do you want to update to TypeScript v5.5? (Y/n) · true
+✔ Do you want to update the Angular version to v18.1? (Y/n) · true
+Fetching @angular/core@18.1.2
+
+ NX   The migrate command has run successfully.
+```
+
+Our `@nx/react` package will now create new React applications using version 18.3, and we now support the new experimental `reactCompiler`. Users can install the [`babel-plugin-react-compiler` package](https://www.npmjs.com/package/babel-plugin-react-compiler) and you can follow [this guide for how to enable it with Nx](/recipes/react/react-compiler#react-compiler-with-nx).
+
+Note that due to the extent of breaking changes coming with React 19, we will not be providing a automated migration to React 19 via [`nx migrate`](/nx-api/nx/documents/migrate).
+
+## Automatically Update Nx
+
+As always - updating Nx and its plugins is easy as we ship an [automated migration command](/features/automate-updating-dependencies).
+
+```shell
+npx nx migrate latest
+```
+
+After updating your dependencies, run any necessary migrations.
+
+```shell
+npx nx migrate --run-migrations
+```
+
+## NEW: Nx Cloud Hobby Tier
+
+Our new expanded Hobby Tier now adds trial support for all features AND includes credits to run Nx Agents.
+
+Sample the entire suite of features to see its impact on your organization. Start with everything, scale when you need more.
+
+[![Nx Cloud Tiers](/blog/images/2024-07-25/start-with-everything-scale-when-you-need.jpg)](/pricing#plan-details)
+
+Checkout the [plan details page](/pricing#plan-details) for more info, and see how Nx Cloud can help you!
+
+## Monorepo World Conference Speakers to Be Announced Soon!!
+
+[![Monorepo World](/blog/images/2024-07-25/monorepo-world.jpg)](https://monorepo.world)
+
+The [Monorepo World conference](https://monorepo.world) is coming up soon on October 7, 2024 at the Computer History museum in Mountain View, California.
+
+[Get your tickets now](https://ti.to/nx-conf/monorepoworld2024), consider [requesting access to the invite-only Enterprise Summit on October 8](https://ti.to/nx-conf/monorepoworld2024), and be sure to stay tuned as we'll be announcing speakers soon!
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](https://go.nx.dev/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)

docs/blog/2024-07-29-explain-with-ai.md

@@ -0,0 +1,55 @@
+---
+title: Introducing Explain with AI
+slug: 'explain-with-ai'
+authors: ['Philip Fulcher']
+cover_image: '/blog/images/2024-07-29/explain-with-ai-header.avif'
+tags: [nx, nx-cloud, ai, release]
+---
+
+It's Friday, and you absolutely, positively have to deploy to production. But you can't get CI to pass your PR. What do you do? It's an inevitable part of your life as a developer, and you've built a collection of tools to deal with it: Google, MDN, Discord, ChatGPT. We've got one more tool for your toolbox: **"Explain with AI" for [Nx Cloud](/nx-cloud)**.
+
+## Your ticket to fast error debugging
+
+"Explain with AI" is a new feature for all Nx Cloud Pro users that is going to help you troubleshoot those pesky failing tasks. Whenever you get an error message on CI, look for the "Explain with AI" button on the upper right-hand corner:
+
+![Nx Cloud error log window](/blog/images/2024-07-29/explain-with-ai-1.avif)
+
+Once you hit that button, we collect the terminal output and other Nx task information and sprinkle some AI on top of it to give you a suggested fix. That should help you quickly get to the bottom of the issue and get back to work quickly.
+
+![Explain with AI explaining how to resolve the CI error](/blog/images/2024-07-29/explain-with-ai-2.avif)
+
+No more switching back and forth between a dozen tabs with different solutions. No more providing the right context for your masterfully written chat prompt. **Get your suggested fix and get back to work.**
+
+## How can I start using this today?
+
+![Nx Cloud organization settings section for enabling AI features](/blog/images/2024-07-29/ai-features.avif)
+
+Here's how you get started:
+
+- **Step 1:** Go to your [Nx Cloud](https://cloud.nx.app/) organization settings
+- **Step 2:** Enable AI features
+- **Step 3:** Accept the Nx Cloud AI terms and conditions.
+- **Step 4:** You're all set ✨
+
+Note that you'll need to be an organization admin for your Nx Cloud workspace to enable AI features.
+
+{% call-to-action title="Log in to Nx Cloud" url="https://cloud.nx.app" icon="nxcloud" description="Enable AI features in your organization settings" %}
+Log in to Nx Cloud
+{% /call-to-action %}
+
+### I want to try this, but I'm on the Hobby plan 🤔
+
+If you're currently on the Hobby plan, you can start a free Pro plan trial for 14 days to try it out on your own workspace. No, we don't ask for credit cards to start a trial, so feel free to experiment!
+
+## More to come!
+
+This is just the first of a series of AI-powered features that we're going to be rolling out to your workspaces. We've got some cool features in the works already, which we're going to **announce publicly during the [Monorepo World](https://monorepo.world) conference in October**! So stay tuned!
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](https://go.nx.dev/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)

docs/blog/authors.json

@@ -52,5 +52,11 @@
     "image": "/blog/images/Jeff Cross.jpeg",
     "twitter": "jeffbcross",
     "github": "jeffbcross"
+  },
+  {
+    "name": "Philip Fulcher",
+    "image": "/blog/images/Philip Fulcher.jpeg",
+    "twitter": "philipjfulcher",
+    "github": "philipjfulcher"
   }
 ]

docs/changelog/19_5_0.md

@@ -0,0 +1,18 @@
+# Nx 19.5 Adds StackBlitz, New Features, And More!!
+
+[![Nx 19.5 Adds StackBlitz, New Features, And More!!](/blog/images/2024-07-25/nx-19-5-thumbnail.png)](/blog/nx-19-5-adds-stackblitz-new-features-and-more)
+
+Read the [blogpost](/blog/nx-19-5-adds-stackblitz-new-features-and-more) for full details.
+
+## Features
+
+{% cards cols="2" %}
+{% card title="Stackblitz Support" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#stackblitz-support" /%}
+{% card title="NEW: Pattern Support for `targetDefaults`" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#new-pattern-support-for-targetdefaults" /%}
+{% card title="NEW: Individual Targets Can Now Opt Out of Parallelism" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#new-individual-targets-can-now-opt-out-of-parallelism" /%}
+{% card title="Experimental: Gradle Test Atomization" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#experimental-gradle-test-atomization" /%}
+{% card title="Support for React 19 (rc) and Angular 18.1" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#support-for-react-19-rc-and-angular-181" /%}
+{% card title="NEW: Nx Cloud Hobby Tier" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#new-nx-cloud-hobby-tier" /%}
+{% card title="Monorepo World Conference Speakers to Be Announced Soon!!" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#monorepo-world-conference-speakers-to-be-announced-soon" /%}
+
+{% /cards %}

docs/generated/cli/reset.md

@@ -55,6 +55,12 @@ Type: `boolean`
 
 Clears the Nx cache directory. This will remove all local cache entries for tasks, but will not affect the remote cache.
 
+### onlyCloud
+
+Type: `boolean`
+
+Resets the Nx Cloud client. NOTE: Does not clear the remote cache.
+
 ### onlyDaemon
 
 Type: `boolean`

docs/generated/cli/show.md

@@ -29,6 +29,12 @@ Show all projects with names starting with "api-". The "projects" option is usef
  nx show projects --projects api-*
 ```
 
+Show all projects with a tag starting with "ui-". The "projects" option is useful to see which projects would be selected by run-many:
+
+```shell
+ nx show projects --projects tag:ui-*
+```
+
 Show all projects with a serve target:
 
 ```shell

docs/generated/devkit/ToJSOptions.md

@@ -4,8 +4,9 @@
 
 #### Type declaration
 
-| Name        | Type                            |
-| :---------- | :------------------------------ |
-| `extension` | `".js"` \| `".mjs"` \| `".cjs"` |
-| `module?`   | `ModuleKind`                    |
-| `target?`   | `ScriptTarget`                  |
+| Name         | Type                            |
+| :----------- | :------------------------------ |
+| `extension?` | `".js"` \| `".mjs"` \| `".cjs"` |
+| `module?`    | `ModuleKind`                    |
+| `target?`    | `ScriptTarget`                  |
+| `useJsx?`    | `boolean`                       |

docs/generated/manifests/ci.json

@@ -721,17 +721,6 @@
                 "path": "/ci/recipes/enterprise/on-premise/auth-saml",
                 "tags": []
               },
-              {
-                "id": "auth-saml-managed",
-                "name": "Authenticate via SAML on Managed Version",
-                "description": "",
-                "mediaImage": "",
-                "file": "nx-cloud/enterprise/on-premise/auth-saml-managed",
-                "itemList": [],
-                "isExternal": false,
-                "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-                "tags": []
-              },
               {
                 "id": "advanced-config",
                 "name": "Advanced Configuration",
@@ -1305,17 +1294,6 @@
             "path": "/ci/recipes/enterprise/on-premise/auth-saml",
             "tags": []
           },
-          {
-            "id": "auth-saml-managed",
-            "name": "Authenticate via SAML on Managed Version",
-            "description": "",
-            "mediaImage": "",
-            "file": "nx-cloud/enterprise/on-premise/auth-saml-managed",
-            "itemList": [],
-            "isExternal": false,
-            "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-            "tags": []
-          },
           {
             "id": "advanced-config",
             "name": "Advanced Configuration",
@@ -1521,17 +1499,6 @@
         "path": "/ci/recipes/enterprise/on-premise/auth-saml",
         "tags": []
       },
-      {
-        "id": "auth-saml-managed",
-        "name": "Authenticate via SAML on Managed Version",
-        "description": "",
-        "mediaImage": "",
-        "file": "nx-cloud/enterprise/on-premise/auth-saml-managed",
-        "itemList": [],
-        "isExternal": false,
-        "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-        "tags": []
-      },
       {
         "id": "advanced-config",
         "name": "Advanced Configuration",
@@ -1647,17 +1614,6 @@
     "path": "/ci/recipes/enterprise/on-premise/auth-saml",
     "tags": []
   },
-  "/ci/recipes/enterprise/on-premise/auth-saml-managed": {
-    "id": "auth-saml-managed",
-    "name": "Authenticate via SAML on Managed Version",
-    "description": "",
-    "mediaImage": "",
-    "file": "nx-cloud/enterprise/on-premise/auth-saml-managed",
-    "itemList": [],
-    "isExternal": false,
-    "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-    "tags": []
-  },
   "/ci/recipes/enterprise/on-premise/advanced-config": {
     "id": "advanced-config",
     "name": "Advanced Configuration",

docs/generated/manifests/menus.json

@@ -5677,14 +5677,6 @@
                     "children": [],
                     "disableCollapsible": false
                   },
-                  {
-                    "name": "Authenticate via SAML on Managed Version",
-                    "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-                    "id": "auth-saml-managed",
-                    "isExternal": false,
-                    "children": [],
-                    "disableCollapsible": false
-                  },
                   {
                     "name": "Advanced Configuration",
                     "path": "/ci/recipes/enterprise/on-premise/advanced-config",
@@ -6103,14 +6095,6 @@
                 "children": [],
                 "disableCollapsible": false
               },
-              {
-                "name": "Authenticate via SAML on Managed Version",
-                "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-                "id": "auth-saml-managed",
-                "isExternal": false,
-                "children": [],
-                "disableCollapsible": false
-              },
               {
                 "name": "Advanced Configuration",
                 "path": "/ci/recipes/enterprise/on-premise/advanced-config",
@@ -6260,14 +6244,6 @@
             "children": [],
             "disableCollapsible": false
           },
-          {
-            "name": "Authenticate via SAML on Managed Version",
-            "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-            "id": "auth-saml-managed",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
           {
             "name": "Advanced Configuration",
             "path": "/ci/recipes/enterprise/on-premise/advanced-config",
@@ -6351,14 +6327,6 @@
         "children": [],
         "disableCollapsible": false
       },
-      {
-        "name": "Authenticate via SAML on Managed Version",
-        "path": "/ci/recipes/enterprise/on-premise/auth-saml-managed",
-        "id": "auth-saml-managed",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
       {
         "name": "Advanced Configuration",
         "path": "/ci/recipes/enterprise/on-premise/advanced-config",

docs/generated/packages/cypress/documents/overview.md

@@ -56,9 +56,7 @@ The `@nx/cypress` plugin will create a task for any project that has a Cypress c
 - `cypress.config.js`
 - `cypress.config.ts`
 - `cypress.config.mjs`
-- `cypress.config.mts`
 - `cypress.config.cjs`
-- `cypress.config.cts`
 
 ### View Inferred Tasks
 

docs/generated/packages/js/executors/tsc.json

@@ -40,6 +40,11 @@
         "x-completion-type": "directory",
         "x-priority": "important"
       },
+      "outputFileName": {
+        "type": "string",
+        "description": "The path to the main file relative to the outputPath",
+        "x-completion-type": "file"
+      },
       "tsConfig": {
         "type": "string",
         "description": "The path to the Typescript configuration file.",

docs/generated/packages/js/executors/verdaccio.json

@@ -23,6 +23,10 @@
         "type": "number",
         "description": "Port of local registry that Verdaccio should listen to"
       },
+      "listenAddress": {
+        "type": "string",
+        "description": "Listen address that Verdaccio should listen to"
+      },
       "config": {
         "type": "string",
         "description": "Path to the custom Verdaccio config file"
@@ -31,6 +35,11 @@
         "type": "boolean",
         "description": "Clear local registry storage before starting Verdaccio",
         "default": true
+      },
+      "scopes": {
+        "type": "array",
+        "description": "Scopes to be added to the Verdaccio config",
+        "items": { "type": "string" }
       }
     },
     "required": ["port"],

docs/generated/packages/nest/documents/overview.md

@@ -150,6 +150,26 @@ You can lint a library with the following command:
 nx lint my-nest-lib
 ```
 
+## Deployment
+
+Ensuring a smooth and reliable deployment of a Nest.js application in a production environment requires careful planning and the right strategy. Depending on your specific needs and infrastructure, you can choose from several deployment approaches. Below are four commonly used methods:
+
+1. **Using Docker:**
+   Create a Dockerfile that specifies the application's environment and dependencies. Build a Docker image and optionally push it to a container registry. Deploy and run the Docker container on the server. Utilize the `@nx/node:setup-docker` generator to streamline the Docker setup process.
+
+2. **Installing Dependencies on the Server:**
+   Transfer the build artifacts to the server, install all dependencies using the package manager of your choice, and start the application. Ensure that [NxAppWebpackPlugin](/recipes/webpack/webpack-plugins#nxappwebpackplugin) is configured with `generatePackageJson: true` so that the build artifacts directory includes `package.json` and `package-lock.json` (or the equivalent files for other package managers).
+
+3. **Transferring Pre-installed Dependencies:**
+   Install dependencies during the build process, and transfer the build artifacts along with the `node_modules` directory to the server. Typically, the artifacts are archived for faster transfer and then unarchived on the server.
+
+4. **Bundling Dependencies:**
+   By default, Nx/Nest creates a setup that externalizes all dependencies, meaning they are not included in the bundle. This behavior can be adjusted using the `externalDependencies` parameter in the webpack configuration with [NxAppWebpackPlugin](/recipes/webpack/webpack-plugins#nxappwebpackplugin). After bundling, transfer the package to the server and start the application.
+
+{% callout type="note" title="Bundling Dependencies" %}
+Bundling dependencies is typically not recommended for Node applications.
+{% /callout %}
+
 ### Unit Test
 
 You can run unit test for an application with the following command:

docs/generated/packages/nx/documents/reset.md

@@ -55,6 +55,12 @@ Type: `boolean`
 
 Clears the Nx cache directory. This will remove all local cache entries for tasks, but will not affect the remote cache.
 
+### onlyCloud
+
+Type: `boolean`
+
+Resets the Nx Cloud client. NOTE: Does not clear the remote cache.
+
 ### onlyDaemon
 
 Type: `boolean`

docs/generated/packages/nx/documents/show.md

@@ -29,6 +29,12 @@ Show all projects with names starting with "api-". The "projects" option is usef
  nx show projects --projects api-*
 ```
 
+Show all projects with a tag starting with "ui-". The "projects" option is useful to see which projects would be selected by run-many:
+
+```shell
+ nx show projects --projects tag:ui-*
+```
+
 Show all projects with a serve target:
 
 ```shell

docs/generated/packages/react/generators/host.json

@@ -171,6 +171,12 @@
         "type": "boolean",
         "description": "Whether the module federation configuration and webpack configuration files should use TS. When --js is used, this flag is ignored.",
         "default": true
+      },
+      "skipPackageJson": {
+        "description": "Do not add dependencies to `package.json`.",
+        "type": "boolean",
+        "default": false,
+        "x-priority": "internal"
       }
     },
     "required": ["name"],

docs/generated/packages/react/generators/remote.json

@@ -170,6 +170,12 @@
         "type": "boolean",
         "description": "Whether the module federation configuration and webpack configuration files should use TS. When --js is used, this flag is ignored.",
         "default": true
+      },
+      "skipPackageJson": {
+        "description": "Do not add dependencies to `package.json`.",
+        "type": "boolean",
+        "default": false,
+        "x-priority": "internal"
       }
     },
     "required": ["name"],

docs/map.json

@@ -1818,11 +1818,6 @@
                       "id": "auth-saml",
                       "file": "nx-cloud/enterprise/on-premise/auth-saml"
                     },
-                    {
-                      "name": "Authenticate via SAML on Managed Version",
-                      "id": "auth-saml-managed",
-                      "file": "nx-cloud/enterprise/on-premise/auth-saml-managed"
-                    },
                     {
                       "name": "Advanced Configuration",
                       "id": "advanced-config",

docs/nx-cloud/enterprise/dte/azure-dte.md

@@ -57,7 +57,7 @@ jobs:
 
       - script: git branch --track main origin/main
       - script: npm ci
-      - script: npx nx-cloud start-ci-run --stop-agents-after="e2e-ci"
+      - script: npx nx-cloud start-ci-run --distribute-on="manual" --stop-agents-after="e2e-ci"
       - script: npx nx-cloud record -- nx format:check --base=$(BASE_SHA) --head=$(HEAD_SHA)
       - script: npx nx affected --base=$(BASE_SHA) --head=$(HEAD_SHA) -t lint,test,build,e2e-ci --parallel=2 --configuration=ci
 ```

docs/nx-cloud/enterprise/dte/bitbucket-dte.md

@@ -33,7 +33,7 @@ pipelines:
                 - export NX_CLOUD_DISTRIBUTED_EXECUTION_AGENT_COUNT=3
 
                 - npm ci
-                - npx nx-cloud start-ci-run --stop-agents-after="e2e-ci" --agent-count=3
+                - npx nx-cloud start-ci-run --distribute-on="manual" --stop-agents-after="e2e-ci" --agent-count=3
                 - npx nx-cloud record -- nx format:check
                 - npx nx affected --target=lint,test,build,e2e-ci --parallel=2
           - step: *agent

docs/nx-cloud/enterprise/dte/circle-ci-dte.md

@@ -22,7 +22,7 @@ jobs:
       - nx/set-shas
 
       # Tell Nx Cloud to use DTE and stop agents when the e2e-ci tasks are done
-      - run: npx nx-cloud start-ci-run --stop-agents-after=e2e-ci
+      - run: npx nx-cloud start-ci-run --distribute-on="manual" --stop-agents-after=e2e-ci
       # Send logs to Nx Cloud for any CLI command
       - run: npx nx-cloud record -- nx format:check
       # Lint, test, build and run e2e on agent jobs for everything affected by a change

docs/nx-cloud/enterprise/dte/github-dte.md

@@ -67,7 +67,7 @@ jobs:
         run: git branch --track main origin/main
 
       - name: Initialize the Nx Cloud distributed CI run and stop agents when the build tasks are done
-        run: npx nx-cloud start-ci-run --stop-agents-after=e2e-ci
+        run: npx nx-cloud start-ci-run --distribute-on="manual" --stop-agents-after=e2e-ci
 
       - name: Run commands in parallel
         run: |

docs/nx-cloud/enterprise/dte/gitlab-dte.md

@@ -50,7 +50,7 @@ nx-dte:
   stage: affected
   extends: .base-pipeline
   script:
-    - yarn nx-cloud start-ci-run --stop-agents-after=e2e-ci
+    - yarn nx-cloud start-ci-run --distribute-on="manual" --stop-agents-after=e2e-ci
     - yarn nx-cloud record -- nx format:check --base=$NX_BASE --head=$NX_HEAD
     - yarn nx affected --base=$NX_BASE --head=$NX_HEAD -t lint,test,build,e2e-ci --parallel=2
 

docs/nx-cloud/enterprise/dte/jenkins-dte.md

@@ -23,7 +23,7 @@ pipeline {
                     agent any
                     steps {
                         sh "npm ci"
-                        sh "npx nx-cloud start-ci-run --stop-agents-after='e2e-ci'"
+                        sh "npx nx-cloud start-ci-run --distribute-on='manual' --stop-agents-after='e2e-ci'"
                         sh "npx nx-cloud record -- nx format:check"
                         sh "npx nx affected --base=HEAD~1 -t lint,test,build,e2e-ci --configuration=ci --parallel=2"
                     }
@@ -35,7 +35,7 @@ pipeline {
                     agent any
                     steps {
                         sh "npm ci"
-                        sh "npx nx-cloud start-ci-run --stop-agents-after='e2e-ci'"
+                        sh "npx nx-cloud start-ci-run --distribute-on='manual' --stop-agents-after='e2e-ci'"
                         sh "npx nx-cloud record -- nx format:check"
                         sh "npx nx affected --base origin/${env.CHANGE_TARGET} -t lint,test,build,e2e-ci --parallel=2 --configuration=ci"
                     }

docs/nx-cloud/enterprise/on-premise/auth-saml-managed.md

@@ -1,67 +0,0 @@
-# SAML Auth Managed Offering
-
-## Okta Set-up
-
-You'll need the `SAML-IDENTIFIER` from us, unique to your org. We'll provide this once we start setting SAML up for you.
-You'll be entering it in the instructions below.
-
-1. Create a new Okta App Integration:
-
-   ![Okta 1](/nx-cloud/enterprise/on-premise/images/saml/okta_1.png)
-
-   ![Okta 2](/nx-cloud/enterprise/on-premise/images/saml/okta_2.png)
-
-2. Give it a name:
-
-   ![Okta 3](/nx-cloud/enterprise/on-premise/images/saml/okta_3.png)
-
-3. On the Next page, configure it as below:
-
-   1. The Single Sign On URL needs to be:
-      - If using the main-US cluster: `https://auth.nx.app/login/callback?connection=SAML-IDENTIFIER`
-   2. The Audience should be `urn:auth0:nrwl:SAML-IDENTIFIER`
-      - If using the main-US cluster: `urn:auth0:nrwl:SAML-IDENTIFIER`
-
-{% callout type="note" title="EU Cluster" %}
-Contact your developer productivity engineer (DPE) to configure SAML auth in the EU cluster. The EU cluster is only available for enterprise customers.
-{% /callout %}
-
-![Okta 4](/nx-cloud/enterprise/on-premise/images/saml/okta_4_public.png)
-
-4. Scroll down to attribute statements and configure them as per below:
-
-   ![Okta 5](/nx-cloud/enterprise/on-premise/images/saml/okta_5.png)
-
-5. Click “Next”, and select the first option on the next screen.
-6. Go to the assignments tab and assign the users that can login to the Nx Cloud WebApp:
-
-   1. **Note:** This just gives them permission to use the Nx Cloud web app with their own workspace. Users will still need to be invited manually through the web app to your main workspace.
-
-   ![Okta 6](/nx-cloud/enterprise/on-premise/images/saml/okta_6.png)
-
-7. Then in the Sign-On tab scroll down:
-
-   ![Okta 7](/nx-cloud/enterprise/on-premise/images/saml/okta_7.png)
-
-8. Scroll down and from the list of certificates, download the one with the “Active” status:
-
-   ![Okta 8](/nx-cloud/enterprise/on-premise/images/saml/okta_8.png)
-
-9. Then view the ldP metadata:
-
-   ![Okta 9](/nx-cloud/enterprise/on-premise/images/saml/okta_9.png)
-
-10. Then find the row similar to the below, and copy the highlighted URL (see screenshot as well):
-
-    1. ```html
-       <md:SingleSignOnService
-         Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
-         Location="https://trial-xxxxx.okta.com/app/trial-xxxxx_nxcloudtest_1/xxxxxxxxx/sso/saml"
-       />
-       ```
-
-    ![Okta 10](/nx-cloud/enterprise/on-premise/images/saml/okta_10.png)
-
-11. Send us via email:
-    - your _public_ certificate downloaded in step 8
-    - your URL from step 10

docs/nx-cloud/enterprise/on-premise/auth-saml.md

@@ -6,7 +6,7 @@ if you are interested.
 ### Jump To
 
 - [Azure AD Config](#azure-active-directory-set-up)
-- [Okta Config](#okta-set-up)
+- [Okta Config](#okta-setup)
 
 ## Azure Active Directory Set-up
 
@@ -88,7 +88,7 @@ if you are interested.
 
 3. On the Next page, configure it as below:
 
-   1. The Single Sign On URL needs to point to your Nx Cloud instance URL and ends with `/auth/saml/callback`
+   1. The Single Sign On URL needs to point to your Nx Cloud instance URL and ends with `/auth-callback`
    2. The Audience should be `nx-private-cloud`
 
    ![Okta 4](/nx-cloud/enterprise/on-premise/images/saml/okta_4.png)

docs/nx-cloud/features/split-e2e-tasks.md

@@ -7,11 +7,11 @@ width="100%" /%}
 
 In almost every codebase, e2e tests are the largest portion of the CI pipeline. Typically, e2e tests are grouped by application so that whenever an application's code changes, all the e2e tests for that application are run. These large groupings of e2e tests make caching and distribution less effective. Also, because e2e tests deal with a lot of integration code, they are at a much higher risk to be flaky.
 
-You could manually address these problems by splitting your e2e tests into smaller tasks, but this requires developer time to maintain and adds additional configuration overhead to your codebase. Or, you could allow Nx to automatically split your Cypress or Playwright e2e tests by file.
+You could manually address these problems by splitting your e2e tests into smaller tasks, but this requires developer time to maintain and adds additional configuration overhead to your codebase. Or, you could allow Nx to automatically split your e2e tests by file. Doing this will split your large e2e tasks into smaller, atomized tasks.
 
 ## Set up
 
-To enable automatically split e2e tasks, you need to turn on [inferred tasks](/concepts/inferred-tasks#existing-nx-workspaces) for the [@nx/cypress](/nx-api/cypress), [@nx/playwright](/nx-api/playwright), or [@nx/jest](/nx-api/jest) plugins. Run this command to set up inferred tasks:
+To enable atomized tasks, you need to turn on [inferred tasks](/concepts/inferred-tasks#existing-nx-workspaces) for the [@nx/cypress](/nx-api/cypress), [@nx/playwright](/nx-api/playwright), [@nx/jest](/nx-api/jest) or [@nx/gradle](/nx-api/gradle) plugins. Run this command to set up inferred tasks:
 
 {% tabs %}
 {% tab label="Cypress" %}
@@ -394,3 +394,10 @@ With more granular e2e tasks, all the other features of Nx become more powerful.
 ### More Precise Flaky Task Identification
 
 Nx Agents [automatically re-run failed flaky e2e tests](/ci/features/flaky-tasks) on a separate agent without a developer needing to manually re-run the CI pipeline. Leveraging e2e task splitting, Nx identifies the specific flaky test file - this way you can quickly fix the offending test file. Without e2e splitting, Nx identifies that at least one of the e2e tests are flaky - requiring you to find the flaky test on your own.
+
+## Nx Cloud is Required to Run Atomized Tasks!
+
+Running a group of atomized tasks on a single machine takes longer than running the large e2e task.
+Nx Cloud [distributes](/ci/features/distribute-task-execution) the atomized tasks across multiple Nx agents in parallel.
+
+When running locally or if you cannot use Nx Agents, it's better to use the non-atomized target instead (`e2e` in the example above).

docs/nx-cloud/reference/launch-templates.md

@@ -59,7 +59,7 @@ The following resource classes are available:
 - `docker_linux_arm64/extra_large`
 - `windows/medium`
 
-See their detailed description and pricing at [nx.app/pricing](https://nx.app/pricing#plan-detail?sutm_source=nx.dev&utm_medium=launch-templates).
+See their detailed description and pricing at [nx.dev/pricing](/pricing#plan-detail?sutm_source=nx.dev&utm_medium=launch-templates).
 
 ### `launch-templates.<template-name>.image`
 

docs/nx-cloud/reference/nx-cloud-cli.md

@@ -21,7 +21,7 @@ Tells Nx Cloud how many agents to use (and what launch templates to use) to dist
 using the `linux-medium-js` launch template.
 
 You can use different types of launch templates as follows:
-`npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js, 3 linux-large-js"`.
+`npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js, 3 linux-large-js"`.
 
 You can also define the configuration in a file and reference it as follows:
 `npx nx-cloud start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yaml"`.

docs/nx-cloud/reference/release-notes.md

@@ -1,5 +1,39 @@
 # Enterprise Release Notes
 
+### 2406.29.1
+
+##### Full terminal outputs in the web app
+
+Due to storage constraints in Mongo, long terminal outputs were sometimes truncated when viewed in the UI. With this update we are now loading all terminal outputs directly
+from the storage bucket, removing the need to keep them in Mongo. You should now be able to view full, complete logs in the UI regardless of how large the output is.
+
+##### OpenShift fixes for Agents
+
+- the latest messagequeue image is now OpenShift ready
+  - to use, just update to the latest Helm version `0.15.6` and make sure you are not passing in an explicit tag for the messagequeue
+  - then use version `2406.29.1` for NxCloud. This should use the latest, OpenShift enabled messagequeue image
+- when running Agents on OpenShift, they run as a specific user with ID 1000
+  - to override this, make sure to set `NX_CLOUD_RUN_UNIX_PODS_AS_USER: <userId>` and `NX_CLOUD_RUN_UNIX_PODS_AS_GROUP: <groupId>` on the [workflow controller env vars](https://github.com/nrwl/nx-cloud-helm/blob/main/charts/nx-agents/values.yaml#L63)
+
+##### Full Bitbucket Data Center (on-prem)
+
+We now have full support for BitBucket Data Center (self-hosted):
+
+- VCS integration for posting comments with live updates about your CI runs
+- full agents integration
+- more info about each one of your commits on the NxCloud web app
+- you can even [set-up auth with BitBucket Data Center](/ci/recipes/enterprise/on-premise/auth-bitbucket-data-center#bitbucket-data-center-auth)
+
+##### Misc
+
+- easier workspace setup experience for new customers
+- the CIPE visualisation has been updated (elapsed task time)
+- general web app performance improvements
+
+##### Breaking changes
+
+If you are using DTE, you will now need to pass the `--distribute-on="manual"` flag to your `npx nx-cloud start-ci-run` commands.
+
 ### 2405.02.15
 
 ##### Easy membership management via GitHub

docs/nx-cloud/tutorial/circle.md

@@ -5,14 +5,12 @@ description: In this tutorial you'll set up continuous integration with Circle C
 
 # Circle CI with Nx
 
-In this tutorial we're going to learn how to leverage Nx to setup a scalable CI pipeline on Circle CI. You're going to learn
+In this tutorial we're going to learn how to leverage Nx to setup a scalable CI pipeline on Circle CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
 
-- how to set up Circle CI and configure Nx
-- how to run tasks for only the projects that were affected by a given PR
-- how to enable remote caching
-- how to parallelize and distribute tasks across multiple machines
-
-Note, many of these optimizations are incremental, meaning you could set up running tasks for only affected projects and stop there. Later when you experience slow CI runs, you could add caching to further improve CI performance or even go further and distribute tasks across machines.
+- Nx reduces wasted time in CI with the [`affected` command](/ci/features/affected).
+- Nx Replay's [remote caching](/ci/features/remote-cache) will reuse task artifacts from different CI executions making sure you will never run the same computation twice.
+- Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
+- Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
 
 ## Example Repository
 
@@ -31,7 +29,7 @@ To get started:
 1. [Fork the nx-shop repo](https://github.com/nrwl/nx-shops/fork) and then clone it to your local machine
 
    ```shell
-   git clone git@github.com:<your-username>/nx-shops.git
+   git clone https://github.com/<your-username>/nx-shops.git
    ```
 
 2. Install dependencies (this repo uses [PNPM](https://pnpm.io/) but you should be able to also use any other package manager)
@@ -40,41 +38,80 @@ To get started:
    pnpm i
    ```
 
-3. Explore the structure of the repo using **the Nx Graph**
+3. Make sure all tasks are working on your machine, by running lint, test, build and e2e on all projects of the workspace
 
    ```shell
-   pnpm nx graph
+   pnpm nx run-many -t lint test build
    ```
 
-4. Finally, make sure all task are working on your machine, by running lint, test, build and e2e on all projects of the workspace
+## Connect to Circle CI
 
-   ```shell
-   pnpm nx run-many -t lint test build e2e-ci
-   ```
+In order to use Circle CI, you need to [sign up and create an organization](https://circleci.com/docs/first-steps/#sign-up-and-create-an-org). Follow the steps in the Circle CI documentation to connect to your GitHub repository to a project.
 
-## Set Up Circle CI
+![](/nx-cloud/tutorial/circle-setup-project.avif)
 
-In order to use Circle CI, you need to [sign up and create an organization](https://circleci.com/docs/first-steps/#sign-up-and-create-an-org). Follow the steps in the Circle CI documentation to connect to your GitHub repository. When you are asked to configure a pipeline, choose any option, since we'll overwrite it in the next step.
+The easiest way is to create a branch and PR in your GitHub repository. Note that a sample pipeline workflow file will be created, which we will overwrite in the next step.
 
-To verify that Circle CI is set up correctly we'll create a pipeline that just logs a message. First, checkout a new branch:
+![](/nx-cloud/tutorial/circle-create-pr.avif)
+
+Once the PR is created, merge it into your main branch.
+
+![](/nx-cloud/tutorial/circle-pr.avif)
+
+And pull the changes locally:
 
 ```shell
-git checkout -b circle-message
+git pull
 ```
 
-Then create (or modify) the `.circleci/config.yml` file with these contents:
+## Create a CI Workflow
 
-```yaml {% fileName=".circleci/config.yml" %}
+First, we'll create a new branch to start adding a CI workflow.
+
+```shell
+git checkout -b setup-ci
+```
+
+Now we can use an Nx generator to create a default CI workflow file.
+
+```shell
+pnpm nx generate ci-workflow --ci=circleci
+```
+
+This generator will overwrite Circle CI's default `.circleci/config.yml` file to create a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR.
+
+The key lines in the CI pipeline are:
+
+```yml {% fileName=".circleci/config.yml" highlightLines=["27-29"] %}
 version: 2.1
 
+orbs:
+  nx: nrwl/nx@1.6.2
+
 jobs:
   main:
     docker:
       - image: cimg/node:lts-browsers
     steps:
+      - checkout
+
       - run:
-          name: Print a message
-          command: echo "Hello Circle CI!"
+          name: Install PNPM
+          command: npm install --prefix=$HOME/.local -g pnpm@8
+
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      # - run: pnpm dlx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
+
+      - run: pnpm install --frozen-lockfile
+      - nx/set-shas:
+          main-branch-name: 'main'
+
+      # Prepend any command with "nx-cloud record --" to record its logs to Nx Cloud
+      # - run: pnpm exec nx-cloud record -- echo Hello World
+      - run: pnpm exec nx affected --base=$NX_BASE --head=$NX_HEAD -t lint test build
 
 workflows:
   version: 2
@@ -84,309 +121,106 @@ workflows:
       - main
 ```
 
-Next, commit this change, push the branch and create a PR on your forked GitHub repository:
+The [`nx affected` command](/ci/features/affected) will run the specified tasks only for projects that have been affected by a particular PR, which can save a lot of time as repositories grow larger.
+
+Commit your changes and push your branch:
 
 ```shell
-git commit -am "pipeline that logs a message"
+git add .
+git commit -am "basic ci workflow"
 git push -u origin HEAD
 ```
 
-If everything was set up correctly, you should see a message from Circle CI in the PR with a success status.
+Open up a new PR to see the run on CircleCI. If you see a message about the `nrwl/nx` orb not being loaded, you need to enable third-party CircleCI orbs in your organization settings. In the Circle CI project dashboard, go to `Organization Settings -> Security` and select `Yes` under Orb Security Settings: Allow Uncertified Orbs.
 
-![All checks have passed in the PR](/nx-cloud/tutorial/Circle%20PR%20passed.png)
+![](/nx-cloud/tutorial/circle-orb-security.png)
 
-Click on the job details and you should see the `Hello Circle CI` message in the logs.
+{% callout type="warning" title="Create Your PR on Your Own Repository" %}
+Make sure that the PR you create is against your own repository's `main` branch - not the `nrwl/nx-shops` repository.
+{% /callout %}
 
-![The "Hello Circle CI" message is printed in the logs](/nx-cloud/tutorial/Message%20Logged.png)
+![](/nx-cloud/tutorial/circle-new-run.avif)
 
-Merge your PR into the `main` branch when you're ready to move to the next section.
+Once CI is green, merge the PR.
 
-## Configure Nx on Circle CI
+![](/nx-cloud/tutorial/github-pr-workflow.avif)
 
-Now let's use Nx in the pipeline. The simplest way to use Nx is to run a single task, so we'll start by building our `cart` application.
+And make sure to pull the changes locally:
 
 ```shell
-pnpm nx build cart
+git checkout main
+git pull origin main
 ```
 
-We need to adjust a couple of things on our CI pipeline to make this work:
+The rest of the tutorial covers remote caching and distribution across multiple machines, which need Nx Cloud to be enabled. Let's set that up next.
 
-- clone the repository
-- install NPM dependencies (in our nx-shop using PNPM)
-- use Nx to run the `build` command
+## Connect to Nx Cloud
 
-Nx is an [npm package](https://www.npmjs.com/package/nx) so once NPM packages are installed we will be able to use it.
+Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e test deflaking, better DX and more.
 
-Create a new branch called `build-one-app` and paste this code into the Circle CI config.
+Let's connect your repository to Nx Cloud with the following command:
 
-```yaml {% fileName=".circleci/config.yml" highlightLines=["8-14"] %}
-version: 2.1
-
-jobs:
-  main:
-    docker:
-      - image: cimg/node:lts-browsers
-    steps:
-      - checkout
-      - run:
-          name: install dependencies
-          command: pnpm install --frozen-lockfile
-      - run:
-          name: Run build
-          command: pnpm nx build cart
-
-workflows:
-  version: 2
-
-  ci:
-    jobs:
-      - main
+```shell
+pnpm nx connect
 ```
 
-Once `node_modules` are in place, you can run normal Nx commands. In this case, we run `pnpm nx build cart`. Push the changes to your repository by creating a new PR and verifying the new CI pipeline correctly builds our application.
+A browser window will open to register your repository in your [Nx Cloud](https://cloud.nx.app) account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.
 
-![Building a single app with nx](/nx-cloud/tutorial/circle-single-build-success.jpg)
+![](/nx-cloud/tutorial/nx-cloud-setup.avif)
 
-You might have noticed that there's also a build running for `shared-header`, `shared-product-types` and `shared-product-ui`. These are projects in our workspace that `cart` depends on. Thanks to the [Nx task pipeline](/concepts/task-pipeline-configuration), Nx knows that it needs to build these projects first before building `cart`. This already helps us simplify our pipeline as we
+Nx Cloud will create a comment on your PR that gives you a summary of the CI run and a link to dig into logs and understand everything that happened during the CI run.
 
-- don't need to define these builds automatically
-- don't need to make any changes to our pipeline as our `cart` app grows and depends on more projects
-- don't need to worry about the order of the builds
+![Nx Cloud report comment](/nx-cloud/tutorial/nx-cloud-report-comment.png)
 
-Merge your PR into the `main` branch when you're ready to move to the next section.
+Once the PR is green, merge it into your main branch.
 
-## Optimize our CI by caching NPM dependencies
+![](/nx-cloud/tutorial/github-cloud-pr.avif)
 
-While this isn't related to Nx specifically, it's a good idea to cache NPM dependencies in CI. This will speed up the CI pipeline by avoiding downloading the same dependencies over and over again. Circle CI has [a docs page on how to cache NPM dependencies](https://circleci.com/docs/caching/).
+And make sure you pull the latest changes locally:
 
-Adjust your CI pipeline script as follows
-
-```yaml {% fileName=".circleci/config.yml" highlightLines=["10-11", "17-21"] %}
-version: 2.1
-
-jobs:
-  main:
-    docker:
-      - image: cimg/node:lts-browsers
-    steps:
-      - checkout
-      # look for existing cache and restore if found
-      - restore_cache:
-          key: npm-dependencies-{{ checksum "pnpm-lock.yaml" }}
-      # install dependencies
-      - run:
-          name: install dependencies
-          command: pnpm install --frozen-lockfile
-      # save any changes to the cache
-      - save_cache:
-          key: npm-dependencies-{{ checksum "pnpm-lock.yaml" }}
-          paths:
-            - node_modules
-            - ~/.cache/Cypress # needed for the Cypress binary
-      - run:
-          name: Run build
-          command: pnpm nx build cart
-
-workflows:
-  version: 2
-
-  ci:
-    jobs:
-      - main
+```shell
+git pull
 ```
 
-The `restore_cache` and `save_cache` steps are using a hash key that is created from the contents of the `pnpm-lock.yaml` file. This way if the `pnpm-lock.yaml` file remains the same, the next CI pipeline can pull from the cache instead of downloading `node_modules` again. This is similar to the way [Nx hashes input files to cache the results of tasks](/features/cache-task-results).
+You should now have an `nxCloudAccessToken` property specified in the `nx.json` file.
 
-Create a new branch with these changes and submit a PR to your repo to test them. Merge your PR into the `main` branch when you're ready to move to the next section.
-
-## Process Only Affected Projects
-
-So far we only ran the build for our `cart` application. There are other apps in our monorepo workspace though, namely `admin`, `landing-page` and `products`. We could now adjust our CI pipeline to add these builds as well:
-
-```plaintext
-pnpm nx build cart
-pnpm nx build admin
-pnpm nx build landing-page
-```
-
-Clearly this is not a scalable solution as it requires us to manually add every new app to the pipeline (and it doesn't include other tasks like `lint`, `test` etc). To improve this we can change the command to run the `build` for all projects like
-
-```{% command="nx run-many -t build" %}
-✔  nx run shared-product-types:build (429ms)
-✔  nx run shared-product-ui:build (455ms)
-✔  nx run shared-header:build (467ms)
-✔  nx run landing-page:build:production (3s)
-✔  nx run admin:build:production (3s)
-✔  nx run cart:build:production (3s)
-
-————————————————————————————————————————————————————————————————
-
-NX   Successfully ran target build for 6 projects (10s)
-```
-
-This change makes our CI pipeline configuration more maintainable. For a small repository, this might be good enough, but after a little bit of growth this approach will cause your CI times to become unmanageable.
-
-Nx comes with a dedicated ["affected" command](/ci/features/affected) to help with that by only running tasks for projects that were affected by the changes in a given PR.
-
-```{% command="nx affected -t build" %}
-✔  nx run shared-product-types:build (404ms)
-✔  nx run shared-product-ui:build (445ms)
-✔  nx run shared-header:build (465ms)
-✔  nx run cart:build:production (3s)
-
-——————————————————————————————————————————————————————————————————————————————————————
-
-NX   Successfully ran target build for project cart and 3 tasks it depends on (4s)
-```
-
-### Configuring the Comparison Range for Affected Commands
-
-To understand which projects are affected, Nx uses the Git history and the [project graph](/features/explore-graph). Git knows which files changed, and the Nx project graph knows which projects those files belong to.
-
-The affected command takes a `base` and `head` commit. The default `base` is your `main` branch and the default `head` is your current file system. This is generally what you want when developing locally, but in CI, you need to customize these values.
-
-The goal of the CI pipeline is to make sure that the current state of the repository is a good one. To ensure this, we want to verify all the changes **since the last successful CI run** - not just since the last commit on `main`.
-
-While you could calculate this yourself, we created the [`nrwl/nx` Circle CI orb](https://github.com/nrwl/nx-orb#background) to help with that. It provides you with the `nx/set-shas` step which automatically sets the `$NX_BASE` and `$NX_HEAD` environment variables to the correct commit SHAs for you to use in the affected command.
-
-In order to use the `nrwl/nx` orb, you need to enable the use of third-party Circle CI orbs in your organization settings. In the Circle CI project dashboard, go to `Organization Settings -> Security` and select `Yes` under Orb Security Settings: Allow Uncertified Orbs.
-
-![Adjust ORB Security Settings in Circle CI](/nx-cloud/tutorial/circle-orb-security.png)
-
-### Using the Affected Commands in our Pipeline
-
-Let's adjust our CI pipeline configuration to use the affected command. Create a new branch called `ci-affected` and create a PR with the following configuration:
-
-```yaml {% fileName=".circleci/config.yml" highlightLines=[2,3,20,22,23] %}
-version: 2.1
-orbs:
-  nx: nrwl/nx@1.5.1
-jobs:
-  main:
-    docker:
-      - image: cimg/node:lts-browsers
-    steps:
-      - checkout
-      - restore_cache:
-          key: npm-dependencies-{{ checksum "pnpm-lock.yaml" }}
-      - run:
-          name: install dependencies
-          command: pnpm install --frozen-lockfile
-      - save_cache:
-          key: npm-dependencies-{{ checksum "pnpm-lock.yaml" }}
-          paths:
-            - node_modules
-            - ~/.cache/Cypress
-      - nx/set-shas
-
-      - run: pnpm nx affected --base=$NX_BASE --head=$NX_HEAD -t lint test build --parallel=3
-      - run: pnpm nx affected --base=$NX_BASE --head=$NX_HEAD -t e2e-ci --parallel=1
-workflows:
-  build:
-    jobs:
-      - main
-```
-
-Notice how we're using the `$NX_BASE` and `$NX_HEAD` environment variables to set the correct `base` and `head` commits to use for file comparisons.
-
-We're also using the `--parallel` flag to run up to 3 `lint`, `test` or `build` tasks at once, but we want to make sure that only 1 `e2e` task is running at a time.
-
-When you check the CI logs for this PR, you'll notice that no tasks were run by the `affected` command. That's because the `.circleci/config.yml` file is not an input for any task. We should really double check every task whenever we make changes to the CI pipeline, so let's fix that by adding an entry in the `sharedGlobals` array in the `nx.json` file.
-
-```jsonc {% fileName="nx.json" %}
-{
-  "namedInputs": {
-    "default": ["{projectRoot}/**/*", "sharedGlobals"],
-    "sharedGlobals": [
-      "{workspaceRoot}/babel.config.json",
-      "{workspaceRoot}/.circleci/config.yml" // add this line
-    ]
-    // etc...
-  }
-}
-```
-
-Merge your PR into the `main` branch when you're ready to move to the next section.
-
-## Enable Remote Caching And Distributed Task Execution Using Nx Cloud
-
-Only running necessary tasks via [affected commands](/ci/features/affected) (as seen in the previous section) is helpful, but might not be enough. By default [Nx caches the results of tasks](/features/cache-task-results) on your local machine. But CI and other developer machines will still perform the same tasks on the same code - wasting time and money. Also, as your repository grows, running all the tasks on a single agent will cause the CI pipeline to take too long. The only way to decrease the CI pipeline time is to distribute your CI across many machines. Let's solve both of these problems using Nx Cloud.
-
-### Connect Your Workspace to Nx Cloud
-
-Create an account on [nx.app](https://nx.app). There are several ways to connect your repository to Nx Cloud.
-
-#### Connect Directly Through GitHub
-
-The easiest way is to create an Nx Cloud organization based on your GitHub organization.
-
-![Connect Your VCS Account](/nx-cloud/tutorial/connect-vcs-account.png)
-
-After that, connect you repository.
-
-![Connect Your Repository](/nx-cloud/tutorial/connect-repository.png)
-
-This will send a pull request to your repository that will add the `nxCloudAccessToken` property to `nx.json`.
-
-![Nx Cloud Setup PR](/nx-cloud/tutorial/nx-cloud-setup-pr.png)
-
-This wires up all the CI for you and configures access. Folks who can see your repository can see your workspace on nx.app.
-
-#### Manually Connect Your Workspace
-
-To manually connect your workspace to Nx Cloud, run the following command in your repository:
-
-```{% command="pnpm nx connect" %}
-$ nx g nx:connect-to-nx-cloud --quiet --no-interactive
-
-NX   Your Nx Cloud workspace is public
-
-To restrict access, connect it to your Nx Cloud account:
-- Push your changes
-- Login at https://cloud.nx.app to connect your repository
-```
-
-Click the link in the terminal to claim your workspace on [nx.app](https://nx.app).
-
-The command generates an `nxCloudAccessToken` property inside of `nx.json`. This is a read-only token that should be committed to the repository.
-
-### Enable Remote Caching using Nx Replay
+## Understand Remote Caching
 
 [Nx Cloud](https://nx.app) provides [Nx Replay](/ci/features/remote-cache), which is a powerful, scalable and, very importantly, secure way to share task artifacts across machines. It lets you configure permissions and guarantees the cached artifacts cannot be tempered with.
 
-[Nx Replay](/ci/features/remote-cache) is enabled by default. To see it in action, rerun the CI for the PR opened by Nx Cloud.
+[Nx Replay](/ci/features/remote-cache) is enabled by default. We can see it in action by running a few commands locally. First, let's build every project in the repository:
 
-When Circle CI now processes our tasks they'll only take a fraction of the usual time. If you inspect the logs a little closer you'll see a note saying `[remote cache]`, indicating that the output has been pulled from the remote cache rather than running it. The full log of each command will still be printed since Nx restores that from the cache as well.
-
-![Circle CI after enabling remote caching](/nx-cloud/tutorial/circle-ci-remote-cache.png)
-
-![Run Details with remote cache hits](/nx-cloud/tutorial/nx-cloud-run-details.png)
-
-What is more, if you run tasks locally, you will also get cache hits:
-
-```{% command="nx run-many -t build" %}
-...
-✔  nx run express-legacy:build  [remote cache]
-✔  nx run nx-plugin-legacy:build  [remote cache]
-✔  nx run esbuild-legacy:build  [remote cache]
-✔  nx run react-native-legacy:build  [remote cache]
-✔  nx run angular-legacy:build  [remote cache]
-✔  nx run remix-legacy:build  [remote cache]
-
-————————————————————————————————————————————————
-
-NX   Successfully ran target build for 58 projects and 62 tasks they depend on (1m)
-
-Nx read the output from the cache instead of running the command for 116 out of 120 tasks.
+```shell
+pnpm nx run-many -t build
 ```
 
+Nx will store the output of those tasks locally in the `.nx/cache` folder and remotely in Nx Cloud. If someone else in the organization were to run the same `build` command on the same source code, they would receive the remotely cached outputs instead of re-running the `build` task themselves. We can simulate this by deleting the `.nx/cache` folder and re-running the `build` command.
+
+```shell
+rm -rf .nx/cache
+pnpm nx run-many -t build
+```
+
+The `build` tasks complete almost instantly, and you can see in the logs that Nx has pulled the outputs from the remote cache:
+
+```
+❯ nx run-many -t build
+
+   ✔  nx run shared-product-types:build  [remote cache]
+   ✔  nx run shared-product-ui:build  [remote cache]
+   ✔  nx run shared-header:build  [remote cache]
+   ✔  nx run landing-page:build:production  [remote cache]
+   ✔  nx run admin:build:production  [remote cache]
+   ✔  nx run cart:build:production  [remote cache]
+```
+
+This remote cache is useful to speed up tasks when developing on a local machine, but it is incredibly useful for CI to be able share task results across different CI pipeline executions. When a small commit is added to a large PR, the CI is able to download the results for most of the tasks instead of recomputing everything from scratch.
+
 You might also want to learn more about [how to fine-tune caching](/recipes/running-tasks/configure-inputs) to get even better results.
 
-Merge your PR into the `main` branch when you're ready to move to the next section.
+## Parallelize Tasks Across Multiple Machines Using Nx Agents
 
-### Parallelize Tasks Across Multiple Machines Using Nx Agents
-
-The affected command and Nx Replay help speed up the average CI time, but there will be some PRs that affect everything in the repository. The only way to speed up that worst case scenario is through efficient parallelization. The best way to parallelize CI with Nx is to use Nx Agents.
+The affected command and Nx Replay help speed up the average CI time, but there will be some PRs that affect everything in the repository. The only way to speed up that worst case scenario is through efficient parallelization. The best way to parallelize CI with Nx is to use [Nx Agents](/ci/features/distribute-task-execution).
 
 The Nx Agents feature
 
@@ -396,61 +230,67 @@ The Nx Agents feature
 - collects the results and logs of all the tasks and presents them in a single view
 - automatically shuts down agents when they are no longer needed
 
-Let's enable Nx Agents
+To enable Nx Agents, make sure the following line is uncommented in the `.circleci/config.yml` file.
 
-```
-pnpm exec nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
-```
-
-We recommend you add this line right after you check out the repo, before installing node modules.
-
-- `nx-cloud start-ci-run --distribute-on="3 linux-medium-js` lets Nx know that all the tasks after this line should using Nx Agents and that Nx Cloud should use 3 instances of the `linux-medium-js` launch template. See below on how to configure a custom launch template.
-- `--stop-agents-after="e2e-ci"` lets Nx Cloud know which line is the last command in this pipeline. Once there are no more e2e tasks for an agent to run, Nx Cloud will automatically shut them down. This way you're not wasting money on idle agents while a particularly long e2e task is running on a single agent.
-
-Try it out by creating a new PR with the above changes.
-
-Once Circle CI starts, you should see multiple agents running in parallel similar to this:
-
-![CIPE Agents In Progress](/nx-cloud/tutorial/cipe-agents-in-progress.png)
-
-With this pipeline configuration in place, no matter how large the repository scales, Nx Cloud will adjust and distribute tasks across agents in the optimal way. If CI pipelines start to slow down, just add some agents. One of the main advantages is that this pipeline definition is declarative. We tell Nx what commands to run, but not how to distribute them. That way even if our monorepo structure changes and evolves over time, the distribution will be taken care of by Nx Cloud.
-
-### Running Commands Without Distribution
-
-Sometimes you want to distribute most of your commands, but run some of them in Circle CI. You can do this with the `--no-agents` flag as follows:
-
-```yaml {% fileName=".circleci/config.yml" highlightLines=[25] %}
+```yml {% fileName=".circleci/config.yml" highlightLines=["21"] %}
 version: 2.1
+
 orbs:
-  nx: nrwl/nx@1.5.1
+  nx: nrwl/nx@1.6.2
+
 jobs:
   main:
     docker:
       - image: cimg/node:lts-browsers
     steps:
       - checkout
-      - run: pnpm exec nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
-      - restore_cache:
-          key: npm-dependencies-{{ checksum "pnpm-lock.yaml" }}
-      - run:
-          name: install dependencies
-          command: pnpm install --frozen-lockfile
-      - save_cache:
-          key: npm-dependencies-{{ checksum "pnpm-lock.yaml" }}
-          paths:
-            - node_modules
-            - ~/.cache/Cypress
-      - nx/set-shas
 
-      - run: pnpm nx affected --base=$NX_BASE --head=$NX_HEAD -t lint test build --parallel=3
-      - run: pnpm nx affected --base=$NX_BASE --head=$NX_HEAD -t e2e-ci --parallel=1
-      - run: pnpm nx affected --base=$NX_BASE --head=$NX_HEAD -t deploy --no-agents # run without distribution
+      - run:
+          name: Install PNPM
+          command: npm install --prefix=$HOME/.local -g pnpm@8
+
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      - run: pnpm dlx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
+
+      - run: pnpm install --frozen-lockfile
+      - nx/set-shas:
+          main-branch-name: 'main'
+
+      # Prepend any command with "nx-cloud record --" to record its logs to Nx Cloud
+      # - run: pnpm exec nx-cloud record -- echo Hello World
+      - run: pnpm exec nx affected --base=$NX_BASE --head=$NX_HEAD -t lint test build
+
 workflows:
-  build:
+  version: 2
+
+  ci:
     jobs:
       - main
 ```
 
+We recommend you add this line right after you check out the repo, before installing node modules.
+
+- `nx-cloud start-ci-run --distribute-on="3 linux-medium-js` lets Nx know that all the tasks after this line should use Nx Agents and that Nx Cloud should use three instances of the `linux-medium-js` launch template. See the separate reference on how to [configure a custom launch template](/ci/reference/launch-templates).
+- `--stop-agents-after="e2e-ci"` lets Nx Cloud know which line is the last command in this pipeline. Once there are no more e2e tasks for an agent to run, Nx Cloud will automatically shut them down. This way you're not wasting money on idle agents while a particularly long e2e task is running on a single agent.
+
+Try it out by creating a new PR with the above changes.
+
+```shell
+git checkout -b enable-distribution
+git commit -am 'enable task distribution'
+```
+
+![](/nx-cloud/tutorial/github-pr-distribution.avif)
+
+Once Circle CI starts, you can click on the Nx Cloud report to see what tasks agents are executing in real time.
+
+![](/nx-cloud/tutorial/nx-cloud-distribution.avif)
+
+With this pipeline configuration in place, no matter how large the repository scales, Nx Cloud will adjust and distribute tasks across agents in the optimal way. If CI pipelines start to slow down, just add some agents. One of the main advantages is that this pipeline definition is declarative. We tell Nx what commands to run, but not how to distribute them. That way even if our monorepo structure changes and evolves over time, the distribution will be taken care of by Nx Cloud.
+
 ## Next Steps
 
 You now have a highly optimized CI configuration that will scale as your repository scales. See what else you can do with Nx Cloud.

docs/nx-cloud/tutorial/github-actions.md

@@ -5,14 +5,12 @@ description: In this tutorial you'll set up continuous integration with GitHub A
 
 # GitHub Actions with Nx
 
-In this tutorial we're going to learn how to leverage Nx to setup a scalable CI pipeline on GitHub Actions. You're going to learn
+In this tutorial we're going to learn how to leverage Nx to setup a scalable CI pipeline on GitHub Actions. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
 
-- how to set up GitHub Actions and configure Nx
-- how to run tasks for only the projects that were affected by a given PR
-- how to enable remote caching
-- how to parallelize and distribute tasks across multiple machines
-
-Note, many of these optimizations are incremental, meaning you could set up running tasks for only affected projects and stop there. Later when you experience slow CI runs, you could add caching to further improve CI performance or even go further and distribute tasks across machines.
+- Nx reduces wasted time in CI with the [`affected` command](/ci/features/affected).
+- Nx Replay's [remote caching](/ci/features/remote-cache) will reuse task artifacts from different CI executions making sure you will never run the same computation twice.
+- Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
+- Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
 
 ## Example Repository
 
@@ -31,7 +29,7 @@ To get started:
 1. [Fork the nx-shop repo](https://github.com/nrwl/nx-shops/fork) and then clone it to your local machine
 
    ```shell
-   git clone git@github.com:<your-username>/nx-shops.git
+   git clone https://github.com/<your-username>/nx-shops.git
    ```
 
 2. Install dependencies (this repo uses [PNPM](https://pnpm.io/) but you should be able to also use any other package manager)
@@ -40,357 +38,154 @@ To get started:
    pnpm i
    ```
 
-3. Explore the structure of the repo using **the Nx Graph**
+3. Make sure all tasks are working on your machine, by running lint, test, build and e2e on all projects of the workspace
 
    ```shell
-   pnpm nx graph
+   pnpm nx run-many -t lint test build
    ```
 
-4. Finally, make sure all task are working on your machine, by running lint, test, build and e2e on all projects of the workspace
+## Create a CI Workflow
 
-   ```shell
-   pnpm nx run-many -t lint test build e2e
-   ```
-
-## Set Up GitHub Actions
-
-To get started with GitHub Actions, we'll create a pipeline that just logs a message. First, checkout a new branch:
+First, we'll create a new branch to start adding a CI workflow.
 
 ```shell
-git checkout -b ci-message
+git checkout -b setup-ci
 ```
 
-Then create (or modify) the `.github/workflows/ci.yml` file with these contents:
+Now we can use an Nx generator to create a default CI workflow file.
 
-```yaml {% fileName=".github/workflows/ci.yml" %}
+```shell
+pnpm nx generate ci-workflow --ci=github
+```
+
+This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR.
+
+The key lines in the CI pipeline are:
+
+```yml {% fileName=".github/workflows/ci.yml" highlightLines=["29-32"] %}
 name: CI
-on:
-  push:
-    branches:
-      # Change this if your primary branch is not main
-      - main
-  pull_request:
-
+# ...
 jobs:
   main:
     runs-on: ubuntu-latest
     steps:
-      - run: echo "Hello GitHub Actions!"
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: pnpm/action-setup@v2
+        with:
+          version: 8
+
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      # - run: pnpm dlx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
+
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 20
+          cache: 'pnpm'
+
+      - run: pnpm install --frozen-lockfile
+      - uses: nrwl/nx-set-shas@v4
+
+      # Prepend any command with "nx-cloud record --" to record its logs to Nx Cloud
+      # - run: pnpm exec nx-cloud record -- echo Hello World
+      # Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
+      - run: pnpm exec nx affected -t lint test build
 ```
 
-Next, commit this change, push the branch and create a PR on your forked GitHub repository:
+The [`nx affected` command](/ci/features/affected) will run the specified tasks only for projects that have been affected by a particular PR, which can save a lot of time as repositories grow larger.
+
+Commit your changes and push your branch:
 
 ```shell
-git commit -am "pipeline that logs a message"
+git add .
+git commit -am "basic ci workflow"
 git push -u origin HEAD
 ```
 
-If everything was set up correctly, you should see a message from GitHub Actions in the PR with a success status.
+Create a pull request with the new branch and watch your CI in action.
 
-![All checks have passed in the PR](/nx-cloud/tutorial/gh-pr-passed.png)
+{% callout type="warning" title="Create Your PR on Your Own Repository" %}
+Make sure that the PR you create is against your own repository's `main` branch - not the `nrwl/nx-shops` repository.
+{% /callout %}
 
-Click on the job details and you should see the `Hello GitHub Actions` message in the logs.
+Once CI is green, merge the PR.
 
-![The "Hello GitHub Actions" message is printed in the logs](/nx-cloud/tutorial/gh-message.png)
+![](/nx-cloud/tutorial/github-pr-workflow.avif)
 
-Merge your PR into the `main` branch when you're ready to move to the next section.
+The rest of the tutorial covers remote caching and distribution across multiple machines, which need Nx Cloud to be enabled. Let's set that up next.
 
-## Configure Nx on GitHub Actions
+## Connect to Nx Cloud
 
-Now let's use Nx in the pipeline. The simplest way to use Nx is to run a single task, so we'll start by building our `cart` application.
+Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e test deflaking, better DX and more.
+
+Let's connect your repository to Nx Cloud with the following command:
 
 ```shell
-pnpm nx build cart
+pnpm nx connect
 ```
 
-We need to adjust a couple of things on our CI pipeline to make this work:
+A browser window will open to register your repository in your [Nx Cloud](https://cloud.nx.app) account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.
 
-- clone the repository
-- install NPM dependencies (in our nx-shop using PNPM)
-- use Nx to run the `build` command
+![](/nx-cloud/tutorial/nx-cloud-setup.avif)
 
-Nx is an [npm package](https://www.npmjs.com/package/nx) so once NPM packages are installed we will be able to use it.
+Nx Cloud will create a comment on your PR that gives you a summary of the CI run and a link to dig into logs and understand everything that happened during the CI run.
 
-Create a new branch called `build-one-app` and paste this code into the GitHub Actions config.
+![Nx Cloud report comment](/nx-cloud/tutorial/nx-cloud-report-comment.png)
 
-```yaml {% fileName=".github/workflows/ci.yml" highlightLines=["12-20"] %}
-name: CI
-on:
-  push:
-    branches:
-      - main
-  pull_request:
+Once the PR is green, merge it into your main branch.
 
-jobs:
-  main:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-      # Setup pnpm
-      - uses: pnpm/action-setup@v2
-        with:
-          version: 8
-      - run: pnpm install --frozen-lockfile
-      - run: pnpm nx build cart
+![](/nx-cloud/tutorial/github-cloud-pr.avif)
+
+And make sure you pull the latest changes locally:
+
+```shell
+git pull
 ```
 
-Once `node_modules` are in place, you can run normal Nx commands. In this case, we run `pnpm nx build cart`. Push the changes to your repository by creating a new PR and verifying the new CI pipeline correctly builds our application.
+You should now have an `nxCloudAccessToken` property specified in the `nx.json` file.
 
-![Building a single app with nx](/nx-cloud/tutorial/gh-single-build-success.png)
-
-You might have noticed that there's also a build running for `shared-header`, `shared-product-types` and `shared-product-ui`. These are projects in our workspace that `cart` depends on. Thanks to the [Nx task pipeline](/concepts/task-pipeline-configuration), Nx knows that it needs to build these projects first before building `cart`. This already helps us simplify our pipeline as we
-
-- don't need to define these builds automatically
-- don't need to make any changes to our pipeline as our `cart` app grows and depends on more projects
-- don't need to worry about the order of the builds
-
-Merge your PR into the `main` branch when you're ready to move to the next section.
-
-## Optimize our CI by caching NPM dependencies
-
-While this isn't related to Nx specifically, it's a good idea to cache NPM dependencies in CI. This will speed up the CI pipeline by avoiding downloading the same dependencies over and over again. GitHub Actions has [an action to cache files](https://github.com/actions/cache) that we'll use.
-
-Adjust your CI pipeline script as follows
-
-```yaml {% fileName=".github/workflows/ci.yml" highlightLines=["18-24", "26-32"] %}
-name: CI
-on:
-  push:
-    branches:
-      - main
-  pull_request:
-
-jobs:
-  main:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-      - uses: pnpm/action-setup@v2
-        with:
-          version: 8
-      - name: Restore cached npm dependencies
-        uses: actions/cache/restore@v3
-        with:
-          path: |
-            node_modules
-            ~/.cache/Cypress # needed for the Cypress binary
-          key: npm-dependencies-${{ hashFiles('pnpm-lock.yaml') }}
-      - run: pnpm install --frozen-lockfile
-      - name: Cache npm dependencies
-        uses: actions/cache/save@v3
-        with:
-          path: |
-            node_modules
-            ~/.cache/Cypress # needed for the Cypress binary
-          key: npm-dependencies-${{ hashFiles('pnpm-lock.yaml') }}
-      - run: pnpm nx build cart
-```
-
-The `restore_cache` and `save_cache` steps are using a hash key that is created from the contents of the `pnpm-lock.yaml` file. This way if the `pnpm-lock.yaml` file remains the same, the next CI pipeline can pull from the cache instead of downloading `node_modules` again. This is similar to the way [Nx hashes input files to cache the results of tasks](/features/cache-task-results).
-
-Create a new branch with these changes and submit a PR to your repo to test them. Merge your PR into the `main` branch when you're ready to move to the next section.
-
-## Process Only Affected Projects
-
-So far we only ran the build for our `cart` application. There are other apps in our monorepo workspace though, namely `admin`, `landing-page` and `products`. We could now adjust our CI pipeline to add these builds as well:
-
-```plaintext
-pnpm nx build cart
-pnpm nx build admin
-pnpm nx build landing-page
-```
-
-Clearly this is not a scalable solution as it requires us to manually add every new app to the pipeline (and it doesn't include other tasks like `lint`, `test` etc). To improve this we can change the command to run the `build` for all projects like
-
-```{% command="nx run-many -t build" %}
-✔  nx run shared-product-types:build (429ms)
-✔  nx run shared-product-ui:build (455ms)
-✔  nx run shared-header:build (467ms)
-✔  nx run landing-page:build:production (3s)
-✔  nx run admin:build:production (3s)
-✔  nx run cart:build:production (3s)
-
-————————————————————————————————————————————————————————————————
-
-NX   Successfully ran target build for 6 projects (10s)
-```
-
-This change makes our CI pipeline configuration more maintainable. For a small repository, this might be good enough, but after a little bit of growth this approach will cause your CI times to become unmanageable.
-
-Nx comes with a dedicated ["affected" command](/ci/features/affected) to help with that by only running tasks for projects that were affected by the changes in a given PR.
-
-```{% command="nx affected -t build" %}
-✔  nx run shared-product-types:build (404ms)
-✔  nx run shared-product-ui:build (445ms)
-✔  nx run shared-header:build (465ms)
-✔  nx run cart:build:production (3s)
-
-——————————————————————————————————————————————————————————————————————————————————————
-
-NX   Successfully ran target build for project cart and 3 tasks it depends on (4s)
-```
-
-### Configuring the Comparison Range for Affected Commands
-
-To understand which projects are affected, Nx uses the Git history and the [project graph](/features/explore-graph). Git knows which files changed, and the Nx project graph knows which projects those files belong to.
-
-The affected command takes a `base` and `head` commit. The default `base` is your `main` branch and the default `head` is your current file system. This is generally what you want when developing locally, but in CI, you need to customize these values.
-
-The goal of the CI pipeline is to make sure that the current state of the repository is a good one. To ensure this, we want to verify all the changes **since the last successful CI run** - not just since the last commit on `main`.
-
-While you could calculate this yourself, we created the [`nx-set-shas` GitHub Action](https://github.com/marketplace/actions/nx-set-shas) to help with that. It provides you with the `nrwl/nx-set-shas` action which automatically sets the `NX_BASE` and `NX_HEAD` environment variables to the correct commit SHAs. The affected command will use these environment variables when they are defined.
-
-### Using the Affected Commands in our Pipeline
-
-Let's adjust our CI pipeline configuration to use the affected command. Create a new branch called `ci-affected` and create a PR with the following configuration:
-
-```yaml {% fileName=".github/workflows/ci.yml" highlightLines=["35-39"] %}
-name: CI
-on:
-  push:
-    branches:
-      - main
-  pull_request:
-
-jobs:
-  main:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-      - uses: pnpm/action-setup@v2
-        with:
-          version: 8
-      - name: Restore cached npm dependencies
-        id: cache-dependencies-restore
-        uses: actions/cache/restore@v3
-        with:
-          path: |
-            node_modules
-            ~/.cache/Cypress # needed for the Cypress binary
-          key: npm-dependencies-${{ hashFiles('pnpm-lock.yaml') }}
-      - run: pnpm install --frozen-lockfile
-      - name: Cache npm dependencies
-        id: cache-dependencies-save
-        uses: actions/cache/save@v3
-        with:
-          path: |
-            node_modules
-            ~/.cache/Cypress # needed for the Cypress binary
-          key: ${{ steps.cache-dependencies-restore.outputs.cache-primary-key }}
-      - uses: nrwl/nx-set-shas@v3
-      # This line is needed for nx affected to work when CI is running on a PR
-      - run: git branch --track main origin/main
-        if: ${{ github.event_name == 'pull_request' }}
-
-      - run: pnpm nx affected -t lint test build --parallel=3
-      - run: pnpm nx affected -t e2e --parallel=1
-```
-
-We're using the `--parallel` flag to run up to 3 `lint`, `test` or `build` tasks at once, but we want to make sure that only 1 `e2e` task is running at a time.
-
-When you check the CI logs for this PR, you'll notice that no tasks were run by the `affected` command. That's because the `.github/workflows/ci.yml` file is not an input for any task. We should really double check every task whenever we make changes to the CI pipeline, so let's fix that by adding an entry in the `sharedGlobals` array in the `nx.json` file.
-
-```jsonc {% fileName="nx.json" highlightLines=[6] %}
-{
-  "namedInputs": {
-    "default": ["{projectRoot}/**/*", "sharedGlobals"],
-    "sharedGlobals": [
-      "{workspaceRoot}/babel.config.json",
-      "{workspaceRoot}/.github/workflows/ci.yml" // add this line
-    ]
-    // etc...
-  }
-}
-```
-
-Merge your PR into the `main` branch when you're ready to move to the next section.
-
-## Enable Remote Caching and Distributed Task Execution Using Nx Cloud
-
-Only running necessary tasks via [affected commands](/ci/features/affected) (as seen in the previous section) is helpful, but might not be enough. By default [Nx caches the results of tasks](/features/cache-task-results) on your local machine. But CI and other developer machines will still perform the same tasks on the same code - wasting time and money. Also, as your repository grows, running all the tasks on a single agent will cause the CI pipeline to take too long. The only way to decrease the CI pipeline time is to distribute your CI across many machines. Let's solve both of these problems using Nx Cloud.
-
-### Connect Your Workspace to Nx Cloud
-
-Create an account on [nx.app](https://nx.app). The easiest way to connect your repository to Nx Cloud is to create an Nx Cloud organization based on your GitHub organization.
-
-![Connect Your VCS Account](/nx-cloud/tutorial/connect-vcs-account.png)
-
-After that, connect you repository.
-
-![Connect Your Repository](/nx-cloud/tutorial/connect-repository.png)
-
-This will send a pull request to your repository that will add the `nxCloudAccessToken` property to `nx.json`.
-
-![Nx Cloud Setup PR](/nx-cloud/tutorial/nx-cloud-setup-pr.png)
-
-This wires up all the CI for you and configures access. Folks who can see your repository can see your workspace on nx.app.
-
-### Enable Remote Caching using Nx Replay
+## Understand Remote Caching
 
 [Nx Cloud](https://nx.app) provides [Nx Replay](/ci/features/remote-cache), which is a powerful, scalable and, very importantly, secure way to share task artifacts across machines. It lets you configure permissions and guarantees the cached artifacts cannot be tempered with.
 
-[Nx Replay](/ci/features/remote-cache) is enabled by default. To see it in action, rerun the CI for the PR opened by Nx Cloud.
+[Nx Replay](/ci/features/remote-cache) is enabled by default. We can see it in action by running a few commands locally. First, let's build every project in the repository:
 
-When GitHub Actions now processes our tasks they'll only take a fraction of the usual time. If you inspect the logs a little closer you'll see a note saying `[remote cache]`, indicating that the output has been pulled from the remote cache rather than running it. The full log of each command will still be printed since Nx restores that from the cache as well.
-
-![GitHub Actions after enabling remote caching](/nx-cloud/tutorial/gh-ci-remote-cache.png)
-
-![Run Details with remote cache hits](/nx-cloud/tutorial/nx-cloud-run-details.png)
-
-What is more, if you run tasks locally, you will also get cache hits:
-
-```{% command="nx run-many -t build" %}
-...
-✔  nx run express-legacy:build  [remote cache]
-✔  nx run nx-plugin-legacy:build  [remote cache]
-✔  nx run esbuild-legacy:build  [remote cache]
-✔  nx run react-native-legacy:build  [remote cache]
-✔  nx run angular-legacy:build  [remote cache]
-✔  nx run remix-legacy:build  [remote cache]
-
-————————————————————————————————————————————————
-
-NX   Successfully ran target build for 58 projects and 62 tasks they depend on (1m)
-
-Nx read the output from the cache instead of running the command for 116 out of 120 tasks.
+```shell
+pnpm nx run-many -t build
 ```
 
+Nx will store the output of those tasks locally in the `.nx/cache` folder and remotely in Nx Cloud. If someone else in the organization were to run the same `build` command on the same source code, they would receive the remotely cached outputs instead of re-running the `build` task themselves. We can simulate this by deleting the `.nx/cache` folder and re-running the `build` command.
+
+```shell
+rm -rf .nx/cache
+pnpm nx run-many -t build
+```
+
+The `build` tasks complete almost instantly, and you can see in the logs that Nx has pulled the outputs from the remote cache:
+
+```
+❯ nx run-many -t build
+
+   ✔  nx run shared-product-types:build  [remote cache]
+   ✔  nx run shared-product-ui:build  [remote cache]
+   ✔  nx run shared-header:build  [remote cache]
+   ✔  nx run landing-page:build:production  [remote cache]
+   ✔  nx run admin:build:production  [remote cache]
+   ✔  nx run cart:build:production  [remote cache]
+```
+
+This remote cache is useful to speed up tasks when developing on a local machine, but it is incredibly useful for CI to be able share task results across different CI pipeline executions. When a small commit is added to a large PR, the CI is able to download the results for most of the tasks instead of recomputing everything from scratch.
+
 You might also want to learn more about [how to fine-tune caching](/recipes/running-tasks/configure-inputs) to get even better results.
 
-Merge your PR into the `main` branch when you're ready to move to the next section.
+## Parallelize Tasks Across Multiple Machines Using Nx Agents
 
-## Enable PR Integration
-
-The [Nx Cloud GitHub App](https://github.com/marketplace/official-nx-cloud-app) automatically creates a comment on your PRs that provides a direct link to the relevant Nx Cloud logs and quickly shows which command failed.
-
-### Install the App
-
-Install the [Nx Cloud GitHub App](https://github.com/marketplace/official-nx-cloud-app) and give it permission to access your repo.
-
-### Connecting Your Workspace
-
-Once you have installed the Nx Cloud GitHub App, you must link your workspace to the installation. To do this, sign in to Nx Cloud and navigate to the VCS Integrations setup page. Once on the VCS Integrations setup page, choose GitHub as your version control system.
-
-![Access VCS Setup](/nx-cloud/set-up/access-vcs-setup.webp)
-
-### Authenticate Via the GitHub App
-
-To use the Nx Cloud GitHub App for authentication, select the radio button and then click "Connect".
-This will verify that Nx Cloud can connect to your repo. Upon a successful test, your configuration is saved.
-
-![Use GitHub App for Authentication](/nx-cloud/set-up/use-github-app-auth.webp)
-
-Now any new PRs in your repo should have a comment automatically added that links directly to Nx Cloud. For other ways of setting up PR integration, read the [Enable GitHub PR Integration recipe](/ci/recipes/source-control-integration/github).
-
-### Parallelize Tasks Across Multiple Machines Using Nx Agents
-
-The affected command and Nx Replay help speed up the average CI time, but there will be some PRs that affect everything in the repository. The only way to speed up that worst case scenario is through efficient parallelization. The best way to parallelize CI with Nx is to use Nx Agents.
+The affected command and Nx Replay help speed up the average CI time, but there will be some PRs that affect everything in the repository. The only way to speed up that worst case scenario is through efficient parallelization. The best way to parallelize CI with Nx is to use [Nx Agents](/ci/features/distribute-task-execution).
 
 The Nx Agents feature
 
@@ -400,37 +195,11 @@ The Nx Agents feature
 - collects the results and logs of all the tasks and presents them in a single view
 - automatically shuts down agents when they are no longer needed
 
-Let's enable Nx Agents
+To enable Nx Agents, make sure the following line is uncommented in the `.github/workflows/ci.yml` file.
 
-```shell
-pnpm dlx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
-```
-
-We recommend you add this line right after you check out the repo, before installing node modules.
-
-- `nx-cloud start-ci-run --distribute-on="3 linux-medium-js` lets Nx know that all the tasks after this line should using Nx Agents and that Nx Cloud should use 3 instances of the `linux-medium-js` launch template. See below on how to configure a custom launch template.
-- `--stop-agents-after="e2e-ci"` lets Nx Cloud know which line is the last command in this pipeline. Once there are no more e2e tasks for an agent to run, Nx Cloud will automatically shut them down. This way you're not wasting money on idle agents while a particularly long e2e task is running on a single agent.
-
-Try it out by creating a new PR with the above changes.
-
-Once GitHub Actions starts, you should see multiple agents running in parallel:
-
-![GitHub Actions showing multiple DTE agents](/nx-cloud/tutorial/gh-dte-multiple-agents.png)
-
-With this pipeline configuration in place, no matter how large the repository scales, Nx Cloud will adjust and distribute tasks across agents in the optimal way. If CI pipelines start to slow down, just add some agents. One of the main advantages is that this pipeline definition is declarative. We tell Nx what commands to run, but not how to distribute them. That way even if our monorepo structure changes and evolves over time, the distribution will be taken care of by Nx Cloud.
-
-### Running Commands Without Distribution
-
-Sometimes you want to distribute most of your commands, but run some of them in Github Actions. You can do this with the `--no-agents` flag as follows:
-
-```yaml {% fileName=".github/workflows/ci.yml" highlightLines=["18-21","44"] %}
+```yml {% fileName=".github/workflows/ci.yml" highlightLines=[19] %}
 name: CI
-on:
-  push:
-    branches:
-      - main
-  pull_request:
-
+# ...
 jobs:
   main:
     runs-on: ubuntu-latest
@@ -438,39 +207,51 @@ jobs:
       - uses: actions/checkout@v4
         with:
           fetch-depth: 0
+
       - uses: pnpm/action-setup@v2
         with:
           version: 8
-      - run: |
-          pnpm dlx nx-cloud start-ci-run \
-            --distribute-on="3 linux-medium-js" \
-            --stop-agents-after="e2e-ci"
-      - name: Restore cached npm dependencies
-        id: cache-dependencies-restore
-        uses: actions/cache/restore@v3
+
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      - run: pnpm dlx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
+
+      - uses: actions/setup-node@v3
         with:
-          path: |
-            node_modules
-            ~/.cache/Cypress # needed for the Cypress binary
-          key: npm-dependencies-${{ hashFiles('pnpm-lock.yaml') }}
+          node-version: 20
+          cache: 'pnpm'
+
       - run: pnpm install --frozen-lockfile
-      - name: Cache npm dependencies
-        id: cache-dependencies-save
-        uses: actions/cache/save@v3
-        with:
-          path: |
-            node_modules
-            ~/.cache/Cypress # needed for the Cypress binary
-          key: ${{ steps.cache-dependencies-restore.outputs.cache-primary-key }}
-      - uses: nrwl/nx-set-shas@v3
-      # This line is needed for nx affected to work when CI is running on a PR
-      - run: git branch --track main origin/main
-        if: ${{ github.event_name == 'pull_request' }}
-      - run: pnpm nx affected -t lint test build --parallel=3
-      - run: pnpm nx affected -t e2e-ci --parallel=1
-      - run: pnpm nx affected -t deploy --no-agents
+      - uses: nrwl/nx-set-shas@v4
+
+      # Prepend any command with "nx-cloud record --" to record its logs to Nx Cloud
+      # - run: pnpm exec nx-cloud record -- echo Hello World
+      # Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
+      - run: pnpm exec nx affected -t lint test build
 ```
 
+We recommend you add this line right after you check out the repo, before installing node modules.
+
+- `nx-cloud start-ci-run --distribute-on="3 linux-medium-js` lets Nx know that all the tasks after this line should use Nx Agents and that Nx Cloud should use three instances of the `linux-medium-js` launch template. See the separate reference on how to [configure a custom launch template](/ci/reference/launch-templates).
+- `--stop-agents-after="e2e-ci"` lets Nx Cloud know which line is the last command in this pipeline. Once there are no more e2e tasks for an agent to run, Nx Cloud will automatically shut them down. This way you're not wasting money on idle agents while a particularly long e2e task is running on a single agent.
+
+Try it out by creating a new PR with the above changes.
+
+```shell
+git checkout -b enable-distribution
+git commit -am 'enable task distribution'
+```
+
+![](/nx-cloud/tutorial/github-pr-distribution.avif)
+
+Once GitHub Actions starts, you can click on the Nx Cloud report to see what tasks agents are executing in real time.
+
+![](/nx-cloud/tutorial/nx-cloud-distribution.avif)
+
+With this pipeline configuration in place, no matter how large the repository scales, Nx Cloud will adjust and distribute tasks across agents in the optimal way. If CI pipelines start to slow down, just add some agents. One of the main advantages is that this pipeline definition is declarative. We tell Nx what commands to run, but not how to distribute them. That way even if our monorepo structure changes and evolves over time, the distribution will be taken care of by Nx Cloud.
+
 ## Next Steps
 
 You now have a highly optimized CI configuration that will scale as your repository scales. See what else you can do with Nx Cloud.

docs/shared/deprecated/workspace-executors.md

@@ -8,13 +8,13 @@ In Nx 13.10+, local nx plugins can contain executors that are used in the worksp
 
 ```shell
 npm add -D @nx/plugin
-nx g @nx/plugin:plugin my-plugin
+nx g @nx/plugin:plugin my-plugin --directory=tools/my-plugin
 ```
 
 - Use the Nx CLI to generate the initial files needed for your executor. Replace `my-executor` with the name of your workspace executor.
 
 ```shell
-nx generate @nx/plugin:executor my-executor --project=my-plugin
+nx generate @nx/plugin:executor my-executor --directory=tools/my-plugin/src/executors/my-executor
 ```
 
 - Copy the code for your workspace executor into the newly created executor's folder. e.g. `libs/my-plugin/src/executors/my-executor/`

docs/shared/deprecated/workspace-generators.md

@@ -16,13 +16,13 @@ When migrating to Nx 16, a new workspace plugin is automatically generated in th
 
 ```shell
 npm add -D @nx/plugin
-nx g @nx/plugin:plugin my-plugin
+nx g @nx/plugin:plugin my-plugin --directory=tools/my-plugin
 ```
 
 - Use the Nx CLI to generate the initial files needed for your generator. Replace `my-generator` with the name of your workspace generator.
 
 ```shell
-nx generate @nx/plugin:generator my-generator --project=my-plugin
+nx generate @nx/plugin:generator my-generator --directory=tools/my-plugin/src/generators/my-generator
 ```
 
 - Copy the code for your workspace generator into the newly created generator's folder. e.g. `libs/my-plugin/src/generators/my-generator/`

docs/shared/features/cache-task-results.md

@@ -87,7 +87,7 @@ To achieve this, we can add an `inputs` and `outputs` definition globally for al
   "targetDefaults": {
     "build": {
       "inputs": ["{projectRoot}/**/*", "!{projectRoot}/**/*.md"],
-      "outputs": ["{workspaceRoot}/dist/{projectName"]
+      "outputs": ["{workspaceRoot}/dist/{projectName}"]
     }
   }
 }
@@ -112,6 +112,7 @@ To achieve this, we can add an `inputs` and `outputs` definition globally for al
 ```
 
 {% /tab %}
+{% /tabs %}
 
 Note, you only need to define output locations if they differ from the usual `dist` or `build` directory which Nx automatically recognizes.
 

docs/shared/features/run-tasks.md

@@ -135,7 +135,10 @@ Learn all the details:
 
 ## Run Root-Level Tasks
 
-Sometimes you have tasks that apply to the entire codebase rather than to a single project. But you still want those tasks to go through the "Nx pipeline" in order to benefit from caching. You can define these in the root-level `package.json` as follows:
+Sometimes you have tasks that apply to the entire codebase rather than to a single project. But you still want those tasks to go through the "Nx pipeline" in order to benefit from caching. You can define these in the root-level `package.json` or `project.json` as follows:
+
+{% tabs %}
+{% tab label="package.json" %}
 
 ```json {% fileName="package.json" %}
 {
@@ -149,12 +152,6 @@ Sometimes you have tasks that apply to the entire codebase rather than to a sing
 
 > Note the `nx: {}` property on the `package.json`. This is necessary to inform Nx about this root-level project. The property can also be expanded to specify cache inputs and outputs.
 
-To invoke it, use:
-
-```shell
-npx nx docs
-```
-
 If you want Nx to cache the task, but prefer to use npm (or pnpm/yarn) to run the script (i.e. `npm run docs`) you can use the [nx exec](/nx-api/nx/documents/exec) command:
 
 ```json {% fileName="package.json" %}
@@ -167,4 +164,28 @@ If you want Nx to cache the task, but prefer to use npm (or pnpm/yarn) to run th
 }
 ```
 
+{% /tab %}
+{% tab label="project.json" %}
+
+```json {% fileName="project.json"%}
+{
+  "name": "myorg",
+  ...
+  "targets": {
+    "docs": {
+      "command": "node ./generateDocsSite.js"
+    }
+  }
+}
+```
+
+{% /tab %}
+{% /tabs %}
+
+To invoke the task, use:
+
+```shell
+npx nx docs
+```
+
 Learn more about root-level tasks [in our dedicated recipe page](/recipes/running-tasks/root-level-scripts).

docs/shared/guides/define-environment-variables.md

@@ -5,7 +5,7 @@ Environment variables are useful to store system-wide values such as the directo
 (PATH), OS version, Network Information, and custom variables. These env variables are passed at build time and used at
 the runtime of an app.
 
-## Setting environment variables
+## Set Environment Variables
 
 By default, Nx will load any environment variables you place in the following files:
 
@@ -53,7 +53,30 @@ We recommend nesting your **app** specific `env` files in `apps/your-app`, and c
 for workspace-specific settings (like the [Nx Cloud token](/ci/recipes/security/access-tokens)).
 {% /callout %}
 
-### Pointing to custom env files
+### Environment Variables for Configurations
+
+Nx will only load environment variable files for a particular configuration if that configuration is defined for a task, even if you specify that configuration name from the command line. So if there is no `development` configuration defined for the `app`'s `build` task, the following command will use `.env.build` instead of `.env.build.development`:
+
+```shell
+nx build app --development
+```
+
+In order to have Nx actually use the `.env.build.development` environment variables, the `development` configuration needs to be set for the task (even if it is empty).
+
+```jsonc {% fileName="apps/app/project.json" highlightLines=["5-7"] %}
+{
+  "targets": {
+    "build": {
+      // ...
+      "configurations": {
+        "development": {}
+      }
+    }
+  }
+}
+```
+
+### Point to Custom Env Files
 
 If you want to load variables from `env` files other than the ones listed above:
 
@@ -61,7 +84,7 @@ If you want to load variables from `env` files other than the ones listed above:
 2. Use [dotenvx](https://github.com/dotenvx/dotenvx): `dotenvx run --env-file=.qa.env -- nx serve`
 3. Use the `envFile` option of the [run-commands](/nx-api/nx/executors/run-commands#envfile) builder and execute your command inside of the builder
 
-### Ad-hoc variables
+### Ad-hoc Variables
 
 You can also define environment variables in an ad-hoc manner using support from your OS and shell.
 

docs/shared/guides/use-environment-variables-in-react.md

@@ -58,7 +58,7 @@ In React applications (e.g. those using the `@nx/web:webpack` executor or an [in
 includes the following variables in the build process:
 
 - `NODE_ENV`
-- Variables prefixed with `NX_PUBLIC`, such as `NX_PUBLIC_CUSTOM_VAR` (when using the [NxWebpackPlugin](/recipes/webpack/webpack-plugins#nxwebpackplugin) or the [withNx](/recipes/webpack/webpack-plugins#withnx) plugins)
+- Variables prefixed with `NX_PUBLIC`, such as `NX_PUBLIC_CUSTOM_VAR` (when using the [NxAppWebpackPlugin](/recipes/webpack/webpack-plugins#nxappwebpackplugin) or the [withNx](/recipes/webpack/webpack-plugins#withnx) plugins)
 
 Defining environment variables can vary between OSes. It's also important to know that this is temporary for the life of
 the shell session.
@@ -66,7 +66,7 @@ the shell session.
 ### Using environment variables in `index.html`
 
 Nx supports interpolating environment variables into your `index.html` file for React and Web applications built with Webpack.
-This feature is available when using the [NxWebpackPlugin](/recipes/webpack/webpack-plugins#nxwebpackplugin) or the [withNx](/recipes/webpack/webpack-plugins#withnx) plugins.
+This feature is available when using the [NxAppWebpackPlugin](/recipes/webpack/webpack-plugins#nxappwebpackplugin) or the [withNx](/recipes/webpack/webpack-plugins#withnx) plugins.
 
 {% callout type="note" title="Predefined Nx variable" %}
 Note that with the release of Nx 19, you won't be able to use predefined Nx variable on this [link](/reference/environment-variables).

docs/shared/migration/adding-to-existing-project.md

@@ -1,6 +1,6 @@
 # Adding Nx to your Existing Project
 
-Nx can be added to any type of project, not just monorepos. The main benefit is to get caching abilities for the package
+Nx can be added to any type of project, not just monorepos. A large benefit of Nx is its caching feature for package
 scripts. Each project usually has a set of scripts in the `package.json`:
 
 ```json {% fileName="package.json" %}
@@ -14,12 +14,14 @@ scripts. Each project usually has a set of scripts in the `package.json`:
 }
 ```
 
-You can make these scripts faster by leveraging Nx's caching capabilities. For example:
+You can make these scripts faster by leveraging Nx's [caching capabilities](/features/cache-task-results). For example:
 
 - You change some spec files: in that case the `build` task can be cached and doesn't have to re-run.
 - You update your docs, changing a couple of markdown files: then there's no need to re-run builds, tests, linting on
   your CI. All you might want to do is trigger the Docusaurus build.
 
+Additionally, Nx also [speeds up your CI ⚡](#fast-ci) with [remote caching](/ci/features/remote-cache) and [distributed task execution](/ci/features/distribute-task-execution).
+
 ## Install Nx on a Non-Monorepo Project
 
 Run the following command:
@@ -284,7 +286,7 @@ Now if you run `npm run test` or `nx test` twice, the results will be retrieved
 this example are as cautious as possible, so you can significantly improve the value of the cache
 by [customizing Nx Inputs](/recipes/running-tasks/configure-inputs) for each task.
 
-## Set Up CI for Your Workspace
+## Fast CI ⚡ {% highlightColor="green" %}
 
 This tutorial walked you through how Nx can improve the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
 
@@ -293,53 +295,93 @@ This tutorial walked you through how Nx can improve the local development experi
 - Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
 - Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
 
-### Generate a CI Workflow
-
-If you are starting a new project, you can use the following command to generate a CI workflow file.
-
-```shell
-npx nx generate ci-workflow --ci=github
-```
-
-{% callout type="note" title="Choose your CI provider" %}
-You can choose `github`, `circleci`, `azure`, `bitbucket-pipelines`, or `gitlab` for the `ci` flag.
-{% /callout %}
-
-This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR.
-
-The key line in the CI pipeline is:
-
-```yml
-- run: npx nx affected -t lint test build e2e-ci
-```
-
-### Connect to Nx Cloud
+### Connect to Nx Cloud {% highlightColor="green" %}
 
 Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.
 
-To connect to Nx Cloud:
+Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.
 
-- Commit and push your changes
-- Go to [https://cloud.nx.app](https://cloud.nx.app), create an account, and connect your repository
+1. Commit your existing changes with `git add . && git commit -am "updates"`
+2. [Create a new GitHub repository](https://github.com/new)
+3. Follow GitHub's instructions to push your existing code to the repository
 
-#### Connect to Nx Cloud Manually
-
-If you are not able to connect via the automated process at [https://cloud.nx.app](https://cloud.nx.app), you can connect your workspace manually by running:
+Now connect your repository to Nx Cloud with the following command:
 
 ```shell
 npx nx connect
 ```
 
-You will then need to merge your changes and connect to your workspace on [https://cloud.nx.app](https://cloud.nx.app).
+A browser window will open to register your repository in your [Nx Cloud](https://cloud.nx.app) account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.
 
-### Enable a Distributed CI Pipeline
+![](/shared/tutorials/nx-cloud-github-connect.avif)
 
-The current CI pipeline runs on a single machine and can only handle small workspaces. To transform your CI into a CI that runs on multiple machines and can handle workspaces of any size, uncomment the `npx nx-cloud start-ci-run` line in the `.github/workflows/ci.yml` file.
+Once the PR is created, merge it into your main branch.
 
-```yml
-- run: npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+![](/shared/tutorials/github-cloud-pr-merged.avif)
+
+And make sure you pull the latest changes locally:
+
+```shell
+git pull
 ```
 
+You should now have an `nxCloudAccessToken` property specified in the `nx.json` file.
+
+### Create a CI Workflow {% highlightColor="green" %}
+
+Use the following command to generate a CI workflow file.
+
+```shell
+npx nx generate ci-workflow --ci=github
+```
+
+This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR. Since we are using Nx Cloud, the pipeline will also distribute tasks across multiple machines to ensure fast and reliable CI runs.
+
+The key lines in the CI pipeline are:
+
+```yml {% fileName=".github/workflows/ci.yml" highlightLines=["10-14", "21-22"] %}
+name: CI
+# ...
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="build"
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 20
+          cache: 'npm'
+      - run: npm ci --legacy-peer-deps
+      - uses: nrwl/nx-set-shas@v4
+      # Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
+      - run: npx nx affected -t lint test build
+```
+
+### Open a Pull Request {% highlightColor="green" %}
+
+Commit the changes and open a new PR on GitHub.
+
+```shell
+git add .
+git commit -m 'add CI workflow file'
+git push origin add-workflow
+```
+
+When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.
+
+![Nx Cloud report](/shared/tutorials/github-pr-cloud-report.avif)
+
+The `See all runs` link goes to a page with the progress and results of tasks that were run in the CI pipeline.
+
+![Run details](/shared/tutorials/nx-cloud-run-details.avif)
+
 For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:
 
 - [Circle CI with Nx](/ci/intro/tutorials/circle)

docs/shared/migration/adding-to-monorepo.md

@@ -6,14 +6,12 @@ powering Nx underneath. As a result, Lerna gets all the modern features such as
 on [https://lerna.js.org/upgrade](https://lerna.js.org/upgrade).
 {% /callout %}
 
-Nx has first-class support for [monorepos](/getting-started/tutorials/npm-workspaces-tutorial). As a result, if you have
+Nx has first-class support for [monorepos](/getting-started/tutorials/npm-workspaces-tutorial). If you have
 an existing NPM/Yarn or PNPM-based monorepo setup, you can easily add Nx to get
 
 - fast [task scheduling](/features/run-tasks)
-- support for [task pipelines](/concepts/task-pipeline-configuration)
-- [caching](/features/cache-task-results)
-- [remote caching with Nx Cloud](/ci/features/remote-cache)
-- [distributed task execution with Nx Cloud](/ci/features/distribute-task-execution)
+- high-performance task [caching](/features/cache-task-results)
+- [fast CI ⚡](#fast-ci) with [remote caching](/ci/features/remote-cache) and [distributed task execution](/ci/features/distribute-task-execution)
 
 This is a low-impact operation because all that needs to be done is to install the `nx` package at the root level and
 add an `nx.json` for configuring caching and task pipelines.
@@ -307,7 +305,7 @@ pnpm run -r test
 
 This allows for incrementally adopting Nx in your existing workspace.
 
-## Set Up CI for Your Workspace
+## Fast CI ⚡ {% highlightColor="green" %}
 
 This tutorial walked you through how Nx can improve the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
 
@@ -316,53 +314,93 @@ This tutorial walked you through how Nx can improve the local development experi
 - Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
 - Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
 
-### Generate a CI Workflow
-
-If you are starting a new project, you can use the following command to generate a CI workflow file.
-
-```shell
-npx nx generate ci-workflow --ci=github
-```
-
-{% callout type="note" title="Choose your CI provider" %}
-You can choose `github`, `circleci`, `azure`, `bitbucket-pipelines`, or `gitlab` for the `ci` flag.
-{% /callout %}
-
-This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR.
-
-The key line in the CI pipeline is:
-
-```yml
-- run: npx nx affected -t lint test build e2e-ci
-```
-
-### Connect to Nx Cloud
+### Connect to Nx Cloud {% highlightColor="green" %}
 
 Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.
 
-To connect to Nx Cloud:
+Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.
 
-- Commit and push your changes
-- Go to [https://cloud.nx.app](https://cloud.nx.app), create an account, and connect your repository
+1. Commit your existing changes with `git add . && git commit -am "updates"`
+2. [Create a new GitHub repository](https://github.com/new)
+3. Follow GitHub's instructions to push your existing code to the repository
 
-#### Connect to Nx Cloud Manually
-
-If you are not able to connect via the automated process at [https://cloud.nx.app](https://cloud.nx.app), you can connect your workspace manually by running:
+Now connect your repository to Nx Cloud with the following command:
 
 ```shell
 npx nx connect
 ```
 
-You will then need to merge your changes and connect to your workspace on [https://cloud.nx.app](https://cloud.nx.app).
+A browser window will open to register your repository in your [Nx Cloud](https://cloud.nx.app) account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.
 
-### Enable a Distributed CI Pipeline
+![](/shared/tutorials/nx-cloud-github-connect.avif)
 
-The current CI pipeline runs on a single machine and can only handle small workspaces. To transform your CI into a CI that runs on multiple machines and can handle workspaces of any size, uncomment the `npx nx-cloud start-ci-run` line in the `.github/workflows/ci.yml` file.
+Once the PR is created, merge it into your main branch.
 
-```yml
-- run: npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+![](/shared/tutorials/github-cloud-pr-merged.avif)
+
+And make sure you pull the latest changes locally:
+
+```shell
+git pull
 ```
 
+You should now have an `nxCloudAccessToken` property specified in the `nx.json` file.
+
+### Create a CI Workflow {% highlightColor="green" %}
+
+Use the following command to generate a CI workflow file.
+
+```shell
+npx nx generate ci-workflow --ci=github
+```
+
+This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR. Since we are using Nx Cloud, the pipeline will also distribute tasks across multiple machines to ensure fast and reliable CI runs.
+
+The key lines in the CI pipeline are:
+
+```yml {% fileName=".github/workflows/ci.yml" highlightLines=["10-14", "21-22"] %}
+name: CI
+# ...
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="build"
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 20
+          cache: 'npm'
+      - run: npm ci --legacy-peer-deps
+      - uses: nrwl/nx-set-shas@v4
+      # Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
+      - run: npx nx affected -t lint test build
+```
+
+### Open a Pull Request {% highlightColor="green" %}
+
+Commit the changes and open a new PR on GitHub.
+
+```shell
+git add .
+git commit -m 'add CI workflow file'
+git push origin add-workflow
+```
+
+When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.
+
+![Nx Cloud report](/shared/tutorials/github-pr-cloud-report.avif)
+
+The `See all runs` link goes to a page with the progress and results of tasks that were run in the CI pipeline.
+
+![Run details](/shared/tutorials/nx-cloud-run-details.avif)
+
 For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:
 
 - [Circle CI with Nx](/ci/intro/tutorials/circle)

docs/shared/migration/migration-angular.md

@@ -117,53 +117,93 @@ This tutorial walked you through how Nx can improve the local development experi
 - Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
 - Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
 
-### Generate a CI Workflow
-
-If you are starting a new project, you can use the following command to generate a CI workflow file.
-
-```shell
-npx nx generate ci-workflow --ci=github
-```
-
-{% callout type="note" title="Choose your CI provider" %}
-You can choose `github`, `circleci`, `azure`, `bitbucket-pipelines`, or `gitlab` for the `ci` flag.
-{% /callout %}
-
-This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR.
-
-The key line in the CI pipeline is:
-
-```yml
-- run: npx nx affected -t lint test build e2e-ci
-```
-
 ### Connect to Nx Cloud
 
 Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.
 
-To connect to Nx Cloud:
+Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.
 
-- Commit and push your changes
-- Go to [https://cloud.nx.app](https://cloud.nx.app), create an account, and connect your repository
+1. Commit your existing changes with `git add . && git commit -am "updates"`
+2. [Create a new GitHub repository](https://github.com/new)
+3. Follow GitHub's instructions to push your existing code to the repository
 
-#### Connect to Nx Cloud Manually
-
-If you are not able to connect via the automated process at [https://cloud.nx.app](https://cloud.nx.app), you can connect your workspace manually by running:
+Now connect your repository to Nx Cloud with the following command:
 
 ```shell
 npx nx connect
 ```
 
-You will then need to merge your changes and connect to your workspace on [https://cloud.nx.app](https://cloud.nx.app).
+A browser window will open to register your repository in your [Nx Cloud](https://cloud.nx.app) account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.
 
-### Enable a Distributed CI Pipeline
+![](/shared/tutorials/nx-cloud-github-connect.avif)
 
-The current CI pipeline runs on a single machine and can only handle small workspaces. To transform your CI into a CI that runs on multiple machines and can handle workspaces of any size, uncomment the `npx nx-cloud start-ci-run` line in the `.github/workflows/ci.yml` file.
+Once the PR is created, merge it into your main branch.
 
-```yml
-- run: npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+![](/shared/tutorials/github-cloud-pr-merged.avif)
+
+And make sure you pull the latest changes locally:
+
+```shell
+git pull
 ```
 
+You should now have an `nxCloudAccessToken` property specified in the `nx.json` file.
+
+### Create a CI Workflow
+
+Use the following command to generate a CI workflow file.
+
+```shell
+npx nx generate ci-workflow --ci=github
+```
+
+This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR. Since we are using Nx Cloud, the pipeline will also distribute tasks across multiple machines to ensure fast and reliable CI runs.
+
+The key lines in the CI pipeline are:
+
+```yml {% fileName=".github/workflows/ci.yml" highlightLines=["10-14", "21-22"] %}
+name: CI
+# ...
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="build"
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 20
+          cache: 'npm'
+      - run: npm ci --legacy-peer-deps
+      - uses: nrwl/nx-set-shas@v4
+      # Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
+      - run: npx nx affected -t lint test build
+```
+
+### Open a Pull Request
+
+Commit the changes and open a new PR on GitHub.
+
+```shell
+git add .
+git commit -m 'add CI workflow file'
+git push origin add-workflow
+```
+
+When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.
+
+![Nx Cloud report](/shared/tutorials/github-pr-cloud-report.avif)
+
+The `See all runs` link goes to a page with the progress and results of tasks that were run in the CI pipeline.
+
+![Run details](/shared/tutorials/nx-cloud-run-details.avif)
+
 For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:
 
 - [Circle CI with Nx](/ci/intro/tutorials/circle)

docs/shared/monorepo-ci-azure.md

@@ -48,7 +48,7 @@ jobs:
 
       # Connect your workspace on nx.app and uncomment this to enable task distribution.
       # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-      # - script: yarn nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+      # - script: yarn nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
 
       - script: yarn install --frozen-lockfile
       - script: git branch --track main origin/main
@@ -56,7 +56,7 @@ jobs:
 
       # Prepend any command with "nx-cloud record --" to record its logs to Nx Cloud
       # - script: yarn nx-cloud record -- echo Hello World
-      - script: yarn nx affected --base=$(BASE_SHA) --head=$(HEAD_SHA) lint test build
+      - script: yarn nx affected --base=$(BASE_SHA) --head=$(HEAD_SHA) --targets lint test build
       - script: yarn nx affected --base=$(BASE_SHA) --head=$(HEAD_SHA) --parallel 1 e2e-ci
 ```
 

docs/shared/monorepo-ci-bitbucket-pipelines.md

@@ -16,7 +16,7 @@ pipelines:
           script:
             # This line enables distribution
             # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-            - npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+            - npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
             - npm ci
 
             - npx nx-cloud record -- nx format:check
@@ -30,7 +30,7 @@ pipelines:
             - export NX_BRANCH=$BITBUCKET_BRANCH
             # This line enables distribution
             # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-            # - npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+            # - npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
             - npm ci
 
             - npx nx-cloud record -- nx format:check

docs/shared/monorepo-ci-circle-ci.md

@@ -16,7 +16,7 @@ jobs:
       - checkout
       # This line enables distribution
       # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-      # - run: npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+      # - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
       - run: npm ci
 
       - nx/set-shas

docs/shared/monorepo-ci-github-actions.md

@@ -29,7 +29,7 @@ jobs:
           cache: 'npm'
       # This line enables distribution
       # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-      # - run: npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+      # - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
       - run: npm ci
 
       - uses: nrwl/nx-set-shas@v4

docs/shared/monorepo-ci-gitlab.md

@@ -22,7 +22,7 @@ main:
   script:
     # Connect your workspace on <%= nxCloudHost %> and uncomment this to enable task distribution.
     # The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-    # - npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+    # - npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
 
     - npm ci --cache .npm --prefer-offline
     - NX_HEAD=$CI_COMMIT_SHA

docs/shared/monorepo-ci-jenkins.md

@@ -19,7 +19,7 @@ pipeline {
                     steps {
                         // This line enables distribution
                         // The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-                        // sh "npx nx-cloud start-ci-run --distribute-on='5 linux-medium-js' --stop-agents-after='e2e-ci'"
+                        // sh "npx nx-cloud start-ci-run --distribute-on='3 linux-medium-js' --stop-agents-after='e2e-ci'"
                         sh "npm ci"
                         sh "npx nx-cloud record -- nx format:check"
                         sh "npx nx affected --base=HEAD~1 -t lint test build e2e-ci"
@@ -33,7 +33,7 @@ pipeline {
                     steps {
                         // This line enables distribution
                         // The "--stop-agents-after" is optional, but allows idle agents to shut down once the "e2e-ci" targets have been requested
-                        // sh "npx nx-cloud start-ci-run --distribute-on='5 linux-medium-js' --stop-agents-after='e2e-ci'"
+                        // sh "npx nx-cloud start-ci-run --distribute-on='3 linux-medium-js' --stop-agents-after='e2e-ci'"
                         sh "npm ci"
                         sh "npx nx-cloud record -- nx format:check"
                         sh "npx nx affected --base origin/${env.CHANGE_TARGET} -t lint test build e2e-ci"

docs/shared/packages/cypress/cypress-plugin.md

@@ -56,9 +56,7 @@ The `@nx/cypress` plugin will create a task for any project that has a Cypress c
 - `cypress.config.js`
 - `cypress.config.ts`
 - `cypress.config.mjs`
-- `cypress.config.mts`
 - `cypress.config.cjs`
-- `cypress.config.cts`
 
 ### View Inferred Tasks
 

docs/shared/packages/nest/nest-plugin.md

@@ -150,6 +150,26 @@ You can lint a library with the following command:
 nx lint my-nest-lib
 ```
 
+## Deployment
+
+Ensuring a smooth and reliable deployment of a Nest.js application in a production environment requires careful planning and the right strategy. Depending on your specific needs and infrastructure, you can choose from several deployment approaches. Below are four commonly used methods:
+
+1. **Using Docker:**
+   Create a Dockerfile that specifies the application's environment and dependencies. Build a Docker image and optionally push it to a container registry. Deploy and run the Docker container on the server. Utilize the `@nx/node:setup-docker` generator to streamline the Docker setup process.
+
+2. **Installing Dependencies on the Server:**
+   Transfer the build artifacts to the server, install all dependencies using the package manager of your choice, and start the application. Ensure that [NxAppWebpackPlugin](/recipes/webpack/webpack-plugins#nxappwebpackplugin) is configured with `generatePackageJson: true` so that the build artifacts directory includes `package.json` and `package-lock.json` (or the equivalent files for other package managers).
+
+3. **Transferring Pre-installed Dependencies:**
+   Install dependencies during the build process, and transfer the build artifacts along with the `node_modules` directory to the server. Typically, the artifacts are archived for faster transfer and then unarchived on the server.
+
+4. **Bundling Dependencies:**
+   By default, Nx/Nest creates a setup that externalizes all dependencies, meaning they are not included in the bundle. This behavior can be adjusted using the `externalDependencies` parameter in the webpack configuration with [NxAppWebpackPlugin](/recipes/webpack/webpack-plugins#nxappwebpackplugin). After bundling, transfer the package to the server and start the application.
+
+{% callout type="note" title="Bundling Dependencies" %}
+Bundling dependencies is typically not recommended for Node applications.
+{% /callout %}
+
 ### Unit Test
 
 You can run unit test for an application with the following command:

docs/shared/packages/webpack/webpack-config-setup.md

@@ -80,7 +80,7 @@ module.exports = {
 };
 ```
 
-The [`NxWebpackPlugin`](/recipes/webpack/webpack-plugins#nxwebpackplugin) plugin takes a `main` entry file and produces a bundle in the output directory as defined in `output.path`. You can also pass the `index` option if it is a webapp, which will handle outputting scripts and stylesheets in the output file. Note that `NxWebpackPlugin` is optional, and you can bring your own Webpack configuration without using it or any plugins from `@nx/webpack`.
+The [`NxAppWebpackPlugin`](/recipes/webpack/webpack-plugins#nxappwebpackplugin) plugin takes a `main` entry file and produces a bundle in the output directory as defined in `output.path`. You can also pass the `index` option if it is a webapp, which will handle outputting scripts and stylesheets in the output file. Note that `NxWebpackPlugin` is optional, and you can bring your own Webpack configuration without using it or any plugins from `@nx/webpack`.
 
 For more information, see the [Webpack plugins guide](/recipes/webpack/webpack-plugins).
 

docs/shared/packages/webpack/webpack-plugins.md

@@ -23,9 +23,9 @@ the [Nx Webpack configuration guide](/recipes/webpack/webpack-config-setup).
 
 The basic plugins work with a standard webpack configuration file by adding them to the `plugins` option.
 
-### NxWebpackPlugin
+### NxAppWebpackPlugin
 
-The `NxWebpackPlugin` plugin provides common configuration for the build, including TypeScript support and linking
+The `NxAppWebpackPlugin` plugin provides common configuration for the build, including TypeScript support and linking
 workspace libraries (via tsconfig paths).
 
 #### Options
@@ -71,6 +71,12 @@ Type: `string`
 
 Set `<base href>` for the resulting index.html.
 
+##### buildLibsFromSource
+
+Type: `boolean`
+
+Build the libraries from source. Default is `true`.
+
 ##### compiler
 
 Type: `'babel' | 'swc' | 'tsc'`

docs/shared/plugins/create-plugin.md

@@ -3,7 +3,7 @@
 To get started with building a local Nx Plugin, install the `@nx/plugin` package and generate a plugin:
 
 ```shell
-nx g @nx/plugin:plugin my-plugin
+nx g @nx/plugin:plugin my-plugin --directory=tools/my-plugin
 ```
 
 This will create a `my-plugin` project that contains all your plugin code and `my-plugin-e2e` for e2e tests.
@@ -15,7 +15,7 @@ This will create a `my-plugin` project that contains all your plugin code and `m
 To create a new generator run:
 
 ```shell
-nx generate @nx/plugin:generator my-generator --project=my-plugin
+nx generate @nx/plugin:generator my-generator --directory="tools/my-plugin/src/generators/my-generator"
 ```
 
 The new generator is located in `/src/generators/my-generator`. The `my-generator.ts` file contains the code that runs the generator. This generator creates a new project using a folder of template files.

docs/shared/recipes/ci-deployment.md

@@ -35,9 +35,9 @@ It is configured in the `plugins` array in `nx.json`.
 
 Where `build`, `serve`, `serve-static` and `preview` in conjunction with your `webpack.config.js` are the names of the targets that are used to _build_, _serve_, and _preview_ the application respectively.
 
-### NxWebpackPlugin
+### NxAppWebpackPlugin
 
-The [`NxWebpackPlugin`](/recipes/webpack/webpack-plugins#nxwebpackplugin) plugin takes a `main` entry file and produces a bundle in the output directory as defined in `output.path`. You can also pass the `index` option if it is a web app, which will handle outputting scripts and stylesheets in the output file.
+The [`NxAppWebpackPlugin`](/recipes/webpack/webpack-plugins#nxappwebpackplugin) plugin takes a `main` entry file and produces a bundle in the output directory as defined in `output.path`. You can also pass the `index` option if it is a web app, which will handle outputting scripts and stylesheets in the output file.
 
 To generate a `package.json` we would declare it in the plugin options.
 

docs/shared/recipes/generators/local-generators.md

@@ -16,7 +16,7 @@ If you don't already have a local plugin, use Nx to generate one:
 
 ```shell {% skipRescope=true %}
 nx add @nx/plugin
-nx g @nx/plugin:plugin my-plugin
+nx g @nx/plugin:plugin my-plugin --directory=tools/my-plugin
 ```
 
 Note that `latest` should match the version of the `nx` plugins installed in your workspace.
@@ -24,7 +24,7 @@ Note that `latest` should match the version of the `nx` plugins installed in you
 Use the Nx CLI to generate the initial files needed for your generator.
 
 ```shell
-nx generate @nx/plugin:generator my-generator --project=my-plugin
+nx generate @nx/plugin:generator my-generator --directory=tools/my-plugin/src/generators/my-generator
 ```
 
 After the command is finished, the generator is created in the plugin `generators` folder.
@@ -32,7 +32,7 @@ After the command is finished, the generator is created in the plugin `generator
 ```text
 happynrwl/
 ├── apps/
-├── libs/
+├── tools/
 │   ├── my-plugin
 │   │   ├── src
 │   │   │   ├── generators

docs/shared/recipes/nx-release/automate-github-releases.md

@@ -2,6 +2,19 @@
 
 Nx Release can automate the creation of [GitHub releases](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository) for you. GitHub releases are a great way to communicate the changes in your projects to your users.
 
+<!-- Prettier will mess up the end tag of the callout causing it to capture all content that follows it -->
+<!-- prettier-ignore-start -->
+
+{% callout type="note" title="Authenticating with GitHub" %}
+In order to be able to create the release on GitHub, you need to provide a valid token which can be used for authenticating with the GitHub API.
+
+Nx release supports two main ways of doing this:
+
+1. In all environments it will preferentially check for an environment variable (the environment variable can either be called `GITHUB_TOKEN` or `GH_TOKEN`). Please ensure that this environment variable is set in your CI environment (and that the token it has been set to has been configured with the appropriate permissions to create releases) before attempting to create a release in CI.
+2. It can also detect if you have a valid, authenticated installation of the official `gh` CLI tool (https://cli.github.com/) and leverage that automatically as a fallback when no environment variable is set.
+{% /callout %}
+<!-- prettier-ignore-end -->
+
 ## GitHub Release Contents
 
 When a GitHub release is created, it will include the changelog that Nx Release generates with entries based on the changes since the last release. Nx Release will parse the `feat` and `fix` type commits according to the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification and sort them into appropriate sections of the changelog. Take a look at the [Nx releases page](https://github.com/nrwl/nx/releases) to see examples of GitHub releases generated by Nx Release.

docs/shared/recipes/nx-release/get-started-with-nx-release.md

@@ -270,6 +270,8 @@ For this same example, if you want the commit message to be 'chore(release): 1.2
 }
 ```
 
+When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
+
 ## Future Releases
 
 After the first release, the `--first-release` option will no longer be required. Nx Release will expect to find git tags and changelog files for each package. It will also use `npm view` to look up the current version of packages before publishing, ensuring that the package has not already been published and therefore avoid any conflict errors, meaning you can run the same publish action multiple times without any negative side-effects.

docs/shared/recipes/nx-release/publish-rust-crates.md

@@ -209,6 +209,8 @@ For this same example, if you want the commit message to be 'chore(release): 1.2
 }
 ```
 
+When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
+
 ## Future Releases
 
 After the first release, the `--first-release` option will no longer be required. Nx Release will expect to find git tags and changelog files for each package.

docs/shared/recipes/plugins/local-executors.md

@@ -10,13 +10,13 @@ If you don't already have a local plugin, use Nx to generate one:
 
 ```shell {% skipRescope=true %}
 nx add @nx/plugin
-nx g @nx/plugin:plugin libs/my-plugin
+nx g @nx/plugin:plugin my-plugin --directory tools/my-plugin
 ```
 
 Use the Nx CLI to generate the initial files needed for your executor.
 
 ```shell
-nx generate @nx/plugin:executor echo --directory=libs/my-plugin/src/executors/echo
+nx generate @nx/plugin:executor echo --directory=tools/my-plugin/src/executors/echo
 ```
 
 After the command is finished, the executor is created in the plugin `executors` folder.
@@ -24,7 +24,7 @@ After the command is finished, the executor is created in the plugin `executors`
 ```text
 happynrwl/
 ├── apps/
-├── libs/
+├── tools/
 │   ├── my-plugin
 │   │   ├── src
 │   │   │   ├── executors

docs/shared/reference/nx-json.md

@@ -347,7 +347,7 @@ The `projectsRelationship` property tells Nx whether to release projects indepen
 
 Optionally override the git/release tag pattern to use. This field is the source of truth for changelog generation and release tagging, as well as for conventional commits parsing.
 
-It supports interpolating the version as `{version}` and (if releasing independently or forcing project level version control system releases) the project name as `{projectName}` within the string.
+It supports interpolating the version as `{version}` and (if releasing independently or forcing project level version control system releases) the project name as `{projectName}` within the string. When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
 
 The default `"releaseTagPattern"` for fixed/unified releases is: `v{version}`
 

docs/shared/reference/project-configuration.md

@@ -200,6 +200,26 @@ If you are using distributed task execution and disable caching for a given targ
 
 {% /callout %}
 
+### Parallelism
+
+In Nx 19.5.0+, tasks can be configured to support parallelism or not. By default, tasks are run in parallel with other tasks on a given machine. However, in some cases, tasks can require a shared resource such as a port or memory. For these cases, setting `"parallelism": false`, will ensure that those tasks will not run in parallel with other tasks on a single machine. For example, if the `e2e` tasks all require port 4200, running them in parallel will conflict so the targets can specify to not support parallelism:
+
+```json {% fileName="project.json" %}
+{
+  "targets": {
+    "e2e": {
+      "parallelism": false
+    }
+  }
+}
+```
+
+{% callout type="warning" title="Note: Parallelism is only per machine" %}
+
+If you are using distributed task execution, tasks will still be run simultaneously on different machines. Because different agents do not share resources with one another, it is perfectly fine for multiple agents to run tasks which do not support parallelism at the same time. Therefore, using Nx Agents is key to running tasks which do not support parallelism quickly and efficiently.
+
+{% /callout %}
+
 ### Inputs and Named Inputs
 
 Each cacheable task needs to define `inputs` which determine whether the task outputs can be retrieved from the cache or the task needs to be re-run. The `namedInputs` defined in `nx.json` or project level configuration are sets of reusable input definitions.
@@ -420,6 +440,27 @@ You can also express task dependencies with an object syntax:
 {% /tab %}
 {% /tabs %}
 
+Starting from v19.5.0, wildcards can be used to define dependencies in the `dependsOn` field.
+
+```json
+{
+  "targets": {
+    "test": {
+      "dependsOn": [
+        {
+          "target": "build", // target name
+          "params": "ignore" // "forward" or "ignore", defaults to "ignore"
+        },
+        "build-*", // support for using wildcards in dependsOn, matches: "build-css", "build-js" targets of current project
+        "^build-*", // matches tasks: "build-css", "build-js" targets of dependencies
+        "*build-*", // matches tasks: "build-css", "build-js" as well as "task-with-build-in-middle" targets of current project
+        "^*build-*" // matches tasks: "build-css", "build-js" as well as "task-with-build-in-middle" targets of dependencies
+      ]
+    }
+  }
+}
+```
+
 #### Examples
 
 You can write the shorthand configuration above in the object syntax like this:

docs/shared/reference/sitemap.md

@@ -290,7 +290,6 @@
         - [Authenticate with BitBucket](/ci/recipes/enterprise/on-premise/auth-bitbucket)
         - [Authenticate with BitBucket Data Center](/ci/recipes/enterprise/on-premise/auth-bitbucket-data-center)
         - [Authenticate via SAML](/ci/recipes/enterprise/on-premise/auth-saml)
-        - [Authenticate via SAML on Managed Version](/ci/recipes/enterprise/on-premise/auth-saml-managed)
         - [Advanced Configuration](/ci/recipes/enterprise/on-premise/advanced-config)
         - [Custom GitHub App](/ci/recipes/enterprise/on-premise/custom-github-app)
       - [Custom Distributed Task Execution](/ci/recipes/enterprise/dte)

docs/shared/tutorials/angular-monorepo.md

@@ -7,12 +7,13 @@ description: In this tutorial you'll create a frontend-focused workspace with Nx
 
 In this tutorial you'll learn how to use Angular with Nx in a [monorepo (integrated) setup](/concepts/integrated-vs-package-based#integrated-repos).
 
-What are you going to learn?
+What will you learn?
 
 - how to create a new Angular application
 - how to run a single task (i.e. serve your app) or run multiple tasks in parallel
 - how to leverage code generators to scaffold components
 - how to modularize your codebase and impose architectural constraints for better maintainability
+- [how to speed up CI with Nx Cloud ⚡](#fast-ci)
 
 {% callout type="info" title="Looking for an Angular standalone app?" %}
 Note, this tutorial sets up a repo with applications and libraries in their own subfolders. If you are looking for an Angular standalone app setup then check out our [Angular standalone app tutorial](/getting-started/tutorials/angular-standalone-tutorial).
@@ -40,14 +41,14 @@ Here's the source code of the final result for this tutorial.
 
 <!-- {% stackblitz-button url="github.com/nrwl/nx-recipes/tree/main/angular-standalone?file=README.md" /%} -->
 
-<!-- {% youtube
-src="https://www.youtube.com/embed/OQ-Zc5tcxJE"
-title="Tutorial: Standalone Angular Application"
-/%} -->
+{% youtube
+src="https://www.youtube.com/embed/ZzTP4bVJEnI"
+title="Nx Angular Monorepo Tutorial Walkthrough"
+/%}
 
 ## Creating a new Angular Monorepo
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=64" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=90" /%}
 
 Create a new Angular monorepo with the following command:
 
@@ -60,10 +61,10 @@ NX   Let's create a new workspace [https://nx.dev/getting-started/intro]
 ✔ Default stylesheet format · css
 ✔ Do you want to enable Server-Side Rendering (SSR) and Static Site Generation (SSG/Prerendering)? · No
 ✔ Test runner to use for end to end (E2E) tests · cypress
-✔ Do you want Nx Cloud to make your CI fast? · Yes
+✔ Which CI provider would you like to use? · github
 ```
 
-Let's name the initial application `angular-store`. In this tutorial we're going to use `cypress` for e2e tests and `css` for styling. The above command generates the following structure:
+Let's name the initial application `angular-store`. In this tutorial we're going to use `cypress` for e2e tests and `css` for styling. We'll talk more about how Nx integrates with GitHub Actions later in the tutorial. The above command generates the following structure:
 
 ```
 └─ angular-monorepo
@@ -112,12 +113,12 @@ The [`nx.json` file](/reference/nx-json) contains configuration settings for Nx
 
 ## Serving the App
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=207" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=138" /%}
 
 To serve your new Angular application, just run:
 
 ```shell
-nx serve angular-store
+npx nx serve angular-store
 ```
 
 Your application should be served at [http://localhost:4200](http://localhost:4200).
@@ -128,6 +129,8 @@ Nx uses the following syntax to run tasks:
 
 ### Manually Defined Tasks
 
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=160" /%}
+
 The project tasks are defined in the `project.json` file.
 
 ```json {% fileName="apps/angular-store/project.json"}
@@ -183,7 +186,7 @@ Learn more about how to [run tasks with Nx](/features/run-tasks). We'll [revisit
 
 ## Adding Another Application
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=706" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=182" /%}
 
 Nx plugins usually provide [generators](/features/generate-code) that allow you to easily scaffold code, configuration or entire projects. To see what capabilities the `@nx/angular` plugin provides, run the following command and inspect the output:
 
@@ -275,7 +278,7 @@ npx nx g @nx/angular:app inventory --directory=apps/inventory
 
 ## Sharing Code with Local Libraries
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=986" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=232" /%}
 
 When you develop your Angular application, usually all your logic sits in the `app` folder. Ideally separated by various folder names which represent your "domains". As your app grows, however, the app becomes more and more monolithic and the code is unable to be shared with other applications.
 
@@ -310,14 +313,14 @@ Nx allows you to separate this logic into "local libraries". The main benefits i
 
 ### Creating Local Libraries
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1041" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=254" /%}
 
 Let's assume our domain areas include `products`, `orders` and some more generic design system components, called `ui`. We can generate a new library for each of these areas using the Angular library generator:
 
 ```
-nx g @nx/angular:library products --directory=libs/products --standalone
-nx g @nx/angular:library orders --directory=libs/orders --standalone
-nx g @nx/angular:library shared-ui --directory=libs/shared/ui --standalone
+npx nx g @nx/angular:library products --directory=libs/products --standalone
+npx nx g @nx/angular:library orders --directory=libs/orders --standalone
+npx nx g @nx/angular:library shared-ui --directory=libs/shared/ui --standalone
 ```
 
 Note how we type out the full path in the `directory` flag to place the libraries into a subfolder. You can choose whatever folder structure you like to organize your projects. If you change your mind later, you can run the [move generator](/nx-api/workspace/generators/move) to move a project to a different folder.
@@ -360,14 +363,14 @@ Running the above commands should lead to the following directory structure:
 
 Each of these libraries
 
-- has its own `project.json` file with corresponding targets you can run (e.g. running tests for just orders: `nx test orders`)
+- has its own `project.json` file with corresponding targets you can run (e.g. running tests for just orders: `npx nx test orders`)
 - has the name you specified in the generate command; you can find the name in the corresponding `project.json` file
 - has a dedicated `index.ts` file which is the "public API" of the library
 - is mapped in the `tsconfig.base.json` at the root of the workspace
 
 ### Importing Libraries into the Angular Applications
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1245" /%} -->
+<!-- {% video-link link="https://youtu.be/ZzTP4bVJEnI?t=1245" /%} -->
 
 All libraries that we generate automatically have aliases created in the root-level `tsconfig.base.json`.
 
@@ -434,7 +437,7 @@ export const appRoutes: Route[] = [
 ];
 ```
 
-Serving your app (`nx serve angular-store`) and then navigating to `/products` should give you the following result:
+Serving your app (`npx nx serve angular-store`) and then navigating to `/products` should give you the following result:
 
 ![products route](/shared/tutorials/app-products-route.png)
 
@@ -491,14 +494,14 @@ export class AppComponent {
 
 ## Visualizing your Project Structure
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1416" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=364" /%}
 
-Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) and more. Interestingly you can also visualize it.
+Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `npx nx build`, identifying [affected projects](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) and more. Interestingly you can also visualize it.
 
 Just run:
 
 ```shell
-nx graph
+npx nx graph
 ```
 
 You should be able to see something similar to the following in your browser.
@@ -592,26 +595,28 @@ You should be able to see something similar to the following in your browser.
 
 Notice how `shared-ui` is not yet connected to anything because we didn't import it in any of our projects.
 
-Exercise for you: change the codebase such that `shared-ui` is used by `orders` and `products`. Note: you need to restart the `nx graph` command to update the graph visualization or run the CLI command with the `--watch` flag.
+Exercise for you: change the codebase such that `shared-ui` is used by `orders` and `products`. Note: you need to restart the `npx nx graph` command to update the graph visualization or run the CLI command with the `--watch` flag.
 
 ## Testing and Linting
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=410" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=410" /%}
 
 Our current setup not only has targets for serving and building the Angular application, but also has targets for unit testing, e2e testing and linting. The `test` and `lint` targets are defined in the application `project.json` file, while the `e2e` target is [inferred from the `apps/angular-store-e2e/cypress.config.ts` file](#inferred-tasks). We can use the same syntax as before to run these tasks:
 
 ```bash
-nx test angular-store # runs the tests for angular-store
-nx lint inventory # runs the linter on inventory
-nx e2e angular-store-e2e # runs e2e tests for the angular-store
+npx nx test angular-store # runs the tests for angular-store
+npx nx lint inventory # runs the linter on inventory
+npx nx e2e angular-store-e2e # runs e2e tests for the angular-store
 ```
 
 ### Inferred Tasks
 
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=424" /%}
+
 Nx identifies available tasks for your project from [tooling configuration files](/concepts/inferred-tasks), `package.json` scripts and the targets defined in `project.json`. All tasks from the `angular-store` project are defined in its `project.json` file, but the companion `angular-store-e2e` project has its tasks inferred from configuration files. To view the tasks that Nx has detected, look in the [Nx Console](/getting-started/editor-setup), [Project Details View](/recipes/nx-console/console-project-details) or run:
 
 ```shell
-nx show project angular-store-e2e --web
+npx nx show project angular-store-e2e --web
 ```
 
 {% project-details title="Project Details View" height="100px" %}
@@ -873,7 +878,7 @@ You can also override the settings for inferred tasks by modifying the [`targetD
 In addition to running individual tasks, you can also run multiple tasks in parallel using the following syntax:
 
 ```shell
-nx run-many -t test lint e2e
+npx nx run-many -t test lint e2e
 ```
 
 ### Caching
@@ -882,7 +887,7 @@ One thing to highlight is that Nx is able to [cache the tasks you run](/features
 
 Note that all of these targets are automatically cached by Nx. If you re-run a single one or all of them again, you'll see that the task completes immediately. In addition, (as can be seen in the output example below) there will be a note that a matching cache result was found and therefore the task was not run again.
 
-```{% command="nx run-many -t test lint e2e" path="angular-monorepo" %}
+```{% command="npx nx run-many -t test lint e2e" path="angular-monorepo" %}
 ✔  nx run e2e:lint  [existing outputs match the cache, left as is]
 ✔  nx run angular-store:lint  [existing outputs match the cache, left as is]
 ✔  nx run angular-store:test  [existing outputs match the cache, left as is]
@@ -899,6 +904,8 @@ Not all tasks might be cacheable though. You can [configure which tasks are cach
 
 ### Testing Affected Projects
 
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=551" /%}
+
 Commit your changes to git.
 
 ```shell
@@ -915,7 +922,7 @@ And then make a small change to the `products` library.
 One of the key features of Nx in a monorepo setting is that you're able to run tasks only for projects that are actually affected by the code changes that you've made. To run the tests for only the projects affected by this change, run:
 
 ```shell
-nx affected -t test
+npx nx affected -t test
 ```
 
 Note that the unit tests were run for `products`, `angular-store` and `inventory`, but not for `orders` because a change to `products` can not possibly break the tests for `orders`. In a small repo like this, there isn't a lot of time saved, but as there are more tests and more projects, this quickly becomes an essential command.
@@ -923,7 +930,7 @@ Note that the unit tests were run for `products`, `angular-store` and `inventory
 You can also see what projects are affected in the graph visualizer with;
 
 ```shell
-nx graph --affected
+npx nx graph --affected
 ```
 
 {% graph height="450px" %}
@@ -1021,7 +1028,7 @@ nx graph --affected
 
 ## Building the Apps for Deployment
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=856" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=608" /%}
 
 If you're ready and want to ship your applications, you can build them using
 
@@ -1062,15 +1069,15 @@ Replace the `command` with whatever terminal command you use to deploy your site
 
 The `"dependsOn": "build"` setting tells Nx to make sure that the project's `build` task has been run successfully before the `deploy` task.
 
-With the `deploy` tasks defined, you can deploy a single application with `nx deploy angular-store` or deploy any applications affected by the current changes with:
+With the `deploy` tasks defined, you can deploy a single application with `npx nx deploy angular-store` or deploy any applications affected by the current changes with:
 
 ```shell
-nx affected -t deploy
+npx nx affected -t deploy
 ```
 
 ## Imposing Constraints with Module Boundary Rules
 
-<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1456" /%} -->
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=663" /%}
 
 Once you modularize your codebase you want to make sure that the libs are not coupled to each other in an uncontrolled way. Here are some examples of how we might want to guard our small demo workspace:
 
@@ -1193,7 +1200,7 @@ export class ProductsComponent {}
 
 If you lint your workspace you'll get an error now:
 
-```{% command="nx run-many -t lint" %}
+```{% command="npx nx run-many -t lint" %}
 NX   Running target lint for 7 projects
 ✖  nx run products:lint
    Linting "products"...
@@ -1232,7 +1239,13 @@ If you have the ESLint plugin installed in your IDE you should immediately see a
 
 Learn more about how to [enforce module boundaries](/features/enforce-module-boundaries).
 
-## Set Up CI for Your Angular Monorepo
+## Fast CI ⚡ {% highlightColor="green" %}
+
+{% callout type="check" title="Repository with Nx" %}
+Make sure you have completed the previous sections of this tutorial before starting this one. If you want a clean starting point, you can check out the [reference code](https://github.com/nrwl/nx-recipes/tree/main/angular-monorepo) as a starting point.
+{% /callout %}
+
+{% video-link link="https://youtu.be/ZzTP4bVJEnI?t=791" /%}
 
 This tutorial walked you through how Nx can improve the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
 
@@ -1241,53 +1254,79 @@ This tutorial walked you through how Nx can improve the local development experi
 - Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
 - Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
 
-### Generate a CI Workflow
-
-If you are starting a new project, you can use the following command to generate a CI workflow file.
-
-```shell
-npx nx generate ci-workflow --ci=github
-```
-
-{% callout type="note" title="Choose your CI provider" %}
-You can choose `github`, `circleci`, `azure`, `bitbucket-pipelines`, or `gitlab` for the `ci` flag.
-{% /callout %}
-
-This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR.
-
-The key line in the CI pipeline is:
-
-```yml
-- run: npx nx affected -t lint test build e2e-ci
-```
-
-### Connect to Nx Cloud
+### Connect to Nx Cloud {% highlightColor="green" %}
 
 Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.
 
-To connect to Nx Cloud:
+Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.
 
-- Commit and push your changes
-- Go to [https://cloud.nx.app](https://cloud.nx.app), create an account, and connect your repository
+1. Commit your existing changes with `git add . && git commit -am "updates"`
+2. [Create a new GitHub repository](https://github.com/new)
+3. Follow GitHub's instructions to push your existing code to the repository
 
-#### Connect to Nx Cloud Manually
-
-If you are not able to connect via the automated process at [https://cloud.nx.app](https://cloud.nx.app), you can connect your workspace manually by running:
+When we set up the repository at the beginning of this tutorial, we chose to use GitHub Actions as a CI provider. This created a basic CI pipeline and configured Nx Cloud in the repository. It also printed a URL in the terminal to register your repository in your [Nx Cloud](https://cloud.nx.app) account. If you didn't click on the link when first creating your repository, you can show it again by running:
 
 ```shell
 npx nx connect
 ```
 
-You will then need to merge your changes and connect to your workspace on [https://cloud.nx.app](https://cloud.nx.app).
+Once you click the link, follow the steps provided and make sure Nx Cloud is enabled on the main branch of your repository.
 
-### Enable a Distributed CI Pipeline
+### Configure Your CI Workflow {% highlightColor="green" %}
 
-The current CI pipeline runs on a single machine and can only handle small workspaces. To transform your CI into a CI that runs on multiple machines and can handle workspaces of any size, uncomment the `npx nx-cloud start-ci-run` line in the `.github/workflows/ci.yml` file.
+When you chose GitHub Actions as your CI provider at the beginning of the tutorial, `create-nx-workspace` created a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR. Since we are using Nx Cloud, the pipeline will also distribute tasks across multiple machines to ensure fast and reliable CI runs.
 
-```yml
-- run: npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+If you need to generate a new workflow file for GitHub Actions or other providers, you can do so with this command:
+
+```shell
+npx nx generate ci-workflow
 ```
 
+The key lines in the CI pipeline are:
+
+```yml {% fileName=".github/workflows/ci.yml" highlightLines=["10-14", "21-22"] %}
+name: CI
+# ...
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="build"
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 20
+          cache: 'npm'
+      - run: npm ci --legacy-peer-deps
+      - uses: nrwl/nx-set-shas@v4
+      # Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
+      - run: npx nx affected -t lint test build
+```
+
+### Open a Pull Request {% highlightColor="green" %}
+
+Commit the changes and open a new PR on GitHub.
+
+```shell
+git add .
+git commit -m 'add CI workflow file'
+git push origin add-workflow
+```
+
+When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.
+
+![Nx Cloud report](/shared/tutorials/github-pr-cloud-report.avif)
+
+The `See all runs` link goes to a page with the progress and results of tasks that were run in the CI pipeline.
+
+![Run details](/shared/tutorials/nx-cloud-run-details.avif)
+
 For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:
 
 - [Circle CI with Nx](/ci/intro/tutorials/circle)

docs/shared/tutorials/angular-standalone.md

@@ -2,12 +2,13 @@
 
 In this tutorial you'll learn how to use Angular with Nx in a ["standalone" (non-monorepo) setup](/concepts/integrated-vs-package-based#standalone-applications). Not to be confused with the "Angular Standalone API", a standalone project in Nx is a non-monorepo setup where you have a single application at the root level. This setup is very similar to what the Angular CLI gives you.
 
-What are you going to learn?
+What will you learn?
 
 - how to create a new standalone (single-project) Nx workspace setup for Angular
 - how to run a single task (i.e. serve your app) or run multiple tasks in parallel
 - how to leverage code generators to scaffold components
 - how to modularize your codebase and impose architectural constraints for better maintainability
+- [how to speed up CI with Nx Cloud ⚡](#fast-ci)
 
 {% callout type="info" title="Looking for Angular monorepos?" %}
 Note, this tutorial sets up a repo with a single application at the root level that breaks out its code into libraries to add structure. If you are looking for an Angular monorepo setup then check out our [Angular monorepo tutorial](/getting-started/tutorials/angular-monorepo-tutorial).
@@ -43,13 +44,13 @@ NX   Let's create a new workspace [https://nx.dev/getting-started/intro]
 ✔ Default stylesheet format · css
 ✔ Do you want to enable Server-Side Rendering (SSR) and Static Site Generation (SSG/Prerendering)? · No
 ✔ Test runner to use for end to end (E2E) tests · cypress
-✔ Set up CI with caching, distribution and test deflaking · github
+✔ Which CI provider would you like to use? · github
 ```
 
 You get asked a few questions that help Nx preconfigure your new Angular application. These include:
 
 - Angular specific questions, such as which bundler to use, whether to enable server-side rendering and which stylesheet format to use
-- General Nx questions, such as whether to enable remote caching with Nx Cloud. Nx comes with built-in [local caching](/features/cache-task-results). If you want to benefit from this cache in CI, you can enable [remote caching](/ci/features/remote-cache) which will set up [Nx Cloud](https://nx.app). This is also a prerequisite for enabling [distributed task execution](/ci/features/distribute-task-execution).
+- General Nx questions, such as whether to enable remote caching with Nx Cloud. Nx comes with built-in [local caching](/features/cache-task-results). If you want to benefit from this cache in CI, you can enable [remote caching](/ci/features/remote-cache) which will set up [Nx Cloud](https://nx.app). This is also a prerequisite for enabling [distributed task execution](/ci/features/distribute-task-execution). We'll explore this later in the tutorial.
 
 For the sake of this tutorial, let's respond to all the questions with the default response.
 
@@ -1041,7 +1042,11 @@ When you are ready to add another application to the repo, you'll probably want
 
 You can also go through the full [Angular monorepo tutorial](/getting-started/tutorials/angular-monorepo-tutorial)
 
-## Set Up CI for the Angular App
+## Fast CI ⚡ {% highlightColor="green" %}
+
+{% callout type="check" title="Repository with Nx" %}
+Make sure you have completed the previous sections of this tutorial before starting this one. If you want a clean starting point, you can check out the [reference code](https://github.com/nrwl/nx-recipes/tree/main/angular-standalone) as a starting point.
+{% /callout %}
 
 This tutorial walked you through how Nx can improve the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
 
@@ -1050,53 +1055,79 @@ This tutorial walked you through how Nx can improve the local development experi
 - Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
 - Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
 
-### Generate a CI Workflow
-
-If you are starting a new project, you can use the following command to generate a CI workflow file.
-
-```shell
-npx nx generate ci-workflow --ci=github
-```
-
-{% callout type="note" title="Choose your CI provider" %}
-You can choose `github`, `circleci`, `azure`, `bitbucket-pipelines`, or `gitlab` for the `ci` flag.
-{% /callout %}
-
-This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR.
-
-The key line in the CI pipeline is:
-
-```yml
-- run: npx nx affected -t lint test build e2e-ci
-```
-
-### Connect to Nx Cloud
+### Connect to Nx Cloud {% highlightColor="green" %}
 
 Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.
 
-To connect to Nx Cloud:
+Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.
 
-- Commit and push your changes
-- Go to [https://cloud.nx.app](https://cloud.nx.app), create an account, and connect your repository
+1. Commit your existing changes with `git add . && git commit -am "updates"`
+2. [Create a new GitHub repository](https://github.com/new)
+3. Follow GitHub's instructions to push your existing code to the repository
 
-#### Connect to Nx Cloud Manually
-
-If you are not able to connect via the automated process at [https://cloud.nx.app](https://cloud.nx.app), you can connect your workspace manually by running:
+When we set up the repository at the beginning of this tutorial, we chose to use GitHub Actions as a CI provider. This created a basic CI pipeline and configured Nx Cloud in the repository. It also printed a URL in the terminal to register your repository in your [Nx Cloud](https://cloud.nx.app) account. If you didn't click on the link when first creating your repository, you can show it again by running:
 
 ```shell
 npx nx connect
 ```
 
-You will then need to merge your changes and connect to your workspace on [https://cloud.nx.app](https://cloud.nx.app).
+Once you click the link, follow the steps provided and make sure Nx Cloud is enabled on the main branch of your repository.
 
-### Enable a Distributed CI Pipeline
+### Configure Your CI Workflow {% highlightColor="green" %}
 
-The current CI pipeline runs on a single machine and can only handle small workspaces. To transform your CI into a CI that runs on multiple machines and can handle workspaces of any size, uncomment the `npx nx-cloud start-ci-run` line in the `.github/workflows/ci.yml` file.
+When you chose GitHub Actions as your CI provider at the beginning of the tutorial, `create-nx-workspace` created a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR. Since we are using Nx Cloud, the pipeline will also distribute tasks across multiple machines to ensure fast and reliable CI runs.
 
-```yml
-- run: npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js" --stop-agents-after="e2e-ci"
+If you need to generate a new workflow file for GitHub Actions or other providers, you can do so with this command:
+
+```shell
+npx nx generate ci-workflow
 ```
 
+The key lines in the CI pipeline are:
+
+```yml {% fileName=".github/workflows/ci.yml" highlightLines=["10-14", "21-22"] %}
+name: CI
+# ...
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      # This enables task distribution via Nx Cloud
+      # Run this command as early as possible, before dependencies are installed
+      # Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
+      # Connect your workspace by running "nx connect" and uncomment this
+      - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="build"
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 20
+          cache: 'npm'
+      - run: npm ci --legacy-peer-deps
+      - uses: nrwl/nx-set-shas@v4
+      # Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
+      - run: npx nx affected -t lint test build
+```
+
+### Open a Pull Request {% highlightColor="green" %}
+
+Commit the changes and open a new PR on GitHub.
+
+```shell
+git add .
+git commit -m 'add CI workflow file'
+git push origin add-workflow
+```
+
+When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.
+
+![Nx Cloud report](/shared/tutorials/github-pr-cloud-report.avif)
+
+The `See all runs` link goes to a page with the progress and results of tasks that were run in the CI pipeline.
+
+![Run details](/shared/tutorials/nx-cloud-run-details.avif)
+
 For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:
 
 - [Circle CI with Nx](/ci/intro/tutorials/circle)