From bdb5ac4879c311ed9d978bc07e2c5df817e3cfcc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miroslav=20Jona=C5=A1?= Date: Tue, 15 Mar 2022 11:34:11 +0100 Subject: [PATCH] chore(repo): update CI config documentation for GitHub and CircleCI (#9328) --- docs/shared/monorepo-ci-circle-ci.md | 13 +++++++++++-- docs/shared/monorepo-ci-github-actions.md | 7 ++++--- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/docs/shared/monorepo-ci-circle-ci.md b/docs/shared/monorepo-ci-circle-ci.md index 3b8715ba17bbd..ec95fd20b24a5 100644 --- a/docs/shared/monorepo-ci-circle-ci.md +++ b/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. diff --git a/docs/shared/monorepo-ci-github-actions.md b/docs/shared/monorepo-ci-github-actions.md index d8af006898fda..5f36fed23886e 100644 --- a/docs/shared/monorepo-ci-github-actions.md +++ b/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.