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
GitHub can track the last successful run on
main branch and use this as a reference point for 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.
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.
1name: CI 2on: 3 push: 4 branches: 5 - main 6 pull_request: 7 8jobs: 9 main: 10 runs-on: ubuntu-latest 11 steps: 12 - uses: actions/checkout@v2 13 with: 14 fetch-depth: 0 15 - uses: nrwl/nx-set-shas@v2 16 - run: npm ci 17 18 - run: npx nx workspace-lint 19 - run: npx nx format:check 20 - run: npx nx affected --target=lint --parallel=3 21 - run: npx nx affected --target=test --parallel=3 --ci --code-coverage 22 - run: npx nx affected --target=build --parallel=3
main jobs implement the CI workflow. Setting
timeout-minutes is needed only if you have very slow tasks.
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. Once all tasks are finished, we must not forget to cleanup used agents.
1name: CI 2on: 3 push: 4 branches: 5 - main 6 pull_request: 7 8jobs: 9 main: 10 name: Nx Cloud - Main Job 11 uses: firstname.lastname@example.org 12 with: 13 parallel-commands: | 14 npx nx-cloud record -- npx nx workspace-lint 15 npx nx-cloud record -- npx nx format:check 16 parallel-commands-on-agents: | 17 npx nx affected --target=lint --parallel=3 18 npx nx affected --target=test --parallel=3 --ci --code-coverage 19 npx nx affected --target=build --parallel=3 20 21 agents: 22 name: Nx Cloud - Agents 23 uses: email@example.com 24 with: 25 number-of-agents: 3
You can also use our ci-workflow generator to generate the workflow file.