miel.truyen/nx
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

docs(core): update ci docs (#10864)

Browse Source
This commit is contained in:
Miroslav Jonaš 2022-06-27 13:28:34 +02:00 committed by GitHub
parent b0205d7a86
commit f31c696523
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
8 changed files with 60 additions and 136 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/nx-cloud/set-up/set-up-dte.md
View File

@ -44,6 +44,7 @@ Every organization manages their CI/CD pipelines differently, so the examples do
Read the guides for more information on how to configure them in CI.
- [Overview](/ci/overview#distributed-ci-with-nx-cloud)
- [Azure Pipelines](/ci/monorepo-ci-azure#distributed-ci-with-nx-cloud)
- [Circle CI](/ci/monorepo-ci-circle-ci#distributed-ci-with-nx-cloud)
- [GitHub Actions](/ci/monorepo-ci-github-actions#distributed-ci-with-nx-cloud)

52
docs/shared/ci-overview.md
View File

@ -1,6 +1,6 @@
# Continous Integration Setup with Monorepos and Nx
# Configuring CI for Nx workspaces
Monorepos provide a lot of advantages:
Nx is a smart, fast and extensible build system, and it works really well with monorepos. Monorepos provide a lot of advantages:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
@ -12,10 +12,48 @@ Monorepos provide a lot of advantages:
But they come with their own technical challenges. The more code you add into your repository and the more code you have to build/test/lint, the slower the CI gets. There are two ways to look at this time spent. In average time, and worst case scenario time. When configured properly, your average CI is the time it takes a given change to go through the CI process. The worst case scenario time is the time it takes to rebuild every project in your monorepo based on a given change. These are baseline you use to measure how long it takes to process pull requests in your CI/CD environment.
Adding Nx to your CI pipeline makes this more efficient.
Nx provides out-of-the-box implementation of CI workflows for `GitHub`, `Azure` and `CircleCI` during the [creation of the Nx workspace](/cli/create-nx-workspace#ci) or later using the [ci-workflow](/packages/workspace/generators/ci-workflow) generator.
<div class="nx-cloud-section">
## 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.
Nx Cloud allows this cache to be shared across your entire organization, meaning that any cacheable operation completed on your workspace only needs to be run once. Nx Cloud also allows you to distribute your CI across multiple machines to make sure the CI is fast even for very large repos.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`.
We enable agents to listen for Nx commands using:
```bash
npx nx-cloud start-agent
```
and notify Nx Cloud of the upcoming Nx commands using:
```bash
npx nx-cloud start-ci-run
```
Once all tasks are finished, we must not forget to cleanup used agents:
```bash
npx nx-cloud stop-all-agents
```
Learn more about configuring your CI environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
</div>
## CI provider specific documentation
The following guides cover optimizing your CI/CD environments with affected commands and distributed caching:
- [Setting up CI using GitHub Actions](/ci/monorepo-ci-github-actions)
- [Setting up CI using CircleCI](/ci/monorepo-ci-circle-ci)
- [Setting up CI using Azure Pipelines](/ci/monorepo-ci-azure)
- [Setting up CI using Jenkins](/ci/monorepo-ci-jenkins)
- [Setting up CI using Bitbucket Pipelines](/ci/monorepo-ci-bitbucket-pipelines)
- [Setting up CI using Azure Pipelines](ci/monorepo-ci-azure)
- [Setting up CI using CircleCI](ci/monorepo-ci-circle-ci)
- [Setting up CI using GitHub Actions](ci/monorepo-ci-github-actions)
- [Setting up CI using Jenkins](ci/monorepo-ci-jenkins)
- [Setting up CI using GitLab](ci/monorepo-ci-gitlab)
- [Setting up CI using Bitbucket](ci/monorepo-ci-bitbucket)

24
docs/shared/monorepo-ci-azure.md
View File

@ -1,19 +1,5 @@
# Configuring CI Using Azure Pipelines and Nx
Nx is a smart, fast and extensible build system, and it works really well with monorepos. Monorepos provide a lot of advantages:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
- Easier dependency management
- One toolchain setup
- Code editors and IDEs are "workspace" aware
- Consistent developer experience
- And more ...
But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets. Adding Nx to your CI pipeline makes this more efficient.
## Setting up Azure Pipelines
Below is an example of an Azure Pipelines setup for an Nx workspace only building and testing what is affected.
Unlike `GitHub Actions` and `CircleCI`, you don't have the metadata to help you track the last successful run on `main`. In the example below, the base is set to `HEAD~1` (for push) or branching point (for pull requests), but a more robust solution would be to tag a SHA in the main job once it succeeds, and then use this tag as a base. See 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) (version 1 implements tagging mechanism) repos for more information.
@ -58,11 +44,9 @@ The `main` job implements the CI workflow.
## 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.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`.
Nx Cloud allows this cache to be shared across your entire organization, meaning that any cacheable operation completed on your workspace only needs to be run once. Nx Cloud also allows you to distribute your CI across multiple machines to make sure the CI is fast even for very large repos.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`. Once all tasks are finished, we must not forget to cleanup used agents.
Read more about the [Distributed CI setup with Nx Cloud](/using-nx/ci-overview#distributed-ci-with-nx-cloud).
```yaml
trigger:
@ -111,8 +95,6 @@ jobs:
condition: always()
```
You can also use our [ci-workflow generator](https://nx.dev/packages/workspace/generators/ci-workflow) to generate the pipeline file.
Learn more about configuring your CI environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
You can also use our [ci-workflow generator](/packages/workspace/generators/ci-workflow) to generate the pipeline file.
</div>

26
docs/shared/monorepo-ci-bitbucket-pipelines.md
View File

@ -1,19 +1,5 @@
# Configuring CI Using Bitbucket Pipelines and Nx
Nx is a smart, fast and extensible build system, and it works really well with monorepos. Monorepos provide a lot of advantages:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
- Easier dependency management
- One toolchain setup
- Code editors and IDEs are "workspace" aware
- Consistent developer experience
- And more ...
But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets.
## Setting Bitbucket Pipelines
Below is an example of a Bitbucket Pipeline setup for an Nx workspace only building and testing what is affected.
```yaml
@ -49,15 +35,3 @@ pipelines:
```
The `pull-requests` and `main` jobs implement the CI workflow.
<div class="nx-cloud-section">
## 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.
Nx Cloud allows this cache to be shared across your entire organization, meaning that any cacheable operation completed on your workspace only needs to be run once. Nx Cloud also allows you to distribute your CI across multiple machines to make sure the CI is fast even for very large repos.
Learn more about configuring your CI environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
</div>

24
docs/shared/monorepo-ci-circle-ci.md
View File

@ -1,19 +1,5 @@
# Configuring CI Using CircleCI and Nx
Nx is a smart, fast and extensible build system, and it works really well with monorepos. Monorepos provide a lot of advantages:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
- Easier dependency management
- One toolchain setup
- Code editors and IDEs are "workspace" aware
- Consistent developer experience
- And more ...
But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets. Adding Nx to your CI pipeline makes this more efficient.
## Setting up CircleCI
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 convenient 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).
@ -55,11 +41,9 @@ To use the [Nx Orb](https://github.com/nrwl/nx-orb) with a private repository on
## 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.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`.
Nx Cloud allows this cache to be shared across your entire organization, meaning that any cacheable operation completed on your workspace only needs to be run once. Nx Cloud also allows you to distribute your CI across multiple machines to make sure the CI is fast even for very large repos.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`. Once all tasks are finished, we must not forget to cleanup used agents.
Read more about the [Distributed CI setup with Nx Cloud](/using-nx/ci-overview#distributed-ci-with-nx-cloud).
```yaml
version: 2.1
@ -107,8 +91,6 @@ workflows:
- main
```
You can also use our [ci-workflow generator](https://nx.dev/packages/workspace/generators/ci-workflow) to generate the configuration file.
Learn more about configuring your CI environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
You can also use our [ci-workflow generator](/packages/workspace/generators/ci-workflow) to generate the configuration file.
</div>

24
docs/shared/monorepo-ci-github-actions.md
View File

@ -1,19 +1,5 @@
# Configuring CI Using GitHub Actions and Nx
Nx is a smart, fast and extensible build system, and it works really well with monorepos. Monorepos provide a lot of advantages:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
- Easier dependency management
- One toolchain setup
- Code editors and IDEs are "workspace" aware
- Consistent developer experience
- And more ...
But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets.
## Setting GitHub Actions
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 convenient 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).
@ -50,11 +36,9 @@ The `pr` and `main` jobs implement the CI workflow. Setting `timeout-minutes` is
## 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.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`.
Nx Cloud allows this cache to be shared across your entire organization, meaning that any cacheable operation completed on your workspace only needs to be run once. Nx Cloud also allows you to distribute your CI across multiple machines to make sure the CI is fast even for very large repos.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`. Once all tasks are finished, we must not forget to cleanup used agents.
Read more about the [Distributed CI setup with Nx Cloud](/using-nx/ci-overview#distributed-ci-with-nx-cloud).
```yaml
name: CI
@ -85,8 +69,6 @@ jobs:
number-of-agents: 3
```
You can also use our [ci-workflow generator](https://nx.dev/packages/workspace/generators/ci-workflow) to generate the workflow file.
Learn more about configuring your CI environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
You can also use our [ci-workflow generator](/packages/workspace/generators/ci-workflow) to generate the workflow file.
</div>

23
docs/shared/monorepo-ci-gitlab.md
View File

@ -1,19 +1,5 @@
# Configuring CI Using GitLab and Nx
Nx is a smart, fast and extensible build system, and it works really well with monorepos. Monorepos provide a lot of advantages:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
- Easier dependency management
- One toolchain setup
- Code editors and IDEs are "workspace" aware
- Consistent developer experience
- And more ...
But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets.
## Setting Gitlab CI/CD
Below is an example of a GitLab pipeline setup for an Nx workspace only building and testing what is affected.
```yaml
@ -73,17 +59,14 @@ build:
- npx nx affected --base=$NX_BASE --head=$NX_HEAD --target=build --parallel=3
```
The `build` and `test` jobs implement the CI workflow using `.distributed` as template to keep
CI configuration file more readable.
The `build` and `test` jobs implement the CI workflow using `.distributed` as template to keep CI configuration file more readable.
<div class="nx-cloud-section">
## 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.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`.
Nx Cloud allows this cache to be shared across your entire organization, meaning that any cacheable operation completed on your workspace only needs to be run once. Nx Cloud also allows you to distribute your CI across multiple machines to make sure the CI is fast even for very large repos.
Learn more about configuring your CI environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
Read more about the [Distributed CI setup with Nx Cloud](/using-nx/ci-overview#distributed-ci-with-nx-cloud).
</div>

22
docs/shared/monorepo-ci-jenkins.md
View File

@ -1,19 +1,5 @@
# Configuring CI Using Jenkins and Nx
Nx is a smart, fast and extensible build system, and it works really well with monorepos. Monorepos provide a lot of advantages:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
- Easier dependency management
- One toolchain setup
- Code editors and IDEs are "workspace" aware
- Consistent developer experience
- And more ...
But they come with their own technical challenges. The more code you add into your repository, the slower the CI gets. Adding Nx to your CI pipeline makes this more efficient.
## Setting up Jenkins
Below is an example of a Jenkins setup for an Nx workspace only building and testing what is affected.
Unlike `GitHub Actions` and `CircleCI`, you don't have the metadata to help you track the last successful run on `main`. In the example below, the base is set to `HEAD~1` (for push) or branching point (for pull requests), but a more robust solution would be to tag a SHA in the main job once it succeeds, and then use this tag as a base. See 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) (version 1 implements tagging mechanism) repos for more information.
@ -69,11 +55,9 @@ The `pr` and `main` jobs implement the CI workflow.
## 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.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`.
Nx Cloud allows this cache to be shared across your entire organization, meaning that any cacheable operation completed on your workspace only needs to be run once. Nx Cloud also allows you to distribute your CI across multiple machines to make sure the CI is fast even for very large repos.
In order to use distributed task execution, we need to start agents and set the `NX_CLOUD_DISTRIBUTED_EXECUTION` flag to `true`. Once all tasks are finished, we must not forget to cleanup used agents.
Read more about the [Distributed CI setup with Nx Cloud](/using-nx/ci-overview#distributed-ci-with-nx-cloud).
```groovy
pipeline {
@ -123,6 +107,4 @@ pipeline {
}
```
Learn more about configuring your CI environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
</div>