chore(repo): update CI config documentation for GitHub and CircleCI (#…

…9328)

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

@@ -14,12 +14,15 @@ But they come with their own technical challenges. The more code you add into yo
 
 ## Setting up CircleCI
 
-Below is an example of a Circle CI setup for an Nx workspace only building and testing what is affected.
+The `CircleCI` can track the last successful run on `main` branch and use this as a reference point for the `BASE`. The `Nx Orb` provides conventient implementation of this functionality which you can drop into you existing CI config.
+To understand why knowing the last successful build is important for the affected command, check out the [in-depth explanation at Orb's docs](https://github.com/nrwl/nx-orb#background).
+
+Below is an example of a Circle CI setup for an Nx workspace only building and testing what is affected. For more details on how the orb is used, head over to the [official docs](https://circleci.com/developer/orbs/orb/nrwl/nx).
 
 ```yaml
 version: 2.1
 orbs:
-  nx: nrwl/nx@1.0.0
+  nx: nrwl/nx@1.1.3
 jobs:
   main:
     steps:
@@ -50,6 +53,12 @@ workflows:
 
 The `pr` and `main` jobs implement the CI workflow.
 
+### Using CircleCI on private repository
+
+To use the [Nx Orb](https://github.com/nrwl/nx-orb) with a private repository on your main branch, you need to grant the orb access to your CircleCI API. You can do this by creating an environment variable called `CIRCLE_API_TOKEN` in the context or the project.
+
+> Note: It should be a user token, not project token.
+
 ## Distributed CI with Nx Cloud
 
 A computation cache is created on your local machine to make the developer experience faster. This allows you to not waste time re-building, re-testing, re-linting, or any number of other actions you might take on code that hasn't changed. Because the cache is stored locally, you are the only member of your team that can take advantage of these instant commands. You can manage and share this cache manually.

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

@@ -14,7 +14,10 @@ But they come with their own technical challenges. The more code you add into yo
 
 ## Setting GitHub Actions
 
-Below is an example of a GitHub Actions setup for an Nx workspace only building and testing what is affected.
+The `GitHub` can track the last successful run on `main` branch and use this as a reference point for the `BASE`. The `Nx Set SHAs` provides conventient implementation of this functionality which you can drop into you existing CI config.
+To understand why knowing the last successful build is important for the affected command, check out the [in-depth explanation at Actions's docs](https://github.com/marketplace/actions/nx-set-shas#background).
+
+Below is an example of a GitHub setup for an Nx workspace only building and testing what is affected. For more details on how the orb is used, head over to the [official docs](https://github.com/marketplace/actions/nx-set-shas).
 
 ```yaml
 name: CI
@@ -61,8 +64,6 @@ jobs:
 
 The `pr` and `main` jobs implement the CI workflow. Setting `timeout-minutes` is needed only if you have very slow tasks.
 
-You can find more information about using GitHub Actions on the [nx-tag-successful-ci-run](https://github.com/nrwl/nx-tag-successful-ci-run) and [nx-set-shas](https://github.com/nrwl/nx-set-shas) repos.
-
 ## Distributed CI with Nx Cloud
 
 A computation cache is created on your local machine to make the developer experience faster. This allows you to not waste time re-building, re-testing, re-linting, or any number of other actions you might take on code that hasn't changed. Because the cache is stored locally, you are the only member of your team that can take advantage of these instant commands. You can manage and share this cache manually.