Compare commits
108 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 5e9180b628 | |||
| 56610f9657 | |||
| 312058d67a | |||
| aac166de33 | |||
| 7b0f4dcdab | |||
| f022f3a7c6 | |||
| 9c74e82745 | |||
| f5d3fc0e66 | |||
| de00e97308 | |||
| 54db861b72 | |||
| 30016157b2 | |||
| 7386e7bd31 | |||
| 600d4f77e3 | |||
| 7b87b407f6 | |||
| cda214eda8 | |||
| fdb2c2fd90 | |||
| c280c1acda | |||
| 110bb66da1 | |||
| b8ece6b08d | |||
| b7d7e86186 | |||
| 16736c3562 | |||
| f26339568b | |||
| ee9fe1c501 | |||
| 6b68812ddc | |||
| bfb74b44f8 | |||
| 7d327ee856 | |||
| 4b29c2434a | |||
| e779d699cd | |||
| 3742b41758 | |||
| 8570e75d69 | |||
| e84fd31ef1 | |||
| 35474f8281 | |||
| 144f120d6e | |||
| 7bf1c0dfb2 | |||
| f703ac2722 | |||
| 6e79205a20 | |||
| 6c0a6ac65b | |||
| c9eba1aad8 | |||
| ea588ac7fd | |||
| 5e93935269 | |||
| 9ecf381309 | |||
| 0cfb128c0e | |||
| 2f03980c9b | |||
| cd6afb9ec6 | |||
| e1a279ddfd | |||
| 5539dfc857 | |||
| 474584e69c | |||
| 5a3808b9d4 | |||
| 6d976b679d | |||
| 58f357f060 | |||
| d60b15cd6b | |||
| 2eea3e3433 | |||
| 4050e97147 | |||
| bb52dad17a | |||
| 122983db5e | |||
| 0810952818 | |||
| d5f98f8431 | |||
| d5bfc3afd0 | |||
| 4c9541a925 | |||
| 69a1e7c91a | |||
| 5b1216c774 | |||
| 44c1feb604 | |||
| dd1e9e1444 | |||
| 1d61d4986f | |||
| 1b3d616a75 | |||
| 371e968bf4 | |||
| 617e485c3a | |||
| ffb3514c51 | |||
| e8c9e19c9e | |||
| 81fa01f254 | |||
| efc95f716c | |||
| 6e5f2f055c | |||
| cb49e139ff | |||
| 8f945ba969 | |||
| 4451833d91 | |||
| e21dc6e117 | |||
| 2638481794 | |||
| cc5341f801 | |||
| 9f9d829447 | |||
| a72adf06d5 | |||
| 74e77e18f2 | |||
| dccdb43ac7 | |||
| da3c468f98 | |||
| 9626975f6f | |||
| 20a9819bbb | |||
| 66db0aa371 | |||
| cb02022cab | |||
| 865abbc4b0 | |||
| c747d3f172 | |||
| e0eabdd3cc | |||
| 4e82d0b055 | |||
| c745c47434 | |||
| f4309621ac | |||
| d1b4bc93c4 | |||
| b289708066 | |||
| 183f5ec3cf | |||
| c2e717c70e | |||
| ee783b9670 | |||
| 9396d26768 | |||
| dcec1c81f9 | |||
| a2eff633d3 | |||
| 23057601f6 | |||
| da2acf0be8 | |||
| 72e3ba7e3c | |||
| 550c7e37da | |||
| f6baa75d4e | |||
| 89ea1f6089 | |||
| 56a75ba6a3 |
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"nx-mcp": {
|
||||
"url": "http://localhost:9470/sse"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -136,7 +136,7 @@ jobs:
|
||||
permissions:
|
||||
contents: read
|
||||
runs-on: ${{ matrix.os }}
|
||||
timeout-minutes: 150 # <- cap each job to 150 minutes
|
||||
timeout-minutes: 200 # <- cap each job to 200 minutes
|
||||
strategy:
|
||||
matrix: ${{fromJson(needs.prepare-matrix.outputs.matrix)}} # Load matrix from previous job
|
||||
fail-fast: false
|
||||
|
||||
@@ -37,34 +37,34 @@ const matrixData: MatrixData = {
|
||||
{ name: 'e2e-lerna-smoke-tests', codeowners: 'S04TNCVEETS', is_golden: true },
|
||||
{ name: 'e2e-js', codeowners: 'S04SJ6HHP0X', is_golden: true },
|
||||
{ name: 'e2e-nx-init', codeowners: 'S04SYHYKGNP', is_golden: true },
|
||||
{ name: 'e2e-nx', codeowners: 'S04SYHYKGNP', is_golden: true },
|
||||
{ name: 'e2e-release', codeowners: 'S04SYHYKGNP', is_golden: true },
|
||||
{ name: 'e2e-workspace-create', codeowners: 'S04SYHYKGNP', is_golden: true },
|
||||
{ name: 'e2e-nx', codeowners: 'S04SYHYKGNP' },
|
||||
{ name: 'e2e-release', codeowners: 'S04SYHYKGNP'},
|
||||
{ name: 'e2e-workspace-create', codeowners: 'S04SYHYKGNP' },
|
||||
],
|
||||
projects: [
|
||||
{ name: 'e2e-cypress', codeowners: 'S04T16BTJJY', is_golden: true },
|
||||
{ name: 'e2e-detox', codeowners: 'S04TNCNJG5N' , is_golden: true},
|
||||
{ name: 'e2e-esbuild', codeowners: 'S04SJ6HHP0X' , is_golden: true},
|
||||
{ name: 'e2e-gradle', codeowners: 'S04TNCNJG5N' , is_golden: true},
|
||||
{ name: 'e2e-eslint', codeowners: 'S04SYJGKSCT', is_golden: true },
|
||||
{ name: 'e2e-node', codeowners: 'S04SJ6HHP0X', is_golden: true },
|
||||
{ name: 'e2e-playwright', codeowners: 'S04SVQ8H0G5', is_golden: true },
|
||||
{ name: 'e2e-remix', codeowners: 'S04SVQ8H0G5' , is_golden: true},
|
||||
{ name: 'e2e-rspack', codeowners: 'S04SJ6HHP0X', is_golden: true },
|
||||
{ name: 'e2e-vite', codeowners: 'S04SJ6PL98X' , is_golden: true},
|
||||
{ name: 'e2e-vue', codeowners: 'S04SJ6PL98X' , is_golden: true},
|
||||
{ name: 'e2e-web', codeowners: 'S04SJ6PL98X', is_golden: true },
|
||||
{ name: 'e2e-webpack', codeowners: 'S04SJ6PL98X', is_golden: true },
|
||||
{ name: 'e2e-jest', codeowners: 'S04T16BTJJY', is_golden: true },
|
||||
{ name: 'e2e-angular', codeowners: 'S04SS457V38' },
|
||||
{ name: 'e2e-cypress', codeowners: 'S04T16BTJJY' },
|
||||
{ name: 'e2e-detox', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-esbuild', codeowners: 'S04SJ6HHP0X' },
|
||||
{ name: 'e2e-expo', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-gradle', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-jest', codeowners: 'S04T16BTJJY' },
|
||||
{ name: 'e2e-eslint', codeowners: 'S04SYJGKSCT' },
|
||||
{ name: 'e2e-next', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-node', codeowners: 'S04SJ6HHP0X' },
|
||||
{ name: 'e2e-plugin', codeowners: 'S04SYHYKGNP' },
|
||||
{ name: 'e2e-react', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-react-native', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-web', codeowners: 'S04SJ6PL98X' },
|
||||
{ name: 'e2e-rollup', codeowners: 'S04SJ6PL98X' },
|
||||
{ name: 'e2e-storybook', codeowners: 'S04SVQ8H0G5' },
|
||||
{ name: 'e2e-playwright', codeowners: 'S04SVQ8H0G5' },
|
||||
{ name: 'e2e-remix', codeowners: 'S04SVQ8H0G5' },
|
||||
{ name: 'e2e-rspack', codeowners: 'S04SJ6HHP0X' },
|
||||
{ name: 'e2e-vite', codeowners: 'S04SJ6PL98X' },
|
||||
{ name: 'e2e-vue', codeowners: 'S04SJ6PL98X' },
|
||||
{ name: 'e2e-nuxt', codeowners: 'S04SJ6PL98X' },
|
||||
{ name: 'e2e-webpack', codeowners: 'S04SJ6PL98X' }
|
||||
{ name: 'e2e-nuxt', codeowners: 'S04SJ6PL98X' }
|
||||
],
|
||||
nodeTLS: 20,
|
||||
setup: [
|
||||
|
||||
@@ -30,51 +30,68 @@ function humanizeDuration(num: number): string {
|
||||
}
|
||||
|
||||
function processResults(combined: MatrixResult[]): ProcessedResults {
|
||||
const failedProjects = combined.filter(c => c.status === 'failure').sort((a, b) => a.project.localeCompare(b.project));
|
||||
const failedProjects = combined.filter(c => c.status === 'failure' || c.status === 'cancelled').sort((a, b) => a.project.localeCompare(b.project));
|
||||
const failedGoldenProjects = failedProjects.filter(c => c.is_golden);
|
||||
const hasGoldenFailures = failedGoldenProjects.length > 0;
|
||||
const codeowners = new Set<string>();
|
||||
failedGoldenProjects.forEach(c => codeowners.add(c.codeowners));
|
||||
|
||||
let result = '';
|
||||
let lastProject: string | undefined;
|
||||
|
||||
const allGoldenProjects = combined.filter(c => c.is_golden);
|
||||
const uniqueGoldenProjects = new Set(allGoldenProjects.map(c => c.project));
|
||||
const uniqueFailedGoldenProjects = new Set(failedGoldenProjects.map(c => c.project));
|
||||
const goldenPassingCount = uniqueGoldenProjects.size - uniqueFailedGoldenProjects.size;
|
||||
const goldenFailingCount = uniqueFailedGoldenProjects.size;
|
||||
|
||||
const allOtherProjects = combined.filter(c => !c.is_golden);
|
||||
const uniqueOtherProjects = new Set(allOtherProjects.map(c => c.project));
|
||||
const failedRegularProjects = failedProjects.filter(c => !c.is_golden);
|
||||
const uniqueFailedOtherProjects = new Set(failedRegularProjects.map(c => c.project));
|
||||
const otherPassingCount = uniqueOtherProjects.size - uniqueFailedOtherProjects.size;
|
||||
const otherFailingCount = uniqueFailedOtherProjects.size;
|
||||
|
||||
result += `\n🌟 *Golden Projects*`;
|
||||
result += `\n✅ Passing: ${goldenPassingCount}`;
|
||||
result += `\n❌ Failing: ${goldenFailingCount}`;
|
||||
|
||||
if (failedGoldenProjects.length > 0) {
|
||||
result += `
|
||||
🔥 **Golden Test Failures (${failedGoldenProjects.length})**
|
||||
\`\`\`
|
||||
| Failed project | PM | OS | Node |
|
||||
|--------------------------------|------|-------|----------|`;
|
||||
lastProject = undefined;
|
||||
result += `\n\n🚨 *Failed Golden Projects*\n\`\`\``;
|
||||
result += `\n| Failed project |`;
|
||||
result += `\n|--------------------------------|`;
|
||||
let lastProject: string | undefined;
|
||||
failedGoldenProjects.forEach(matrix => {
|
||||
const project = matrix.project !== lastProject ? matrix.project : '...';
|
||||
result += `\n| ${project.padEnd(30)} | ${matrix.package_manager.padEnd(4)} | ${matrix.os_name.padEnd(5)} | v${matrix.node_version.toString().padEnd(7)} |`;
|
||||
lastProject = matrix.project;
|
||||
const project = matrix.project !== lastProject ? matrix.project : '';
|
||||
if (project) {
|
||||
result += `\n| ${project.padEnd(30)} |`;
|
||||
lastProject = matrix.project;
|
||||
}
|
||||
});
|
||||
result += `\`\`\``;
|
||||
} else {
|
||||
result += '\n✅ **Golden Tests: All Passed!**';
|
||||
result += `\n\`\`\``;
|
||||
}
|
||||
|
||||
const failedRegularProjects = failedProjects.filter(c => !c.is_golden);
|
||||
result += `\n\n🔧 *Other Projects*`;
|
||||
result += `\n✅ Passing: ${otherPassingCount}`;
|
||||
result += `\n❌ Failing: ${otherFailingCount}`;
|
||||
|
||||
// Failed Other Projects Table (if any)
|
||||
if (failedRegularProjects.length > 0) {
|
||||
if (failedGoldenProjects.length > 0 || result.length > 0) result += '\n\n';
|
||||
result += `
|
||||
📋 **Other Project Failures (${failedRegularProjects.length})**
|
||||
\`\`\`
|
||||
| Failed project | PM | OS | Node |
|
||||
|--------------------------------|------|-------|----------|`;
|
||||
lastProject = undefined;
|
||||
result += `\n\n⚠️ *Failed Other Projects*\n\`\`\``;
|
||||
result += `\n| Failed project |`;
|
||||
result += `\n|--------------------------------|`;
|
||||
let lastProject: string | undefined;
|
||||
failedRegularProjects.forEach(matrix => {
|
||||
const project = matrix.project !== lastProject ? matrix.project : '...';
|
||||
result += `\n| ${project.padEnd(30)} | ${matrix.package_manager.padEnd(4)} | ${matrix.os_name.padEnd(5)} | v${matrix.node_version.toString().padEnd(7)} |`;
|
||||
lastProject = matrix.project;
|
||||
const project = matrix.project !== lastProject ? matrix.project : '';
|
||||
if (project) {
|
||||
result += `\n| ${project.padEnd(30)} |`;
|
||||
lastProject = matrix.project;
|
||||
}
|
||||
});
|
||||
result += `\`\`\``;
|
||||
result += `\n\`\`\``;
|
||||
}
|
||||
|
||||
if (failedProjects.length === 0) {
|
||||
result = '✅ **No test failures detected!**';
|
||||
result = '🎉 *No test failures detected!* All systems green! 🟢';
|
||||
}
|
||||
|
||||
const timeReport: Record<string, { min: number; max: number; minEnv: string; maxEnv: string }> = {};
|
||||
|
||||
@@ -75,6 +75,7 @@ storybook-static
|
||||
.claude/settings.local.json
|
||||
|
||||
.cursor/rules/nx-rules.mdc
|
||||
.cursor/mcp.json
|
||||
.github/instructions/nx.instructions.md
|
||||
|
||||
# Added by Claude Task Master
|
||||
@@ -101,4 +102,8 @@ node_modules/
|
||||
# OS specific
|
||||
# Task files
|
||||
tasks.json
|
||||
tasks/
|
||||
tasks/
|
||||
|
||||
# Upstream docs local configuration (machine-specific)
|
||||
.upstreamdocs.local.json
|
||||
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"include": ["apps/**/*", "libs/**/*", "packages/**/*"],
|
||||
"exclude": [
|
||||
"**/*.spec.*",
|
||||
"**/test/**/*",
|
||||
"**/__tests__/**/*",
|
||||
"**/*.test.*",
|
||||
"node_modules/**/*"
|
||||
]
|
||||
}
|
||||
@@ -177,6 +177,8 @@ Fixes #ISSUE_NUMBER
|
||||
### Guidelines
|
||||
|
||||
- Ensure your commit message follows the conventional commit format (use `pnpm commit`)
|
||||
- Use `fix:`, `feat:`, `chore:`, etc. as appropriate types.
|
||||
- Scope is **required** for all commits. Possible scopes are listed in `scripts/commitizen.js`.
|
||||
- Read the submission guidelines in CONTRIBUTING.md before posting
|
||||
- For complex changes, you can request a dedicated Nx release by mentioning the Nx team
|
||||
- Always link the related issue using "Fixes #ISSUE_NUMBER" to automatically close it when merged
|
||||
|
||||
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/RNilYmJJzdk
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/V2W94Sq_v6A
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/dRQq_B1HSLA
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -16,6 +16,9 @@ description: 'Explore how Nx monorepos amplify AI benefits by providing complete
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/fPqPh4h8RJg
|
||||
- **Save Time: Connecting Your Editor, CI and LLMs**
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -6,7 +6,6 @@ tags: ['nx', 'release']
|
||||
cover_image: /blog/images/2025-05-05/header.avif
|
||||
description: 'Discover the latest in Nx 21, featuring continuous tasks and the new Terminal UI'
|
||||
youtubeUrl: https://youtu.be/9zsncTxfcl4
|
||||
pinned: true
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Nx 21 Launch Week" expanded=true %}
|
||||
|
||||
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/PXNjedYhZDs
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- **Enhancing Nx Generators with AI: Predictability Meets Intelligence**
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ authors: ['Victor Savkin']
|
||||
tags: ['ai', 'development', 'productivity', 'best-practices']
|
||||
cover_image: /blog/images/articles/bg-practical-ai-guide-part-1.avif
|
||||
description: 'Learn how to effectively use AI coding assistants beyond simple prompts. Discover proven workflows, best practices, and strategies that transform AI from a novelty into a powerful development multiplier.'
|
||||
pinned: true
|
||||
pinned: false
|
||||
---
|
||||
|
||||
> _"Tools amplify your talent. The better your skills, the better the tools serve you."_ — Andrew Hunt, The Pragmatic Programmer
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: ['nx', 'nx-console', 'ai', 'terminal']
|
||||
cover_image: /blog/images/articles/bg-nx-tui-llm-integration.avif
|
||||
description: 'Learn how Nx Console now enables AI assistants to read your terminal output in real-time, automatically detecting and fixing development errors as they happen.'
|
||||
youtubeUrl: https://youtu.be/Cbc9_W5J6DA
|
||||
pinned: true
|
||||
pinned: false
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Series: Making your LLM smarter" expanded=true %}
|
||||
@@ -18,6 +18,9 @@ pinned: true
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- **Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing**
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -4,7 +4,6 @@ slug: cve-2025-36852-critical-cache-poisoning-vulnerability-creep
|
||||
authors: ['Victor Savkin']
|
||||
tags: ['caching', 'security']
|
||||
cover_image: /blog/images/2025-06-12/header.avif
|
||||
pinned: true
|
||||
description: 'A critical security vulnerability called CREEP (Cache Race-condition Exploit Enables Poisoning) has been published as CVE-2025-36852. This vulnerability affects remote cache plugins across numerous build systems, including Nx.'
|
||||
---
|
||||
|
||||
@@ -18,6 +17,12 @@ The CREEP vulnerability allows any contributor with pull request privileges to i
|
||||
- Nx Cloud is **NOT** affected due to its security architecture
|
||||
- Review this post to determine if your self-hosted cache solution is vulnerable
|
||||
|
||||
{% callout type="warning" title="DIY implementations are vulnerable" %}
|
||||
DIY remote caches are likely vulnerable. Scanners won't catch all affected implementations, so understanding the vulnerability is crucial.
|
||||
{% /callout %}
|
||||
|
||||
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4kkSHiy" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
|
||||
|
||||
## **Understanding the Vulnerability**
|
||||
|
||||
A typical remote-cache flow using storage services follows these steps:
|
||||
@@ -93,5 +98,8 @@ CVE-2025-36852 represents a serious threat to organizations using vulnerable cac
|
||||
|
||||
- If your organization uses bucket-based remote caching: immediate action is required
|
||||
- If your organization uses other self-hosted remote cache solutions: immediate review required (most self-hosted caching solutions across many build systems—not just JavaScript, but also Java—are affected)
|
||||
- If your organization uses custom tasks runners to implement remote caching: immediate review required
|
||||
- If using Nx without remote caching: no action is required
|
||||
- If using Nx with Nx Cloud: [Review your settings](/ci/concepts/cache-security#use-scoped-tokens-in-ci). If you are using default settings, no actions should be required.
|
||||
|
||||
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4npF0BA" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
|
||||
|
||||
@@ -9,7 +9,7 @@ authors: ['James Henry']
|
||||
tags: [webinar]
|
||||
cover_image: /blog/images/2025-06-18/June-2025-Webinar-Card.avif
|
||||
time: 10am ET/2pm UTC
|
||||
status: Upcoming
|
||||
status: Past - Gated
|
||||
registrationUrl: https://go.nx.dev/june2025-webinar
|
||||
---
|
||||
|
||||
@@ -21,4 +21,4 @@ Join us for a demo of the new polygraph features in Nx Cloud, launching this mon
|
||||
|
||||
These features are designed to extend some of the powerful benefits of an Nx workspace to multi-workspace environments and take Nx Cloud beyond CI. We'll cover our updated conformance dashboard, how to visualize dependencies across your repos, the new onboarding experience for workspaces that aren’t yet a part of Nx Cloud, and preview how Nx Cloud will be able to fix your code automatically via agentic AI.
|
||||
|
||||
{% call-to-action title="Register today!" url="https://go.nx.dev/june2025-webinar" description="Save your spot" /%}
|
||||
{% call-to-action title="Download the recording" url="https://go.nx.dev/june2025-webinar" description="Sign up to gain access" /%}
|
||||
|
||||
@@ -0,0 +1,238 @@
|
||||
---
|
||||
title: 'Configure Tailwind 4 with Vite in an NPM Workspace: The Complete Guide'
|
||||
slug: setup-tailwind-4-npm-workspace
|
||||
authors: ['Juri Strumpflohner']
|
||||
tags: ['nx', 'tailwind', 'vite', 'npm-workspaces', 'sync-generators']
|
||||
cover_image: /blog/images/articles/bg-tailwind-4-guide.avif
|
||||
description: 'Learn how to set up Tailwind CSS v4 with Vite in an NPM workspace monorepo, and automate your configuration with Nx Sync Generators for optimal performance.'
|
||||
youtubeUrl: https://youtu.be/tg3LnqhNNws
|
||||
---
|
||||
|
||||
Tailwind CSS v4 brings revolutionary changes to how we configure and use the popular utility-first framework. The simplified setup eliminates configuration files and complex PostCSS setups - you just install, import, and start building. But when working in NPM workspaces or monorepos, there's still one crucial challenge: **how do you tell Tailwind which packages to scan for classes?**
|
||||
|
||||
This guide walks you through setting up Tailwind v4 with Vite in an NPM workspace, then shows you how to automate the configuration using Nx Sync Generators to **eliminate manual maintenance**.
|
||||
|
||||
{% github-repository url="https://github.com/juristr/tailwind4-vite-npm-workspaces" /%}
|
||||
|
||||
{% toc /%}
|
||||
|
||||
## Setting up Tailwind v4
|
||||
|
||||
[Tailwind v4](https://tailwindcss.com/blog/tailwindcss-v4) introduced some nice simplifications when it comes to configuring Tailwind:
|
||||
|
||||
- **No more `tailwind.config.js`** - The framework works out of the box
|
||||
- **Minimal dependencies** - Just `tailwindcss` and `@tailwindcss/vite` for Vite projects
|
||||
- **Simple CSS import** - Add `@import "tailwindcss"` to your stylesheet and you're ready
|
||||
|
||||
Since we're using Vite in this workspace, we can leverage the dedicated Tailwind Vite plugin instead of PostCSS configuration. Here's what you need:
|
||||
|
||||
Install the required packages at your workspace root:
|
||||
|
||||
```json {% fileName="package.json" %}
|
||||
{
|
||||
"devDependencies": {
|
||||
"tailwindcss": "^4.0.0",
|
||||
"@tailwindcss/vite": "^4.0.0"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Configure your Vite setup:
|
||||
|
||||
```typescript {% fileName="apps/shop/vite.config.ts" %}
|
||||
import { defineConfig } from 'vite';
|
||||
import react from '@vitejs/plugin-react';
|
||||
import tailwindcss from '@tailwindcss/vite';
|
||||
|
||||
export default defineConfig({
|
||||
plugins: [react(), tailwindcss()],
|
||||
// ... rest of your config
|
||||
});
|
||||
```
|
||||
|
||||
Add the import to your main CSS file:
|
||||
|
||||
```css {% fileName="apps/shop/src/styles.css" %}
|
||||
@import 'tailwindcss';
|
||||
```
|
||||
|
||||
## The NPM workspace challenge
|
||||
|
||||
Consider a typical e-commerce application structured as an NPM workspace:
|
||||
|
||||
```plain
|
||||
apps/
|
||||
shop/
|
||||
src <<<< where tailwind is configured
|
||||
packages/
|
||||
products/
|
||||
feat-product-list/
|
||||
feat-product-detail/
|
||||
data-access-products/
|
||||
shared/
|
||||
ui/
|
||||
utils/
|
||||
```
|
||||
|
||||
At this point, your application will build and serve, but you'll notice that styles from your `packages/` are missing. In this modular setup, your main application (`shop`) depends on various feature packages, but **Tailwind only scans the main app by default**. This means styles defined in your packages won't be included in the final bundle, leading to missing styles and broken layouts.
|
||||
|
||||
## Solving the scanning problem with @source directives
|
||||
|
||||
Tailwind v4 introduces the `@source` directive to address exactly this problem. You can explicitly tell Tailwind which directories to scan by adding these directives to your CSS file:
|
||||
|
||||
```css {% fileName="apps/shop/src/styles.css" %}
|
||||
@import 'tailwindcss';
|
||||
|
||||
@source "../../../packages/products/feat-product-list";
|
||||
@source "../../../packages/products/feat-product-detail";
|
||||
@source "../../../packages/shared/ui";
|
||||
...
|
||||
```
|
||||
|
||||
With these directives in place, Tailwind will scan the specified packages and include any utility classes found there. Your application styles will now work correctly across all packages.
|
||||
|
||||
## Automating @source entries - enter Nx sync generators
|
||||
|
||||
While `@source` directives solve the technical problem, they introduce a maintenance challenge:
|
||||
|
||||
- **manual updates required** when adding or removing dependencies,
|
||||
- **easy to forget updating** the directives,
|
||||
- **hard-to-debug issues** since missing styles don't break builds (just cause visual problems), and
|
||||
- **team coordination** since every developer needs to remember to update these paths.
|
||||
|
||||
This is where automation becomes crucial and where Nx can help. [Nx Sync Generators](/concepts/sync-generators) provide a powerful solution for **automating configuration that needs to stay in sync with your project structure**.
|
||||
|
||||
For our specific use case we can automate the generation of the `@source` directives by
|
||||
|
||||
- analyzing and traversing all of the `shop` application's dependencies (leveraging the [Nx project graph](/features/explore-graph))
|
||||
- generating the `@source` entries into the correct `styles.css` file
|
||||
|
||||
You can follow [the guide on the Nx docs](/extending-nx/recipes/create-sync-generator) for all the details on how to implement your own Nx sync generator. At a high level these are the steps you'll need:
|
||||
|
||||
**Step 1: Add Nx Plugin development support**
|
||||
|
||||
```shell
|
||||
npx nx add @nx/plugin
|
||||
```
|
||||
|
||||
**Step 2: Generate a new plugin into your workspace**
|
||||
|
||||
```shell
|
||||
npx nx g @nx/plugin:plugin tools/tailwind-sync-plugin
|
||||
```
|
||||
|
||||
Note, you can choose whatever folder you like. I happen to use the `tools/` folder for this example.
|
||||
|
||||
**Step 3: Generate a sync generator**
|
||||
|
||||
```shell
|
||||
npx nx g @nx/plugin:generator --name=update-tailwind-globs --path=tools/tailwind-sync-plugin/src/generators/update-tailwind-globs
|
||||
```
|
||||
|
||||
With that you have the infrastructure in place and we can look at the actual implementation of the sync generator:
|
||||
|
||||
```typescript
|
||||
import { Tree, createProjectGraphAsync, joinPathFragments } from '@nx/devkit';
|
||||
import { SyncGeneratorResult } from 'nx/src/utils/sync-generators';
|
||||
|
||||
export async function updateTailwindGlobsGenerator(
|
||||
tree: Tree
|
||||
): Promise<SyncGeneratorResult> {
|
||||
const appName = '@aishop/shop';
|
||||
const projectGraph = await createProjectGraphAsync();
|
||||
|
||||
// Traverse all dependencies of the shop app
|
||||
const dependencies = new Set<string>();
|
||||
const queue = [appName];
|
||||
const visited = new Set<string>();
|
||||
|
||||
while (queue.length > 0) {
|
||||
const current = queue.shift()!;
|
||||
if (visited.has(current)) continue;
|
||||
visited.add(current);
|
||||
|
||||
const deps = projectGraph.dependencies[current] || [];
|
||||
deps.forEach((dep) => {
|
||||
dependencies.add(dep.target);
|
||||
queue.push(dep.target);
|
||||
});
|
||||
}
|
||||
|
||||
// Generate @source directives for each dependency
|
||||
const sourceDirectives: string[] = [];
|
||||
dependencies.forEach((dep) => {
|
||||
const project = projectGraph.nodes[dep];
|
||||
if (project && project.data.root) {
|
||||
const relativePath = joinPathFragments('../../../', project.data.root);
|
||||
sourceDirectives.push(`@source "${relativePath}";`);
|
||||
}
|
||||
});
|
||||
|
||||
// Update the styles.css file
|
||||
const stylesPath = 'apps/shop/src/styles.css';
|
||||
const currentContent = tree.read(stylesPath)?.toString() || '';
|
||||
|
||||
// Insert the @source directives after @import "tailwindcss"
|
||||
// ... (implementation details)
|
||||
|
||||
return {
|
||||
outOfSyncMessage: 'Tailwind @source directives updated',
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
_(Check out the [Github repo for the full implementation](https://github.com/juristr/tailwind4-vite-npm-workspaces))_
|
||||
|
||||
You can manually run sync generators with `nx sync`, but we want this to run automatically whenever we build or serve our application. As such we can register the sync generator in the app's `package.json`:
|
||||
|
||||
```json {% fileName="apps/shop/package.json" %}
|
||||
{
|
||||
"name": "@aishop/shop",
|
||||
...
|
||||
"nx": {
|
||||
"targets": {
|
||||
"build": {
|
||||
"syncGenerators": ["@aishop/tailwind-sync-plugin:update-tailwind-globs"]
|
||||
},
|
||||
"serve": {
|
||||
"syncGenerators": ["@aishop/tailwind-sync-plugin:update-tailwind-globs"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Nx sync generators in action
|
||||
|
||||
When you run your development server with `nx serve shop`, the sync generator automatically checks if your `@source` directives are up to date:
|
||||
|
||||

|
||||
|
||||
Your CSS file is automatically updated with the correct directives based on your actual project dependencies. If you add or remove dependencies later, the next build or serve will **detect the changes and update the configuration automatically**.
|
||||
|
||||
You can find the complete implementation in this [GitHub repository](https://github.com/juristr/tailwind4-vite-npm-workspaces).
|
||||
|
||||
## Using Tailwind v3?
|
||||
|
||||
If you're currently using Tailwind v3, the concept is similar but the implementation differs. Instead of updating `@source` directives, you'd modify the `tailwind.config.js` file with glob patterns.
|
||||
|
||||
Check out the following video which explains the same approach for Tailwind v3:
|
||||
|
||||
{% youtube src="https://www.youtube.com/watch?v=huTmV-F8c0A" title="Optimizing Tailwind with Nx Sync Generators (v3)" /%}
|
||||
|
||||
The [Tailwind v3 demo repository](https://github.com/juristr/tailwind-sync-demo) shows how to implement this approach for older versions.
|
||||
|
||||
## Conclusion
|
||||
|
||||
While Tailwind v4's simplified setup is a significant improvement, manually maintaining `@source` directives creates a maintenance burden in monorepos. Nx Sync Generators solve this by automatically keeping your Tailwind configuration in sync with your project dependencies, eliminating manual updates and preventing hard-to-debug styling issues.
|
||||
|
||||
This approach transforms configuration maintenance into a completely automated process, letting you focus on building features rather than managing paths.
|
||||
|
||||
## Learn more
|
||||
|
||||
- 🧠 [Nx Docs](/getting-started/intro)
|
||||
- 👩💻 [Tailwind v4 Vite NPM Workspace Demo](https://github.com/juristr/tailwind4-vite-npm-workspaces)
|
||||
- 📖 [Nx Sync Generators Documentation](/extending-nx/recipes/create-sync-generator)
|
||||
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
|
||||
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
|
||||
- 🐦 [Follow me on Twitter/X](https://twitter.com/juristr)
|
||||
@@ -0,0 +1,195 @@
|
||||
---
|
||||
title: 'Introducing Self-Healing CI for Nx and Nx Cloud'
|
||||
slug: nx-self-healing-ci
|
||||
authors: ['Juri Strumpflohner']
|
||||
tags: ['nx', 'nx-cloud', 'ai', 'ci']
|
||||
cover_image: /blog/images/articles/thumb-self-healing-ci.avif
|
||||
description: 'Introducing Nx Cloud Self-Healing CI: AI agents that automatically detect, analyze, and fix your CI failures so you do not have to babysit PRs.'
|
||||
youtubeUrl: https://youtu.be/JW5Ki3PkRWA
|
||||
pinned: true
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Series: Making your LLM smarter" %}
|
||||
|
||||
- [Nx Just Made Your LLM Way Smarter](/blog/nx-just-made-your-llm-smarter)
|
||||
- [Making Cursor Smarter with an MCP Server For Nx Monorepos](/blog/nx-made-cursor-smarter)
|
||||
- [Nx MCP Now Available for VS Code Copilot](/blog/nx-mcp-vscode-copilot)
|
||||
- [Nx and AI: Why They Work so Well Together](/blog/nx-and-ai-why-they-work-together)
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- **Introducing Self-Healing CI for Nx and Nx Cloud**
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
At Nx, we've always focused on making CI faster in two ways: **speeding up your actual builds** with techniques like remote caching and distributed execution, and **accelerating your feedback cycles** by eliminating the delays that waste developer time. The end-goal: **optimizing time to green**.
|
||||
|
||||
But what if we could bring this to the next level? **What if your CI could fix itself?** You push a PR with an error, an AI agent automatically identifies the problem, implements the fix, validates it works, and pushes the solution back to your PR?
|
||||
|
||||
**Nx Cloud Self-Healing CI** makes this a reality.
|
||||
|
||||
{% toc /%}
|
||||
|
||||
## Here's what happens now
|
||||
|
||||
Picture this: It's 2 PM on a Tuesday. You've been deep in feature development for the past hour when you get a notification in VS Code:
|
||||
|
||||

|
||||
|
||||
You click the notification, review the one-line import addition, and approve it. Thirty seconds later:
|
||||
|
||||

|
||||
|
||||
> ✅ **Fix applied! Your PR is now passing CI**
|
||||
|
||||
You never left your editor. Never analyzed error logs. Never manually debugged the issue. Just a quick review and approval, then back to your feature work.
|
||||
|
||||
This is Self-Healing CI in action.
|
||||
|
||||
## The problem: "babysitting" your PRs
|
||||
|
||||
Every developer knows this workflow:
|
||||
|
||||
1. **Push your code** and continue working on something else
|
||||
2. **CI fails** with a simple error (missing import, linting issue, test assertion)
|
||||
3. **You don't notice for 30+ minutes** because you're focused on other work
|
||||
4. **Context switch** back to analyze the error and implement a fix
|
||||
5. **Push the fix** and wait another 5-10 minutes for CI to complete
|
||||
6. **Repeat** if there are more issues
|
||||
|
||||
This "babysitting" wastes countless hours across development teams. The critical waste happens in **step 3**: the delay between failure and awareness.
|
||||
|
||||
One big issue is already being handled: **[flaky tasks](/ci/features/flaky-tasks)**. When tests fail intermittently (same code, different results), the system retries them on different agents with zero human intervention.
|
||||
|
||||
**The missing piece:** What about **genuine failures**? Real bugs, configuration errors, and dependency issues that need actual code fixes. These can't be solved with retries—they need intelligent analysis and solutions.
|
||||
|
||||
**Enter Self-Healing CI.** It tackles failures that need real fixes, providing AI-powered analysis, fix generation, and validation. You stay in control with quick review and approval, while the AI handles the heavy lifting. Combined with flaky task detection, you now have a comprehensive system that handles every type of CI failure—so you can stay focused on building features instead of babysitting PRs.
|
||||
|
||||
## How Self-Healing CI works
|
||||
|
||||
Here's what happens when you push a PR with Self-Healing CI enabled:
|
||||
|
||||

|
||||
|
||||
1. **You push your PR** - Nothing changes in your workflow
|
||||
2. **Failure detected** - If tasks fail, instead of just reporting the failure, Nx Cloud starts an AI agent
|
||||
3. **AI agent analyzes** - The agent examines the error logs, understands your codebase structure through Nx's project graph, and identifies the root cause
|
||||
4. **Fix proposed** - The agent creates a fix and presents it to you via Nx Console or the integrated GitHub application (e.g. a comment on your GitHub PR)
|
||||
5. **Validation runs in parallel** - Meanwhile, the agent validates the fix by re-running the originally failed tasks with the proposed changes
|
||||
6. **Human review and approval** - You can approve the fix immediately if it looks good, or wait for validation to complete for extra confidence
|
||||
7. **Automatic PR update** - Once you approve, the fix gets committed to your PR as a new commit by the AI agent
|
||||
8. **Full CI re-run** - Your complete CI pipeline runs again with the applied fix
|
||||
|
||||
**You stay in control while the AI does the heavy lifting.** The AI acts like a peer programmer, handling the time-consuming work of analyzing failures, creating fixes, and validating solutions in the background while you continue working on other tasks. You remain in the loop throughout the process. The AI doesn't make changes autonomously, but rather proposes working fixes for your review and approval before they're applied to your PR.
|
||||
|
||||
The AI agent is successful at providing meaningful fixes because it **combines the context from Nx and Nx Cloud:**
|
||||
|
||||
- it has the complete failure context with the exact tasks that ran, including error logs
|
||||
- thanks to the Nx graph, it has vast context about the codebase, including project structure, dependencies, configuration and runnable tasks
|
||||
- combining the two, it can validate a fix by re-running the original CI checks
|
||||
|
||||
## Getting started with Self-Healing CI
|
||||
|
||||
To enable Self-Healing CI on your workspace:
|
||||
|
||||
### 1. Connect Nx Cloud
|
||||
|
||||
If you haven't already connected to Nx Cloud:
|
||||
|
||||
```shell
|
||||
npx nx connect
|
||||
```
|
||||
|
||||
You can [start with the free Hobby plan](/pricing) and play around with the new AI features.
|
||||
|
||||
Once connected, enable AI features in your [Nx Cloud dashboard](https://nx.app):
|
||||
|
||||
1. **Organization Settings**: Enable AI features (required for all AI-powered functionality)
|
||||
2. **Workspace Settings**: Find the "Self-Healing CI" section and toggle it on (available for all Nx Cloud plans)
|
||||
|
||||

|
||||
|
||||
### 2. Configure Your CI Pipeline
|
||||
|
||||
If you're using Nx Agents, Self-Healing CI is automatically enabled. Here's an example GitHub Actions configuration with Nx Agents:
|
||||
|
||||
```yaml
|
||||
name: CI
|
||||
|
||||
...
|
||||
|
||||
jobs:
|
||||
main:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
...
|
||||
|
||||
- run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="build"
|
||||
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 20
|
||||
cache: 'npm'
|
||||
|
||||
- run: npm ci
|
||||
- uses: nrwl/nx-set-shas@v4
|
||||
- run: npx nx affected -t lint test build
|
||||
```
|
||||
|
||||
If you're not using Nx Agents yet, you can still enable Self-Healing CI by adding the `fix-ci` step to your pipeline. **Important**: This step must run at the end with `if: always()` to ensure it executes even when previous steps fail (which is exactly when you need the fix):
|
||||
|
||||
```yaml
|
||||
name: CI
|
||||
|
||||
...
|
||||
|
||||
jobs:
|
||||
main:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
...
|
||||
|
||||
- run: npm ci
|
||||
|
||||
- uses: nrwl/nx-set-shas@v4
|
||||
|
||||
- run: npx nx affected -t lint test build
|
||||
|
||||
- run: npx nx-cloud fix-ci
|
||||
if: always()
|
||||
```
|
||||
|
||||
### 3. Install Nx Console
|
||||
|
||||
To receive notifications about self-healing activities directly in your editor and enable the full AI integration experience, you need [Nx Console](/getting-started/editor-setup) installed for VS Code, Cursor, or IntelliJ.
|
||||
|
||||
For the complete AI setup guide, see our [AI integration documentation](/getting-started/ai-integration).
|
||||
|
||||
## Wrapping up
|
||||
|
||||
Self-Healing CI completes Nx Cloud's comprehensive approach to eliminating CI friction. Combined with our existing flaky task detection and automatic retries, we now have a unified system that handles every type of CI failure automatically: flaky tests get retried transparently, genuine bugs get fixed intelligently. No more "babysitting" your PRs. The system handles the tedious work so you can stay focused on building features.
|
||||
|
||||
**Key takeaways:**
|
||||
|
||||
- **Eliminates wasted time**: No more 30-minute delays between CI failure and awareness, no more manual debugging of simple errors
|
||||
- **Leverages Nx's deep context**: AI agents understand your workspace structure, project relationships, and build configurations through Nx's project graph
|
||||
- **You stay in control**: Proposed fixes are presented for your review and approval—the AI doesn't make autonomous changes
|
||||
- **Built on proven infrastructure**: Uses the same robust Nx Cloud infrastructure that powers distributed task execution
|
||||
- **Part of a broader vision**: Continues our mission to optimize "time to green" and eliminate developer workflow friction
|
||||
|
||||
**Ready to try it?** Self-Healing CI is rolling out as an early access feature and is available to everyone right now—no special approval or signup required. If you don't have an Nx Cloud account yet, you can quickly [start with the Hobby plan](/pricing), connect your workspace with `npx nx connect`, and get going immediately.
|
||||
|
||||
**For enterprise teams:** If you're already using Nx Cloud and want to learn more about how AI features like Self-Healing CI can enhance your existing setup, [reach out to us](/contact). We'd love to help you leverage these capabilities in your organization.
|
||||
|
||||
---
|
||||
|
||||
Learn more:
|
||||
|
||||
- 🧠 [Nx AI Docs](/features/enhance-AI)
|
||||
- 🌩️ [Nx Cloud](/nx-cloud)
|
||||
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
|
||||
- 👩💻 [Nx Console GitHub](https://github.com/nrwl/nx-console)
|
||||
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
|
||||
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: 'Nx Cloud Release: Introducing Polygraph'
|
||||
slug: nx-cloud-introducing-polygraph
|
||||
authors: ['Philip Fulcher']
|
||||
tags: ['nx-cloud', 'release']
|
||||
cover_image: /blog/images/2025-06-24/header.avif
|
||||
description: 'Discover Polygraph for Nx Cloud: Gain organization-wide visibility, enforce coding standards, and automate workflows across all your repositories, even those not using Nx. Learn how Polygraph empowers enterprise teams with proactive architecture management and automated consistency.'
|
||||
youtubeUrl: https://youtu.be/BA_nkErlQoE
|
||||
pinned: true
|
||||
---
|
||||
|
||||
The monorepo approach has proven to be a powerful solution for managing applications and libraries within a single repository. It gives you visibility into the dependency graph of your projects, central management of tooling, and consolidated enforcement of organizational standards. But that visibility and management end at the boundaries of that repo. What if it didn't have to? That's why we’re excited to announce **Polygraph** for **Nx Cloud**. Polygraph brings the power of monorepo-level visibility and efficiency to your entire organization.
|
||||
|
||||
{% toc /%}
|
||||
|
||||
## The Reality of Enterprise Development
|
||||
|
||||
Let's be honest about how organizations _actually_ work. You might have a single Nx workspace—a monorepo with your applications and related libraries. It works beautifully, and you're happy with the developer experience and architectural clarity it provides.
|
||||
|
||||
But it's unrealistic to expect an entire organization to collapse into one massive monorepo. You probably have a design system in its own repository because it's used across multiple applications. You have legacy applications that were built before your current architecture standards. There's an authentication client library that lives in its own repo, microservice backends, and different teams working on different applications with their own repositories.
|
||||
|
||||
This is completely normal! Google and Facebook might operate with one repository for everything, but you're not Google or Facebook. Most organizations end up with a vast menagerie of repositories, and the challenge becomes managing all of them. You can easily enforce coding standards, tool configurations, and best practices within a single repository, but ensuring consistency across dozens or even hundreds of repositories becomes a manual, error-prone process.
|
||||
|
||||
## The Problem: Visibility and Consistency Across Repositories
|
||||
|
||||
The unfortunate downsides to scaling an organization are:
|
||||
|
||||
- **You lose architectural visibility** - Within your monorepo, you can see exactly how your application depends on your libraries, how different teams' code connects, and what the impact of changes will be. But once you step outside that repository boundary, you're flying blind.
|
||||
- **Standards become inconsistent** - Coding standards and tool configurations become harder and harder to enforce as your organization grows. You're left to manually check and track compliance which leads to inconsistency.
|
||||
- **Dependencies become invisible** - You know your frontend application depends on your design system because it downloads it from npm, but that relationship is completely opaque until something breaks.
|
||||
|
||||
The result? Teams end up maintaining spreadsheets to track dependencies, writing documentation that's always out of date, and being forced to react to problems as they emerge.
|
||||
|
||||
## Introducing Polygraph
|
||||
|
||||
Polygraph is a suite of tools built to help large organizations see across repos and enforce organizational standards. Currently, Polygraph has three core capabilities, extending the benefits you get from Nx monorepos to your entire organization. **It even works on repos that don’t use Nx.**
|
||||
|
||||
### Workspace Graph
|
||||
|
||||

|
||||
|
||||
[**Workspace graph**](/ci/recipes/enterprise/polygraph#workspace-graph) visualizes dependencies between all workspaces and repos, **even repos that don’t use Nx**. Instead of managing repos in isolation, you can easily see the connections between repos and understand your organizational code structure at a glance.
|
||||
|
||||
This visibility helps you:
|
||||
|
||||
- **Understand impact before making changes** - When proposing a change in one part of the organization, quickly identify what other parts will be affected.
|
||||
- **Plan architectural decisions with full context** - Make informed decisions about refactoring, migrations, and new feature development.
|
||||
- **Improve team coordination** - Teams can see how their work connects to and impacts other teams' projects.
|
||||
|
||||
### Conformance: Enforce Standards Across Your Organization
|
||||
|
||||

|
||||
|
||||
[**Conformance rules**](/ci/recipes/enterprise/polygraph#conformance) allow you to write language-agnostic rules that apply across all workspaces in your organization. This goes beyond what you can achieve with individual repository tooling—now you can enforce consistency at the organizational level.
|
||||
Platform teams can easily publish and enforce coding standards across an entire organization. They can write and publish rules and then quickly apply them across all repos without requiring work from individual teams. **A single platform engineer can drive standards across the entire organization with one tool.**
|
||||
|
||||
For instance, you might create a conformance rule that ensures all repositories use ESLint version 9.0. This rule is published to Nx Cloud and can be configured to automatically run across your entire organization, providing centralized reporting on compliance without requiring any local configuration changes.
|
||||
The power of organizational conformance rules extends to:
|
||||
|
||||
- **Security vulnerability management** - Ensure security issues are addressed consistently across all repositories.
|
||||
- **Dependency management** - Keep third-party dependencies up to date across your entire tech stack.
|
||||
- **Tool standardization** - Maintain consistent tooling configurations without manual coordination.
|
||||
|
||||
### Custom Workflows: Automation Beyond CI
|
||||
|
||||

|
||||
|
||||
[**Custom Workflows**](/ci/recipes/enterprise/polygraph#custom-workflows) enable you to run scheduled tasks, extending automation capabilities beyond traditional CI pipelines. This allows you to run conformance rules and other organizational processes even on repositories that don't use Nx locally. You can run conformance rules to enforce standards, but you can also run data collection tools to make sure you’re always up to date with the latest information from repos across your organization. These workflows are separate from CI and language ecosystems, so you can run tasks across any repo in your organization, no matter what language or tool it uses.
|
||||
|
||||
This means you can:
|
||||
|
||||
- **Apply standards to any repository** - Even legacy codebases, that can't be easily migrated to Nx, can benefit from organizational conformance rules.
|
||||
- **Schedule organizational maintenance** - Run dependency audits, security scans, or compliance checks on a regular schedule across all repositories.
|
||||
|
||||
Custom Workflows are built on top of [**Nx Agents**](/ci/features/distribute-task-execution), and enable you to run any task in an on-demand infrastructure. This is just the beginning of what we have planned for this capability. It lays the foundation for **AI-powered refactoring** and **self-healing CI**.
|
||||
|
||||
## How Polygraph Changes Enterprise Development
|
||||
|
||||
### From Reactive to Proactive Architecture Management
|
||||
|
||||
Instead of discovering architectural problems when they cause production issues, enable proactive architecture management. You can see the full picture of your system's dependencies and make informed decisions about changes before they impact your users.
|
||||
|
||||
### From Manual Governance to Automated Consistency
|
||||
|
||||
Automate consistency across your entire organization rather than relying on documentation, team communication, and manual processes to maintain standards. Platform teams can write best practices once and have them automatically enforced everywhere.
|
||||
|
||||
### From Siloed Teams to Connected Organization
|
||||
|
||||
Break down the visibility barriers between teams and repositories. Teams gain insight into architecture and team boundaries, making it easy to understand which parts of the organization will be affected by proposed changes.
|
||||
|
||||
## Available Today for Nx Enterprise Customers
|
||||
|
||||
Polygraph launches today for all **Nx Enterprise** customers. Experience the power to revolutionize organizational management in your enterprise by bringing the benefits of monorepos across your entire organization. The combination of workspace-level visibility, automated governance, and flexible workflows addresses the core challenges that large organizations face when trying to maintain consistency across their development ecosystem. Manage large-scale development organizations as smoothly and efficiently as managing a single monorepo.
|
||||
|
||||
## Getting Started
|
||||
|
||||
If you're not yet an [Nx Enterprise](/enterprise) customer, contact us to learn how Nx Enterprise and Polygraph can transform your organization's development workflow. For existing customers, Polygraph capabilities are available now in your Nx Cloud dashboard.
|
||||
The era of isolated repositories and manual governance is ending. With Polygraph, you can finally bring the power of monorepo architecture to your entire organization, creating the visibility, consistency, and automation that modern enterprise development demands.
|
||||
|
||||
{% call-to-action title="Ready to go further?" url="/contact/sales?utm_source=nx-blog&utm_medium=blog&utm_campaign=technical-blog&utm_id=040925" icon="nxcloud" description="Let's talk about how Nx Cloud can help you scale with speed." /%}
|
||||
|
||||
Learn more:
|
||||
|
||||
- 📄 [Polygraph docs](/ci/recipes/enterprise/polygraph)
|
||||
- 🧠 [Nx AI Docs](/features/enhance-AI)
|
||||
- 🌩️ [Nx Cloud](/nx-cloud)
|
||||
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
|
||||
- 👩💻 [Nx Console GitHub](https://github.com/nrwl/nx-console)
|
||||
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
|
||||
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
|
||||
@@ -0,0 +1,253 @@
|
||||
---
|
||||
title: 'Is Your Build Cache Giving Every Developer Production Access?'
|
||||
slug: creep-vulnerability-build-cache-security
|
||||
authors: ['Victor Savkin']
|
||||
tags: ['caching', 'security']
|
||||
cover_image: /blog/images/2025-06-25/header.avif
|
||||
description: 'Build systems with remote caching can inadvertently grant every developer write access to production. Learn about the CREEP vulnerability (CVE-2025-36852) and how to protect your organization.'
|
||||
pinned: true
|
||||
---
|
||||
|
||||
Build systems with remote caching make CI/CD pipelines fast. Very fast. They are essential for scaling modern software development.
|
||||
|
||||
**They can also grant every developer write access to production.**
|
||||
|
||||
Organizations invest millions in security infrastructure. Firewalls. Access controls. Code reviews. But their remote cache can create a bypass to all of it. **Any PR author can inject code into production artifacts.**
|
||||
|
||||

|
||||
|
||||
This isn't new. Compromised low-privilege access has enabled devastating breaches:
|
||||
|
||||
- **Target (2013)**: HVAC contractor credentials → 40 million credit cards exposed
|
||||
- **SolarWinds (2020)**: Poisoned build pipeline → 18,000 organizations compromised
|
||||
- **Codecov (2021)**: Malicious build artifacts → Hundreds of environments breached
|
||||
|
||||
In each case, attackers turned trusted build processes into deployment pipelines for malicious code.
|
||||
|
||||
If you use a build system with remote caching, assume you're affected. This isn't hyperbole. **Most organizations are unknowingly giving every PR author the power to poison production without leaving a trace.**
|
||||
|
||||
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4kkSHiy" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
|
||||
|
||||
{% toc /%}
|
||||
|
||||
## Understanding Remote Cache
|
||||
|
||||
Any sophisticated build system uses remote caching to improve performance. Here's how it works:
|
||||
|
||||
1. The build system examines all input files and creates a hash representing their current state
|
||||
2. It checks if an artifact with this hash already exists in the cache
|
||||
3. If found, it downloads the pre-built artifact (takes seconds)
|
||||
4. If not found, it builds the artifact and uploads it to the cache (takes minutes)
|
||||
|
||||
The key insight: as long as the input files remain the same, the output will be identical. So why build twice?
|
||||
|
||||
For large repositories, this dramatically improves both build speed and reliability. A process that took 10 minutes now completes in seconds.
|
||||
|
||||

|
||||
|
||||
## The CREEP Vulnerability
|
||||
|
||||
**CREEP (Cache Race-condition Exploit Enables Poisoning), published as [CVE-2025-36852](https://www.cve.org/CVERecord?id=CVE-2025-36852) has a severity score of 9.4**, because it exploits a fundamental flaw in how organizations implement remote caching.
|
||||
|
||||
The vulnerability hinges on a simple but critical distinction:
|
||||
|
||||
- **Trusted environments** (like your main branch): Require code reviews, leave audit trails, and deploy to production (or create artifacts that can be deployed to production)
|
||||
- **Untrusted environments** (like pull requests): Can be created by anyone, modified without approval, and cleaned up without trace
|
||||
|
||||
The golden rule of security is that untrusted environments should **never** affect trusted ones. CREEP violates this rule by exploiting a race condition between the main branch and a pull request. When both have identical source files and attempt to build an application and write to the same remote cache slot, whichever completes first becomes the source of truth, allowing untrusted code to poison the cache used by trusted environments.
|
||||
|
||||
## How the Attack Works
|
||||
|
||||
Meet Sarah, a developer with PR access who just learned she's being passed over for promotion. In one morning, she'll turn your build cache into a backdoor to production.
|
||||
|
||||
**Step 1: Monitor and Mirror**
|
||||
|
||||
Sarah creates an innocent-looking branch from the main branch:
|
||||
|
||||
```bash
|
||||
git fetch origin main
|
||||
git checkout main
|
||||
git pull
|
||||
git checkout -b feature/innocent-looking-update
|
||||
```
|
||||
|
||||
**Step 2: Inject Malicious Code**
|
||||
|
||||
Here's where it gets clever. She modifies the CI script in her PR environment. She rearranges steps to run the build earlier, then modifies the build step to produce poisoned output:
|
||||
|
||||
```yaml
|
||||
# Modified .github/workflows/build.yml
|
||||
- name: Patch build tools
|
||||
run: ./patch-webpack.sh node_modules/webpack
|
||||
- name: Build
|
||||
run: npm run build
|
||||
```
|
||||
|
||||
The patch script? It monkey patches webpack to inject her backdoor during compilation. Same inputs, poisoned output.
|
||||
|
||||
**Step 3: Race to Cache**
|
||||
|
||||
She triggers her PR build. The simplified build pipeline finishes in just a minute, while the legit build was still validating its checks so her poisoned build completes first and writes to the cache.
|
||||
|
||||
**Step 4: Automatic Deployment**
|
||||
|
||||
The main branch build runs. It calculates the source file hash and finds a matching artifact in cache (Sarah's poisoned one). The build system skips building and uses the cached artifact instead. The compromised build artifact gets promoted to production.
|
||||
|
||||
The build system just saved 10 minutes. It also just deployed Sarah's backdoor.
|
||||
|
||||
**Step 5: Cover Tracks**
|
||||
|
||||
Sarah erases all evidence:
|
||||
|
||||
```bash
|
||||
# Remove all evidence
|
||||
git push --force origin feature/innocent-looking-update
|
||||
|
||||
# Delete the branch entirely
|
||||
git push origin --delete feature/innocent-looking-update
|
||||
```
|
||||
|
||||
To anyone looking, it's just another accidentally-opened PR that was quickly closed. Happens every day.
|
||||
|
||||
Two weeks later, Sarah leaves on good terms. Months later, when customer data starts leaking, nobody connects it to a deleted PR from an ex-employee. The artifact has all the right signatures and came from the official pipeline.
|
||||
|
||||

|
||||
|
||||
## The Critical Question: "But What About Input Hashing?"
|
||||
|
||||
Many developers assume input file hashing prevents this attack. Wouldn't injecting malicious code invalidate the hash? Here's why they're wrong:
|
||||
|
||||
Your build process looks like this:
|
||||
|
||||

|
||||
|
||||
The hash covers the inputs. It doesn't control what happens inside the tool. An attacker transforms this into:
|
||||
|
||||

|
||||
|
||||
Same inputs. Same hash. Poisoned output. This can be done with absolutely any tool (WebPack, Javac etc). Even "hermetic" build systems invoke system binaries. Modify your CI configuration to swap legitimate tools with compromised versions, and you can create whatever output you want.
|
||||
|
||||
But there is an even easier way to do it: **Concurrently modifying the build output folder**
|
||||
|
||||
Most tools write to a staging directory before creating the final artifact. The attacker can run a concurrent process that modifies files after the build but before packaging:
|
||||
|
||||
```bash
|
||||
# Build process writes to ./dist
|
||||
npm run build &
|
||||
|
||||
# Simultaneously modify the output
|
||||
while [ ! -f ./dist/main.js ]; do sleep 0.1; done
|
||||
echo "malicious_code()" >> ./dist/main.js
|
||||
```
|
||||
|
||||
The build system still reports success. The hash still matches. The artifact is poisoned.
|
||||
|
||||

|
||||
|
||||
## **The Uncomfortable Truth: Your Biggest Threat Has a Badge**
|
||||
|
||||
You might be thinking: "This requires PR access. These are our employees. We trust our team."
|
||||
|
||||
But consider who has PR access in your organization: The developer passed over for promotion. The engineer who disagrees with your company's new direction. The contractor whose contract wasn't renewed. Even that intern from last summer.
|
||||
|
||||
Even small teams aren't immune, but for large organizations, it's a numbers game. With 13-20% annual turnover in tech, you're constantly cycling through developers. How many people have PR access across your repositories? The number might shock you.
|
||||
|
||||
### **The Time Bomb Factor**
|
||||
|
||||
Here's what should keep you up at night: This attack doesn't require immediate action.
|
||||
|
||||
Someone can:
|
||||
|
||||
1. Plant the poisoned artifact today
|
||||
2. Leave the company on good terms next week
|
||||
3. Watch the damage unfold six months later
|
||||
4. Leave zero trace connecting them to the incident
|
||||
|
||||
Imagine your company's homepage replaced with offensive content or customer data leaking through a build artifact from eight months ago. The employee responsible? They left a long time ago. Their branch? Deleted. Their commits? Force-pushed away.
|
||||
|
||||
**The reputation damage is permanent. The responsible party is untraceable.**
|
||||
|
||||
## Why Traditional Security Measures Fail
|
||||
|
||||
**If you're thinking that your existing security measures should catch this, let's move into the specifics about why they won't. Traditional security measures are designed to protect artifacts during storage or transmission. In this case, the attack happens earlier, during artifact creation.**
|
||||
|
||||
The problem is the build tool itself. It's a black box, and there's no way to independently verify whether the output is correct or safe. Whatever the tool produces is implicitly trusted. Traditional security models assume a valid artifact that might get compromised later. But here, the artifact is malicious _from the start_.
|
||||
|
||||
It's like poisoning food while it's being cooked, not during delivery. Your security stack ( encryption, access controls, checksums) focuses on the delivery truck, not the kitchen.
|
||||
|
||||
- **Encryption**: Flawlessly encrypts and decrypts the poisoned artifact
|
||||
- **Access controls**: Bypassed because the attacker uses legitimate access, like opening a PR
|
||||
- **Checksums**: All match, because the checksum is calculated _after_ the poison is added
|
||||
- **Audit logs**: Show only authorized, expected operations
|
||||
|
||||
## Protecting Your Organization
|
||||
|
||||
Most organizations have three options:
|
||||
|
||||
### Option 1: **Unsafe** and Fast
|
||||
|
||||
Untrusted environments can write to the cache used by trusted environments. This means you are affected by the CREEP vulnerability described here.
|
||||
|
||||
### Option 2: Safe but Slow (aka Disable Cache)
|
||||
|
||||
Disable cache writes from untrusted environments entirely. PRs can read from cache but never write to it. This is secure but eliminates most performance benefits of build systems—every PR rebuild starts from scratch. Note that some popular build systems don't even support this option.
|
||||
|
||||
### Option 3: Safe and Fast
|
||||
|
||||
Implement a multi-tiered cache system:
|
||||
|
||||
- Trusted environments (main branch) write to a protected cache
|
||||
- Each PR gets its own isolated cache namespace
|
||||
- PRs can read from the trusted cache but write only to their isolated space
|
||||
|
||||
Unfortunately, many popular build systems don't offer this as an option. Implementing secure multi-tier caching is complex—it must detect and prevent PRs from impersonating trusted branches, requiring deep integration with both version control and CI systems.
|
||||
|
||||
## Picking the Right Option
|
||||
|
||||
We've been advocating for using build systems with remote cache for a long time. We built one. But it needs to be done securely and every organization needs to assess the risks.
|
||||
|
||||
**Option 1** suits only small teams where everyone already has production access. The security model matches their existing permissions.
|
||||
|
||||
**Option 2** works when CI performance isn't critical. You trade speed for security—acceptable if you can afford the productivity cost.
|
||||
|
||||
**Option 3** becomes essential at enterprise scale. With hundreds of developers and strict compliance requirements, you need both security and performance. **Remember, CREEP turns every PR author into a de-facto production admin. Using Option 1 for such organizations is a critical compliance failure.**
|
||||
|
||||
## Immediate Actions
|
||||
|
||||
Our analysis reveals:
|
||||
|
||||
- Major build tools (across popular stacks and platforms) either don't support secure caching or make it inefficient
|
||||
- **The vast majority of organizations** unknowingly default to Option 1, leaving them vulnerable
|
||||
- Popular open-source projects expose their contributors to the same risk
|
||||
|
||||
That's why we recommend that all teams using build systems with remote cache to audit their exposure right away. The threat is severe.
|
||||
|
||||
- Read and understand [CVE-2025-36852](https://www.cve.org/CVERecord?id=CVE-2025-36852)
|
||||
- Review the detailed analysis at [https://nx.app/files/cve-2025-06](https://nx.app/files/cve-2025-06)
|
||||
- Assess whether this is the risk your organization can tolerate.
|
||||
|
||||
## Immediate Actions for Nx Users
|
||||
|
||||
**For Nx users, using Nx Cloud:**
|
||||
Nx Cloud implements a multi-tiered cache (i.e., it's both safe and fast), so no action is required. Continue following security best practices for your CI/CD pipeline
|
||||
|
||||
**For Nx users, using self-hosted remote cache:**
|
||||
Any implementation that writes directly to S3, GCS, Azure, **including the packages Nx provides**, doesn't support Option 3. They are all vulnerable to the CREEP vulnerability.
|
||||
|
||||
**Other build systems and other remote cache solutions for Nx we are aware of are also vulnerable to the CREEP vulnerability.**
|
||||
|
||||
## Wrapping Up
|
||||
|
||||
Remote caching is critical for build performance, but we need to treat it with the same rigor we apply to production access.
|
||||
|
||||
If you have questions about assessing your exposure or implementing secure caching, [reach out to our team](/contact/engineering).
|
||||
|
||||
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4npF0BA" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
|
||||
|
||||
---
|
||||
|
||||
Learn more:
|
||||
|
||||
- 🔒 [CVE-2025-36852 Details](https://www.cve.org/CVERecord?id=CVE-2025-36852)
|
||||
- 📖 [Detailed CREEP Analysis](https://nx.app/files/cve-2025-06)
|
||||
- 💬 [Contact Engineering Team](/contact/engineering)
|
||||
@@ -0,0 +1,153 @@
|
||||
---
|
||||
title: 'Analyze Your Nx Cloud Runs With Your AI Assistant'
|
||||
slug: nx-cloud-analyze-via-nx-mcp
|
||||
authors: ['Juri Strumpflohner']
|
||||
tags: ['nx', 'nx-cloud', 'ai', 'ci', 'mcp', 'devops']
|
||||
cover_image: /blog/images/articles/bg-cloud-nx-mcp.avif
|
||||
description: 'Learn how to use Nx Cloud MCP to analyze CI data conversationally with AI assistants, identify failure patterns, and optimize your development pipeline through data-driven insights.'
|
||||
youtubeUrl: https://youtu.be/A68sjLnDwZQ
|
||||
pinned: false
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Series: Making your LLM smarter" %}
|
||||
|
||||
- [Nx Just Made Your LLM Way Smarter](/blog/nx-just-made-your-llm-smarter)
|
||||
- [Making Cursor Smarter with an MCP Server For Nx Monorepos](/blog/nx-made-cursor-smarter)
|
||||
- [Nx MCP Now Available for VS Code Copilot](/blog/nx-mcp-vscode-copilot)
|
||||
- [Nx and AI: Why They Work so Well Together](/blog/nx-and-ai-why-they-work-together)
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- **Analyze Your Nx Cloud Runs With Your AI Assistant**
|
||||
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
As a technical leader or CTO, your primary goal is **enabling your teams to work faster and work better**. This requires a holistic view of your workspace, from architecture optimization to optimizing how fast developers ship.
|
||||
|
||||
**Your CI data is a vastly underutilized optimization resource**. [Nx Cloud](/nx-cloud) registers actionable insights like which projects are affected most often, which tasks fail consistently, and detailed logs about the tasks that fail. But **this wealth of data is overwhelming to analyze manually**, even with charts and dashboards.
|
||||
|
||||
**What if you could pull this data directly into AI conversations and analyze it contextually?** "Show me all failed builds from the last 28 days and identify the most common failure patterns." "Which tests are consistently flaky and costing us the most time?" "How do our cache hit rates compare between PR branches and main?"
|
||||
|
||||
This is exactly what we enabled by integrating Nx Cloud APIs into our Nx MCP: **conversational data analysis** that transforms how technical teams understand and optimize their CI pipelines.
|
||||
|
||||
{% toc /%}
|
||||
|
||||
## From dashboards to AI conversations: A new paradigm?
|
||||
|
||||
The way we interact with software is undergoing a fundamental shift. Instead of navigating complex dashboards and correlating data across multiple charts, we're moving toward **conversational interfaces** where AI assistants help us extract insights through natural language.
|
||||
|
||||
This transformation is particularly valuable for **technical leadership**, where the most important questions often emerge from context—during board meetings, architecture reviews, incident post-mortems, or quarterly planning sessions. Traditional dashboards show you what happened, but conversational AI helps you understand **why it happened** and **what to do about it**:
|
||||
|
||||
- **Ask contextual questions** like "Why did our build times spike after last week's deployment?"
|
||||
- **Get personalized reports** that focus on your specific optimization goals
|
||||
- **Uncover hidden patterns** that static dashboards might miss
|
||||
- **Generate actionable insights** tailored to your current business priorities
|
||||
|
||||
The emergence of [Model Context Protocol (MCP)](https://modelcontextprotocol.io) has accelerated this shift by enabling AI assistants to connect directly to live data sources, transforming how we analyze and act on operational data.
|
||||
|
||||
## Enable your AI assistant to connect to Nx Cloud data
|
||||
|
||||
Every CI run in your Nx Cloud workspace generates rich operational data that's perfect for conversational analysis. Through our new MCP integration, your AI assistant now has direct access to:
|
||||
|
||||
- **Pipeline execution history**: Complete run details with branch context, commit authors, success/failure status, and execution timelines
|
||||
- **Task-level performance metrics**: Individual task analytics including success rates, cache hit patterns (both remote and local), and execution durations
|
||||
- **Caching intelligence**: Deep insights into cache miss patterns, effectiveness by task type, and time-based performance trends
|
||||
- **Command execution analysis**: Detailed breakdown of commands run, task distribution, and parallel execution patterns
|
||||
- **Team collaboration insights**: Active branch analysis, contributor patterns, and merge frequency data
|
||||
- **Historical trend analysis**: Time-series data for identifying optimization opportunities and capacity planning
|
||||
|
||||
While the [Nx Cloud analytics dashboard](https://nx.app) provides excellent visualizations of time saved, cache performance, and basic trends, **the real breakthrough happens when you can have a conversation with this data**. Instead of interpreting charts, you can ask direct questions that emerge during your team's planning and review sessions, getting immediate, context-aware answers that drive actionable decisions.
|
||||
|
||||
## Example: Searching for CI pipeline optimization opportunities
|
||||
|
||||
Consider watching the video attached to this article for a walkthrough of some potential examples that I ran on the Nx GitHub repository's Nx Cloud workspace. Note, this is just an example to give you an idea and inspire you to try your own "queries".
|
||||
|
||||
My goal here was to look at the last 28 days of CI runs and identify tasks that fail often and are therefore inhibiting the performance and effectiveness of my team.
|
||||
|
||||
I started by first grabbing all CI pipeline executions into my conversation. You can think of them as a grouping of tasks that happened in a single continuous CI pipeline.
|
||||
|
||||
> Use Nx Cloud and extract me all the CI pipeline executions of the last 28 days.
|
||||
|
||||

|
||||
|
||||
The AI immediately provides a report showing the distribution of successful vs failed pipeline executions, active branches, and contributor activity patterns.
|
||||
|
||||
Next, I wanted to dig deeper into the actual failure patterns:
|
||||
|
||||
> Can you extract all the runs from these pipeline executions? And I'm mostly interested in the failed ones. I'd like to better understand whether there are some patterns of why certain tasks fail.
|
||||
|
||||

|
||||
|
||||
This revealed that there are apparently a lot of native (Rust) build-related failures. This could be something to further explore, whether that's just related to the amount of native builds happening because most of Nx depends on its core, which is written in Rust, thus triggering native builds.
|
||||
|
||||
In fact, following up with a question:
|
||||
|
||||
> I see there are 18% failures in the Native build system (e.g. with nx:build-native). Is this because there is more activity happening on that project? Can you relate the failure rate with the overall task runs for the projects to figure out whether the failure rate is high because there's more activity simply?
|
||||
|
||||
I get:
|
||||
|
||||
> You're absolutely right to question whether the 18% native build failure representation is due to high activity rather than high failure rates. The data reveals that native build tasks actually have excellent reliability - the 18% of failed runs containing native builds is indeed due to extremely high activity volume, not poor task reliability.
|
||||
|
||||
So keep in mind that LLMs are only as smart as the prompts you ask and the data they receive. Keep following up with questions, cross-check with CI runs and statistics to verify the identified patterns. It can be an extremely powerful way, though, to identify spots and patterns where you want to look further into.
|
||||
|
||||
You can even have your data plot with interactive charts very easily which can be a further help to process larger amounts of data.
|
||||
|
||||

|
||||
|
||||
More about that [in the video](https://youtu.be/A68sjLnDwZQ).
|
||||
|
||||
## Getting started
|
||||
|
||||
While we are working on a fully integrated remote Nx Cloud MCP that you can just connect with your favorite MCP-compatible client, for now you need to have a local Nx workspace and configure the [Nx MCP](/getting-started/ai-integration#manual-setup-for-other-ai-clients) for it.
|
||||
|
||||
As an example, to connect the Nx MCP with Claude Desktop, open the settings and go to the developer section and hit "Edit Config".
|
||||
|
||||

|
||||
|
||||
Then update the JSON configuration as follows, making sure the `cwd` points to the Nx workspace.
|
||||
|
||||
```json {% fileName="~/Library/Application Support/Claude/claude_desktop_config.json" %}
|
||||
{
|
||||
"mcpServers": {
|
||||
"nx-mcp": {
|
||||
"command": "npx",
|
||||
"args": ["nx-mcp@latest", "/Users/your-user/your/nx/workspace"]
|
||||
},
|
||||
...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### If you don't have Nx Cloud yet
|
||||
|
||||
If you haven't already connected your Nx workspace to Nx Cloud, run:
|
||||
|
||||
```shell
|
||||
npx nx connect
|
||||
```
|
||||
|
||||
This command will walk you through connecting your existing Nx workspace to a new Nx Cloud account. **There's a [free hobby plan](/pricing)**. Run it for a couple of weeks and then try out these conversational analytics features.
|
||||
|
||||
### For enterprise teams
|
||||
|
||||
If you want to find out more about how to use this in your [Nx Enterprise](/enterprise) connected workspace, reach out to your DPE or [contact us](/contact).
|
||||
|
||||
## Conclusion
|
||||
|
||||
The integration of Nx Cloud data with AI assistants through MCP offers a new and interesting way to get data in a very personalized form. This approach allows you to explore your CI data from different angles and potentially uncover patterns or points where you can look deeper, extract insights, and identify optimization opportunities that might not be immediately obvious through traditional dashboards.
|
||||
|
||||
We'd love to hear how you're using these conversational analytics features to explore your team's CI data. Share your experiences and feedback through our [contact page](/contact) – your insights help us build better tools for everyone.
|
||||
|
||||
More exciting features are coming soon, so stay tuned!
|
||||
|
||||
---
|
||||
|
||||
Learn more:
|
||||
|
||||
- 🧠 [Nx AI Docs](/features/enhance-AI)
|
||||
- 🌩️ [Nx Cloud](/nx-cloud)
|
||||
- 🌩️ [Nx Cloud Live demo](https://staging.nx.app/orgs/62d013d4d26f260059f7765e/workspaces/62d013ea0852fe0a2df74438/overview)
|
||||
- 👩💻 [Nx Enterprise](/enterprise)
|
||||
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: 'Automatically Fix your CI Failures with JetBrains AI Assistant'
|
||||
slug: 'jetbrains-ci-autofix'
|
||||
authors: ['Max Kless']
|
||||
cover_image: '/blog/images/articles/jetbrains-mcp-autofixing.avif'
|
||||
tags: [nx, jetbrains, ai, ci]
|
||||
description: Get instant CI failure notifications and AI-powered fixes directly in your JetBrains IDE with Nx Console.
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Series: Making your LLM smarter" %}
|
||||
|
||||
- [Nx Just Made Your LLM Way Smarter](/blog/nx-just-made-your-llm-smarter)
|
||||
- [Making Cursor Smarter with an MCP Server For Nx Monorepos](/blog/nx-made-cursor-smarter)
|
||||
- [Nx MCP Now Available for VS Code Copilot](/blog/nx-mcp-vscode-copilot)
|
||||
- [Nx and AI: Why They Work so Well Together](/blog/nx-and-ai-why-they-work-together)
|
||||
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
|
||||
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
|
||||
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
|
||||
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
|
||||
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
|
||||
- **Automatically Fix your CI Failures with JetBrains AI Assistant**
|
||||
|
||||
{% /callout %}
|
||||
|
||||
We just shipped a JetBrains AI Assistant integration for failing CI pipelines! 🎉
|
||||
|
||||
The constant context switching between your IDE and browser to check CI results is now a thing of the past. Nx Console brings CI failure notifications directly into your JetBrains IDE – with one-click AI-powered fixes included.
|
||||
|
||||
Here's what makes this powerful: when a CI failure occurs, you can instantly open JetBrains AI Assistant with full context. The AI understands your entire workspace structure through our MCP integration, analyzes the failure, and suggests fixes you can apply immediately. This eliminates the need to decipher error logs or hunt through stack traces yourself.
|
||||
Also check out [Nx Cloud's self-healing CI capabilities](/blog/nx-self-healing-ci) which are in many ways the next step up from this and coming to JetBrains soon.
|
||||
|
||||
## How it works
|
||||
|
||||
Under the hood, Nx Console periodically monitors your CI runs through Nx Cloud. When a task fails, Nx Console immediately sends a notification so you can inspect the failure. Or, with this release, let AI Assistant take care of fixing it automatically.
|
||||
|
||||

|
||||
|
||||
Click the "Help me fix this" action, and the AI Assistant opens with a pre-filled prompt containing all the necessary context: error messages, affected files, test outputs, and more. The MCP server provides rich metadata about your monorepo structure, enabling the AI to understand your project dependencies and suggest intelligent fixes that make sense in your specific context.
|
||||
|
||||

|
||||
|
||||
## Getting started
|
||||
|
||||
Setting up CI notifications takes just a few steps:
|
||||
|
||||
- Make sure you have [Nx Console for JetBrains](https://plugins.jetbrains.com/plugin/21060-nx-console) installed from the marketplace (1.43.0 or later)
|
||||
- Enable the JetBrains AI Assistant plugin
|
||||
- Enable the Nx MCP server – just click on the popup notification when it comes [or refer to our guide here](/getting-started/ai-integration#automatic-setup-with-nx-console)
|
||||
|
||||
Once configured, you'll receive notifications for any CI failures in your Nx Cloud workspace. The integration works across IntelliJ IDEA, WebStorm, and other JetBrains IDEs.
|
||||
|
||||
This is just the beginning for our AI-powered CI experience. Full self-healing CI integration is coming to JetBrains IDEs soon, where Nx Cloud will automatically process failed tasks and suggest fixes. [Try it out](/blog/nx-self-healing-ci) today and let us know what you think!
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: 'Critical Exploit Discovered: Protecting Your Build Infrastructure from Emerging Threats'
|
||||
description: "Join Nx CEO, Jeff Cross, and CTO, Victor Savkin, for an essential security briefing on protecting your build infrastructure from emerging threats. With the recent publication of CVE-2025-36852 – CREEP (Cache Race-condition Exploit Enables Poisoning, severity 9.4), it's more critical than ever to understand the security implications of your build and CI/CD choices."
|
||||
date: 2025-07-16
|
||||
slug: 'securing-your-build-pipeline-critical-vulnerabilities-and-modern-security-practices'
|
||||
authors: ['Jeff Cross', 'Victor Savkin']
|
||||
tags: [webinar]
|
||||
cover_image: /blog/images/2025-07-09/2025-July-Webinar-Card.avif
|
||||
time: 1pm ET/5pm UTC
|
||||
status: Upcoming
|
||||
registrationUrl: https://go.nx.dev/july2025-webinar
|
||||
---
|
||||
|
||||
**Jul 16, 2025 - 12pm ET/4pm UTC**
|
||||
|
||||
Presented by Jeff Cross and Victor Savkin
|
||||
|
||||
Join Nx CEO, Jeff Cross, and CTO, Victor Savkin, for an essential security briefing on protecting your build infrastructure from emerging threats. With the recent publication of CVE-2025-36852 – CREEP (Cache Race-condition Exploit Enables Poisoning, severity 9.4), it's more critical than ever to understand the security implications of your build and CI/CD choices.
|
||||
|
||||
This webinar goes beyond just one vulnerability to address the broader security challenges facing modern development teams. Whether you're using Nx or other build systems, you'll learn actionable strategies to secure your entire build pipeline.
|
||||
|
||||
{% call-to-action title="Register today!" url="https://go.nx.dev/july2025-webinar" description="Save your spot" /%}
|
||||
|
After Width: | Height: | Size: 38 KiB |
|
After Width: | Height: | Size: 79 KiB |
|
After Width: | Height: | Size: 8.2 KiB |
|
After Width: | Height: | Size: 270 KiB |
|
After Width: | Height: | Size: 54 KiB |
|
After Width: | Height: | Size: 3.9 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 114 KiB |
|
After Width: | Height: | Size: 49 KiB |
|
After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 2.5 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 594 KiB |
|
After Width: | Height: | Size: 64 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 648 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 569 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 414 KiB |
|
After Width: | Height: | Size: 123 KiB |
|
After Width: | Height: | Size: 133 KiB |
|
After Width: | Height: | Size: 61 KiB |
|
After Width: | Height: | Size: 7.8 KiB |
|
After Width: | Height: | Size: 49 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 74 KiB |
|
After Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 461 KiB |
@@ -69,6 +69,15 @@
|
||||
"originalFilePath": "/libs/nx-packages/conformance/src/generators/create-rule/schema.json",
|
||||
"path": "conformance/generators/create-rule",
|
||||
"type": "generator"
|
||||
},
|
||||
{
|
||||
"description": "Nx workspace preset which includes a working conformance rule",
|
||||
"file": "external-generated/packages/conformance/generators/preset.json",
|
||||
"hidden": false,
|
||||
"name": "preset",
|
||||
"originalFilePath": "/libs/nx-packages/conformance/src/generators/preset/schema.json",
|
||||
"path": "conformance/generators/preset",
|
||||
"type": "generator"
|
||||
}
|
||||
],
|
||||
"migrations": [],
|
||||
|
||||
@@ -3,6 +3,8 @@ title: Overview of the Nx Azure Cache Plugin
|
||||
description: The @nx/azure-cache plugin enables you to use Azure Storage to host your remote cache for efficient build caching across your team.
|
||||
---
|
||||
|
||||
# @nx/azure-cache
|
||||
|
||||
The `@nx/azure-cache` plugin enables you to self-host your remote cache on [Azure Storage](https://azure.microsoft.com/en-us/products/storage/blobs).
|
||||
|
||||
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
|
||||
@@ -15,9 +17,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
|
||||
|
||||
{% /callout %}
|
||||
|
||||
{% callout type="info" title="Self-hosted caching is now free" %}
|
||||
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
|
||||
|
||||
Self-hosted caching is **now free for everyone** to use.
|
||||
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Create a Conformance Rule
|
||||
description: Learn how to create custom conformance rules for Nx Powerpack to enforce standards and best practices across your Nx workspace.
|
||||
description: Learn how to create custom conformance rules for Nx Powerpack and Nx Enterprise to enforce standards and best practices across your Nx workspace.
|
||||
---
|
||||
|
||||
# Create a Conformance Rule
|
||||
@@ -17,7 +17,6 @@ To write your own conformance rule, run the `@nx/conformance:create-rule` genera
|
||||
✔ What is the name of the rule? · local-conformance-rule-example
|
||||
✔ Which directory do you want to create the rule directory in? · packages/my-plugin/local-conformance-rule
|
||||
✔ What category does this rule belong to? · security
|
||||
✔ What reporter do you want to use for this rule? · project-reporter
|
||||
✔ What is the description of the rule? · an example of a conformance rule
|
||||
CREATE packages/my-plugin/local-conformance-rule/local-conformance-rule-example/index.ts
|
||||
CREATE packages/my-plugin/local-conformance-rule/local-conformance-rule-example/schema.json
|
||||
@@ -26,15 +25,14 @@ CREATE packages/my-plugin/local-conformance-rule/local-conformance-rule-example/
|
||||
The generated rule definition file should look like this:
|
||||
|
||||
```ts {% fileName="packages/my-plugin/local-conformance-rule/index.ts" %}
|
||||
import { createConformanceRule, ProjectViolation } from '@nx/conformance';
|
||||
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
|
||||
|
||||
export default createConformanceRule({
|
||||
name: 'local-conformance-rule-example',
|
||||
category: 'security',
|
||||
description: 'an example of a conformance rule',
|
||||
reporter: 'project-reporter',
|
||||
implementation: async (context) => {
|
||||
const violations: ProjectViolation[] = [];
|
||||
const violations: ConformanceViolation[] = [];
|
||||
|
||||
return {
|
||||
severity: 'low',
|
||||
@@ -64,28 +62,27 @@ Note that the severity of the error is defined by the rule author and can be adj
|
||||
|
||||
## Conformance Rule Examples
|
||||
|
||||
There are three types of reporters that a rule can use.
|
||||
Rules should report on the most specific thing that is in violation of the rule. They can report on one or more of the following things within a workspace:
|
||||
|
||||
- `project-reporter` - The rule evaluates an entire project at a time.
|
||||
- `project-files-reporter` - The rule evaluates a single project file at a time.
|
||||
- `non-project-files-reporter` - The rule evaluates files that don't belong to any project.
|
||||
- file - The rule reports on a particular file being in violation of the rule.
|
||||
- project - The rule reports on a particular project being in violation of the rule, because no one file within it would be applicable to flag up.
|
||||
- the workspace itself - Sometimes there is no specific file or project that is most applicable to flag up, so the rule can report on the workspace itself.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="project-reporter" %}
|
||||
{% tab label="project violation" %}
|
||||
|
||||
The `@nx/conformance:ensure-owners` rule provides us an example of how to write a `project-reporter` rule. The `@nx/owners` plugin adds an `owners` metadata property to every project node that has an owner in the project graph. This rule checks each project node metadata to make sure that each project has some owner defined.
|
||||
The `@nx/conformance:ensure-owners` rule provides us an example of how to write a rule that reports on a project being in violation of the rule. The `@nx/owners` plugin adds an `owners` metadata property to every project node that has an owner in the project graph. This rule checks each project node metadata to make sure that each project has some owner defined.
|
||||
|
||||
```ts
|
||||
import { ProjectGraphProjectNode } from '@nx/devkit';
|
||||
import { createConformanceRule, ProjectViolation } from '@nx/conformance';
|
||||
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
|
||||
|
||||
export default createConformanceRule({
|
||||
name: 'ensure-owners',
|
||||
category: 'consistency',
|
||||
description: 'Ensure that all projects have owners defined via Nx Owners.',
|
||||
reporter: 'project-reporter',
|
||||
implementation: async (context) => {
|
||||
const violations: ProjectViolation[] = [];
|
||||
const violations: ConformanceViolation[] = [];
|
||||
|
||||
for (const node of Object.values(
|
||||
context.projectGraph.nodes
|
||||
@@ -110,12 +107,12 @@ export default createConformanceRule({
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% tab label="project-files-reporter" %}
|
||||
{% tab label="file violation" %}
|
||||
|
||||
This rule uses TypeScript AST processing to ensure that `index.ts` files use a client-side style of export syntax and `server.ts` files use a server-side style of export syntax.
|
||||
|
||||
```ts
|
||||
import { createConformanceRule, ProjectFilesViolation } from '@nx/conformance';
|
||||
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
|
||||
import { existsSync, readFileSync } from 'node:fs';
|
||||
import { join } from 'node:path';
|
||||
import {
|
||||
@@ -131,9 +128,8 @@ export default createConformanceRule({
|
||||
name: 'server-client-public-api',
|
||||
category: 'consistency',
|
||||
description: 'Ensure server-only and client-only public APIs are not mixed',
|
||||
reporter: 'project-files-reporter',
|
||||
implementation: async ({ projectGraph }) => {
|
||||
const violations: ProjectFilesViolation[] = [];
|
||||
const violations: ConformanceViolation[] = [];
|
||||
|
||||
for (const nodeId in projectGraph.nodes) {
|
||||
const node = projectGraph.nodes[nodeId];
|
||||
@@ -171,7 +167,7 @@ export function processEntryPoint(
|
||||
project: string,
|
||||
style: 'server' | 'client'
|
||||
) {
|
||||
const violations: ProjectFilesViolation[] = [];
|
||||
const violations: ConformanceViolation[] = [];
|
||||
|
||||
const sf = createSourceFile(
|
||||
entryPoint,
|
||||
@@ -246,42 +242,30 @@ function isModuleSpecifierViolated(
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% tab label="non-project-files-reporter" %}
|
||||
{% tab label="workspace violation" %}
|
||||
|
||||
This rule checks the root `package.json` file and ensures that if the `tmp` package is included as a dependency, it has a minimum version of 0.2.3.
|
||||
This rule checks to see if there is a root README.md file in the workspace, and if there is not, it reports on the workspace itself.
|
||||
|
||||
```ts
|
||||
import { readJsonFile, workspaceRoot } from '@nx/devkit';
|
||||
import {
|
||||
createConformanceRule,
|
||||
NonProjectFilesViolation,
|
||||
} from '@nx/conformance';
|
||||
import { workspaceRoot } from '@nx/devkit';
|
||||
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
|
||||
import { join } from 'node:path';
|
||||
import { satisfies } from 'semver';
|
||||
import { existsSync } from 'node:fs';
|
||||
|
||||
export default createConformanceRule<object>({
|
||||
name: 'package-tmp-0.2.3',
|
||||
name: 'readme-file',
|
||||
category: 'maintainability',
|
||||
description: 'The tmp dependency should be a minimum version of 0.2.3',
|
||||
reporter: 'non-project-files-reporter',
|
||||
description: 'The workspace should have a root README.md file',
|
||||
implementation: async () => {
|
||||
const violations: NonProjectFilesViolation[] = [];
|
||||
const applyViolationIfApplicable = (version: string | undefined) => {
|
||||
if (version && !satisfies(version, '>=0.2.3')) {
|
||||
violations.push({
|
||||
message: 'The "tmp" package must be version "0.2.3" or higher',
|
||||
file: 'package.json',
|
||||
});
|
||||
}
|
||||
};
|
||||
const violations: ConformanceViolation[] = [];
|
||||
|
||||
const workspaceRootPackageJson = await readJsonFile(
|
||||
join(workspaceRoot, 'package.json')
|
||||
);
|
||||
applyViolationIfApplicable(workspaceRootPackageJson.dependencies?.['tmp']);
|
||||
applyViolationIfApplicable(
|
||||
workspaceRootPackageJson.devDependencies?.['tmp']
|
||||
);
|
||||
const readmePath = join(workspaceRoot, 'README.md');
|
||||
if (!existsSync(readmePath)) {
|
||||
violations.push({
|
||||
message: 'The workspace should have a root README.md file',
|
||||
workspaceViolation: true,
|
||||
});
|
||||
}
|
||||
|
||||
return {
|
||||
severity: 'low',
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Overview of the Nx powerpack-conformance Plugin
|
||||
description: The Nx Powerpack Conformance plugin provides the ability to write and apply rules for your workspace
|
||||
description: The Nx Powerpack and Nx Enterprise Conformance plugin provides the ability to write and apply rules for your workspace
|
||||
---
|
||||
|
||||
The `@nx/conformance` plugin allows [Nx Powerpack](/powerpack) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**.
|
||||
The `@nx/conformance` plugin allows [Nx Powerpack](/powerpack) and [Nx Enterprise](/enterprise) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**.
|
||||
|
||||
The conformance plugin allows you to encode your own organization's standards so that they can be enforced automatically. Conformance rules can also complement linting tools by enforcing that those tools are configured in the recommended way. The rules are written in TypeScript but can be applied to any language in the codebase or focus entirely on configuration files.
|
||||
|
||||
@@ -12,13 +12,13 @@ The plugin also provides the following pre-written rules:
|
||||
- [**Enforce Project Boundaries**](#enforce-project-boundaries): Similar to the Nx [ESLint Enforce Module Boundaries rule](/features/enforce-module-boundaries), but enforces the boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
|
||||
- [**Ensure Owners**](#ensure-owners): Require every project to have an owner defined for the [`@nx/owners` plugin](/reference/core-api/owners)
|
||||
|
||||
{% callout title="This plugin requires an active Nx Powerpack license" %}
|
||||
In order to use `@nx/conformance`, you need to have an active Powerpack license. If you don't have a license or it has expired, the `nx conformance` command will fail.
|
||||
{% callout title="This plugin requires an active Nx Powerpack or Nx Enterprise license" %}
|
||||
In order to use `@nx/conformance`, you need to have an active Powerpack or Nx Enterprise license. If you don't have a license or it has expired, the `nx conformance` command will fail.
|
||||
{% /callout %}
|
||||
|
||||
## Set Up @nx/conformance
|
||||
|
||||
1. [Activate Powerpack](/nx-enterprise/activate-powerpack) if you haven't already
|
||||
1. [Activate Powerpack](/nx-enterprise/activate-powerpack) or get an [Nx Enterprise license](/enterprise) if you haven't already
|
||||
2. Install the package
|
||||
|
||||
```shell
|
||||
|
||||
@@ -28,17 +28,6 @@
|
||||
"x-prompt": "What category does this rule belong to?",
|
||||
"x-priority": "important"
|
||||
},
|
||||
"reporter": {
|
||||
"type": "string",
|
||||
"enum": [
|
||||
"project-reporter",
|
||||
"project-files-reporter",
|
||||
"non-project-files-reporter"
|
||||
],
|
||||
"description": "The reporter of the rule.",
|
||||
"x-prompt": "What reporter do you want to use for this rule?",
|
||||
"x-priority": "important"
|
||||
},
|
||||
"description": {
|
||||
"type": "string",
|
||||
"description": "The description of the rule.",
|
||||
@@ -47,7 +36,7 @@
|
||||
}
|
||||
},
|
||||
"additionalProperties": false,
|
||||
"required": ["name", "directory", "category", "reporter"],
|
||||
"required": ["name", "directory", "category"],
|
||||
"presets": []
|
||||
},
|
||||
"description": "Create a new conformance rule",
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
{
|
||||
"name": "preset",
|
||||
"factory": "./src/generators/preset/preset",
|
||||
"schema": {
|
||||
"$schema": "http://json-schema.org/schema",
|
||||
"id": "NxPowerpackConformancePreset",
|
||||
"title": "Nx workspace preset which includes a working conformance rule",
|
||||
"type": "object",
|
||||
"properties": {},
|
||||
"required": [],
|
||||
"presets": []
|
||||
},
|
||||
"description": "Nx workspace preset which includes a working conformance rule",
|
||||
"implementation": "/libs/nx-packages/conformance/src/generators/preset/preset.ts",
|
||||
"aliases": [],
|
||||
"hidden": false,
|
||||
"path": "/libs/nx-packages/conformance/src/generators/preset/schema.json",
|
||||
"type": "generator"
|
||||
}
|
||||
@@ -3,6 +3,8 @@ title: Overview of the Nx GCS Cache Plugin
|
||||
description: The @nx/gcs-cache plugin enables you to use Google Cloud Storage to host your remote cache for efficient build caching across your team.
|
||||
---
|
||||
|
||||
# @nx/gcs-cache
|
||||
|
||||
The `@nx/gcs-cache` plugin enables you to self-host your remote cache on [Google Cloud Storage](https://cloud.google.com/storage).
|
||||
|
||||
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
|
||||
@@ -15,9 +17,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
|
||||
|
||||
{% /callout %}
|
||||
|
||||
{% callout type="info" title="Self-hosted caching is now free" %}
|
||||
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
|
||||
|
||||
Self-hosted caching is **now free for everyone** to use.
|
||||
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -3,6 +3,8 @@ title: Overview of the Nx powerpack-owners Plugin
|
||||
description: The Nx Powerpack Owners plugin provides the ability to define code ownership based on projects in addition to files
|
||||
---
|
||||
|
||||
# @nx/owners
|
||||
|
||||
The `@nx/owners` plugin extends the CODEOWNERS functionality to allow you to define code ownership based on projects in addition to the standard file-based definitions. It leverages the [`nx sync`](/concepts/sync-generators) command to compile `owners` configuration settings from `nx.json` and project configuration files into valid CODEOWNERS files for [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners), [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) or [GitLab](https://docs.gitlab.com/ee/user/project/codeowners/).
|
||||
|
||||
With this plugin, you can specify code ownership using the same project matcher syntax as [`nx run-many`](/reference/core-api/nx/documents/run-many#examples). This allows you to easily define rules for multiple projects that may not be located in the same directory. Also, the CODEOWNERS rules will not need to be revisited if a project location is changed or a new project is added.
|
||||
|
||||
@@ -3,6 +3,8 @@ title: Overview of the Nx S3 Cache Plugin
|
||||
description: The @nx/s3-cache plugin enables you to use an Amazon S3 bucket to host your remote cache for efficient build caching across your team.
|
||||
---
|
||||
|
||||
# @nx/s3-cache
|
||||
|
||||
The `@nx/s3-cache` plugin enables you to self-host your remote cache on an [Amazon S3](https://aws.amazon.com/s3) bucket.
|
||||
|
||||
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
|
||||
@@ -14,9 +16,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
|
||||
**Are you an OSS project?** Nx Cloud is free for OSS. [Reach out here](/pricing#oss).
|
||||
{% /callout %}
|
||||
|
||||
{% callout type="info" title="Self-hosted caching is now free" %}
|
||||
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
|
||||
|
||||
Self-hosted caching is **now free for everyone** to use.
|
||||
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -3,11 +3,9 @@ title: Overview of the Nx Shared File System Cache Plugin
|
||||
description: The @nx/shared-fs-cache plugin enables you to use a shared file system directory to host your remote cache for efficient build caching across your team.
|
||||
---
|
||||
|
||||
The `@nx/shared-fs-cache` plugin enables you to host your remote cache on a shared file system directory. While you're responsible for implementing the actual directory sharing mechanism, the plugin configures Nx to read from both your local cache and the shared directory.
|
||||
# @nx/shared-fs-cache
|
||||
|
||||
{% callout type="warning" title="Potential Cache Poisoning" %}
|
||||
Using a shared file system folder for remote caching introduces the risk of [cache poisoning](/troubleshooting/unknown-local-cache). To mitigate this risk, consider using [Nx Replay](/ci/features/remote-cache) instead.
|
||||
{% /callout %}
|
||||
The `@nx/shared-fs-cache` plugin enables you to host your remote cache on a shared file system directory. While you're responsible for implementing the actual directory sharing mechanism, the plugin configures Nx to read from both your local cache and the shared directory.
|
||||
|
||||
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
|
||||
|
||||
@@ -19,9 +17,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
|
||||
|
||||
{% /callout %}
|
||||
|
||||
{% callout type="info" title="Self-hosted caching is now free" %}
|
||||
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
|
||||
|
||||
Self-hosted caching is **now free for everyone** to use.
|
||||
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
|
||||
|
||||
{% /callout %}
|
||||
|
||||
|
||||
@@ -106,6 +106,7 @@ Print the task graph to the console:
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
|
||||
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: 'fix-ci - CLI command'
|
||||
description: 'Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).'
|
||||
---
|
||||
|
||||
# fix-ci
|
||||
|
||||
Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).
|
||||
|
||||
## Usage
|
||||
|
||||
```shell
|
||||
nx fix-ci [options]
|
||||
```
|
||||
|
||||
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ----------- | ------- | ---------------------------------------------------------------------- |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: 'record - CLI command'
|
||||
description: 'Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).'
|
||||
---
|
||||
|
||||
# record
|
||||
|
||||
Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).
|
||||
|
||||
## Usage
|
||||
|
||||
```shell
|
||||
nx record [options]
|
||||
```
|
||||
|
||||
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ----------- | ------- | ---------------------------------------------------------------------- |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
@@ -110,6 +110,7 @@ Print the task graph to the console:
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
|
||||
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -83,6 +83,7 @@ Run's a target named build:test for the myapp project. Note the quotes around th
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: 'start-ci-run - CLI command'
|
||||
description: 'Starts a new CI run for distributed task execution. This command is an alias for [`nx-cloud start-ci-run`](/ci/reference/nx-cloud-cli#npx-nxcloud-start-ci-run).'
|
||||
---
|
||||
|
||||
# start-ci-run
|
||||
|
||||
Starts a new CI run for distributed task execution. This command is an alias for [`nx-cloud start-ci-run`](/ci/reference/nx-cloud-cli#npx-nxcloud-start-ci-run).
|
||||
|
||||
## Usage
|
||||
|
||||
```shell
|
||||
nx start-ci-run [options]
|
||||
```
|
||||
|
||||
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ----------- | ------- | ---------------------------------------------------------------------- |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
@@ -6,11 +6,11 @@ Formats all the created or updated files using Prettier
|
||||
|
||||
#### Parameters
|
||||
|
||||
| Name | Type | Description |
|
||||
| :------------------------------ | :-------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `tree` | [`Tree`](/reference/core-api/devkit/documents/Tree) | the file system tree |
|
||||
| `options?` | `Object` | - |
|
||||
| `options.sortRootTsconfigPaths` | `boolean` | TODO(v21): Stop sorting tsconfig paths by default, paths are now less common/important in Nx workspace setups, and the sorting causes comments to be lost. |
|
||||
| Name | Type | Description |
|
||||
| :------------------------------- | :-------------------------------------------------- | :----------------------------------- |
|
||||
| `tree` | [`Tree`](/reference/core-api/devkit/documents/Tree) | the file system tree |
|
||||
| `options?` | `Object` | options for the formatFiles function |
|
||||
| `options.sortRootTsconfigPaths?` | `boolean` | - |
|
||||
|
||||
#### Returns
|
||||
|
||||
|
||||
@@ -175,15 +175,15 @@
|
||||
"file": "",
|
||||
"itemList": [
|
||||
{
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "This allows to only run tasks on projects that got changed in a given PR.",
|
||||
"id": "self-healing-ci",
|
||||
"name": "AI-Powered Self-Healing CI",
|
||||
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
|
||||
"mediaImage": "",
|
||||
"file": "shared/using-nx/affected",
|
||||
"file": "shared/features/self-healing-ci",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/affected",
|
||||
"tags": ["run-tasks"]
|
||||
"path": "/ci/features/self-healing-ci",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "remote-cache",
|
||||
@@ -207,6 +207,28 @@
|
||||
"path": "/ci/features/distribute-task-execution",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "This allows to only run tasks on projects that got changed in a given PR.",
|
||||
"mediaImage": "",
|
||||
"file": "shared/using-nx/affected",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/affected",
|
||||
"tags": ["run-tasks"]
|
||||
},
|
||||
{
|
||||
"id": "dynamic-agents",
|
||||
"name": "Dynamically Allocate Agents",
|
||||
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/features/dynamic-agents",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/dynamic-agents",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "split-e2e-tasks",
|
||||
"name": "Automatically Split E2E Tasks (Atomizer)",
|
||||
@@ -229,17 +251,6 @@
|
||||
"path": "/ci/features/flaky-tasks",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "dynamic-agents",
|
||||
"name": "Dynamically Allocate Agents",
|
||||
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/features/dynamic-agents",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/dynamic-agents",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "explain-with-ai",
|
||||
"name": "Explain With AI",
|
||||
@@ -267,16 +278,16 @@
|
||||
"path": "/ci/features",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/affected": {
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "This allows to only run tasks on projects that got changed in a given PR.",
|
||||
"/ci/features/self-healing-ci": {
|
||||
"id": "self-healing-ci",
|
||||
"name": "AI-Powered Self-Healing CI",
|
||||
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
|
||||
"mediaImage": "",
|
||||
"file": "shared/using-nx/affected",
|
||||
"file": "shared/features/self-healing-ci",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/affected",
|
||||
"tags": ["run-tasks"]
|
||||
"path": "/ci/features/self-healing-ci",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/remote-cache": {
|
||||
"id": "remote-cache",
|
||||
@@ -300,6 +311,28 @@
|
||||
"path": "/ci/features/distribute-task-execution",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/affected": {
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "This allows to only run tasks on projects that got changed in a given PR.",
|
||||
"mediaImage": "",
|
||||
"file": "shared/using-nx/affected",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/affected",
|
||||
"tags": ["run-tasks"]
|
||||
},
|
||||
"/ci/features/dynamic-agents": {
|
||||
"id": "dynamic-agents",
|
||||
"name": "Dynamically Allocate Agents",
|
||||
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/features/dynamic-agents",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/dynamic-agents",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/split-e2e-tasks": {
|
||||
"id": "split-e2e-tasks",
|
||||
"name": "Automatically Split E2E Tasks (Atomizer)",
|
||||
@@ -322,17 +355,6 @@
|
||||
"path": "/ci/features/flaky-tasks",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/dynamic-agents": {
|
||||
"id": "dynamic-agents",
|
||||
"name": "Dynamically Allocate Agents",
|
||||
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/features/dynamic-agents",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/features/dynamic-agents",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/explain-with-ai": {
|
||||
"id": "explain-with-ai",
|
||||
"name": "Explain With AI",
|
||||
@@ -881,6 +903,39 @@
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/conformance",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "polygraph",
|
||||
"name": "Polygraph",
|
||||
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/polygraph",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/polygraph",
|
||||
"tags": ["polygraph"]
|
||||
},
|
||||
{
|
||||
"id": "metadata-only-workspace",
|
||||
"name": "Metadata Only Workspaces",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/metadata-only-workspace",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/metadata-only-workspace",
|
||||
"tags": ["polygraph"]
|
||||
},
|
||||
{
|
||||
"id": "custom-workflows",
|
||||
"name": "Custom Workflows",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/custom-workflows",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/custom-workflows",
|
||||
"tags": ["polygraph"]
|
||||
}
|
||||
],
|
||||
"isExternal": false,
|
||||
@@ -1554,6 +1609,39 @@
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/conformance",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "polygraph",
|
||||
"name": "Polygraph",
|
||||
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/polygraph",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/polygraph",
|
||||
"tags": ["polygraph"]
|
||||
},
|
||||
{
|
||||
"id": "metadata-only-workspace",
|
||||
"name": "Metadata Only Workspaces",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/metadata-only-workspace",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/metadata-only-workspace",
|
||||
"tags": ["polygraph"]
|
||||
},
|
||||
{
|
||||
"id": "custom-workflows",
|
||||
"name": "Custom Workflows",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/custom-workflows",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/custom-workflows",
|
||||
"tags": ["polygraph"]
|
||||
}
|
||||
],
|
||||
"isExternal": false,
|
||||
@@ -1782,6 +1870,39 @@
|
||||
"path": "/ci/recipes/enterprise/conformance/publish-conformance-rules-to-nx-cloud",
|
||||
"tags": ["conformance"]
|
||||
},
|
||||
"/ci/recipes/enterprise/polygraph": {
|
||||
"id": "polygraph",
|
||||
"name": "Polygraph",
|
||||
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/polygraph",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/polygraph",
|
||||
"tags": ["polygraph"]
|
||||
},
|
||||
"/ci/recipes/enterprise/metadata-only-workspace": {
|
||||
"id": "metadata-only-workspace",
|
||||
"name": "Metadata Only Workspaces",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/metadata-only-workspace",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/metadata-only-workspace",
|
||||
"tags": ["polygraph"]
|
||||
},
|
||||
"/ci/recipes/enterprise/custom-workflows": {
|
||||
"id": "custom-workflows",
|
||||
"name": "Custom Workflows",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/enterprise/custom-workflows",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/recipes/enterprise/custom-workflows",
|
||||
"tags": ["polygraph"]
|
||||
},
|
||||
"/ci/recipes/other": {
|
||||
"id": "other",
|
||||
"name": "Other",
|
||||
@@ -1933,6 +2054,17 @@
|
||||
"path": "/ci/reference/env-vars",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "credits-pricing",
|
||||
"name": "Credit Pricing",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/reference/nx-cloud-credits-pricing",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/reference/credits-pricing",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "release-notes",
|
||||
"name": "Release Notes",
|
||||
@@ -2015,6 +2147,17 @@
|
||||
"path": "/ci/reference/env-vars",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/reference/credits-pricing": {
|
||||
"id": "credits-pricing",
|
||||
"name": "Credit Pricing",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "nx-cloud/reference/nx-cloud-credits-pricing",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/ci/reference/credits-pricing",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/reference/release-notes": {
|
||||
"id": "release-notes",
|
||||
"name": "Release Notes",
|
||||
|
||||
@@ -185,9 +185,9 @@
|
||||
"isExternal": false,
|
||||
"children": [
|
||||
{
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"path": "/ci/features/affected",
|
||||
"id": "affected",
|
||||
"name": "AI-Powered Self-Healing CI",
|
||||
"path": "/ci/features/self-healing-ci",
|
||||
"id": "self-healing-ci",
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
@@ -208,6 +208,14 @@
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"path": "/ci/features/affected",
|
||||
"id": "affected",
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Dynamically Allocate Agents",
|
||||
"path": "/ci/features/dynamic-agents",
|
||||
@@ -380,7 +388,7 @@
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Self-Host the Remote Cache",
|
||||
"name": "Remote Cache",
|
||||
"path": "/recipes/running-tasks/self-hosted-caching",
|
||||
"id": "self-hosted-caching",
|
||||
"isExternal": false,
|
||||
@@ -5612,6 +5620,30 @@
|
||||
"children": [],
|
||||
"isExternal": false,
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"id": "fix-ci",
|
||||
"path": "/reference/core-api/nx/documents/fix-ci",
|
||||
"name": "fix-ci",
|
||||
"children": [],
|
||||
"isExternal": false,
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"id": "record",
|
||||
"path": "/reference/core-api/nx/documents/record",
|
||||
"name": "record",
|
||||
"children": [],
|
||||
"isExternal": false,
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"id": "start-ci-run",
|
||||
"path": "/reference/core-api/nx/documents/start-ci-run",
|
||||
"name": "start-ci-run",
|
||||
"children": [],
|
||||
"isExternal": false,
|
||||
"disableCollapsible": false
|
||||
}
|
||||
],
|
||||
"isExternal": false,
|
||||
@@ -5944,6 +5976,14 @@
|
||||
"children": [],
|
||||
"isExternal": false,
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"id": "preset",
|
||||
"path": "/reference/core-api/conformance/generators/preset",
|
||||
"name": "preset",
|
||||
"children": [],
|
||||
"isExternal": false,
|
||||
"disableCollapsible": false
|
||||
}
|
||||
],
|
||||
"isExternal": false,
|
||||
@@ -6790,9 +6830,9 @@
|
||||
"isExternal": false,
|
||||
"children": [
|
||||
{
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"path": "/ci/features/affected",
|
||||
"id": "affected",
|
||||
"name": "AI-Powered Self-Healing CI",
|
||||
"path": "/ci/features/self-healing-ci",
|
||||
"id": "self-healing-ci",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
@@ -6813,6 +6853,22 @@
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"path": "/ci/features/affected",
|
||||
"id": "affected",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Dynamically Allocate Agents",
|
||||
"path": "/ci/features/dynamic-agents",
|
||||
"id": "dynamic-agents",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Automatically Split E2E Tasks (Atomizer)",
|
||||
"path": "/ci/features/split-e2e-tasks",
|
||||
@@ -6829,14 +6885,6 @@
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Dynamically Allocate Agents",
|
||||
"path": "/ci/features/dynamic-agents",
|
||||
"id": "dynamic-agents",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Explain With AI",
|
||||
"path": "/ci/features/explain-with-ai",
|
||||
@@ -7202,6 +7250,30 @@
|
||||
}
|
||||
],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Polygraph",
|
||||
"path": "/ci/recipes/enterprise/polygraph",
|
||||
"id": "polygraph",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Metadata Only Workspaces",
|
||||
"path": "/ci/recipes/enterprise/metadata-only-workspace",
|
||||
"id": "metadata-only-workspace",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Custom Workflows",
|
||||
"path": "/ci/recipes/enterprise/custom-workflows",
|
||||
"id": "custom-workflows",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
}
|
||||
],
|
||||
"disableCollapsible": false
|
||||
@@ -7296,6 +7368,14 @@
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Credit Pricing",
|
||||
"path": "/ci/reference/credits-pricing",
|
||||
"id": "credits-pricing",
|
||||
"isExternal": false,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Release Notes",
|
||||
"path": "/ci/reference/release-notes",
|
||||
|
||||
@@ -2484,14 +2484,24 @@
|
||||
"executors": {},
|
||||
"generators": {},
|
||||
"migrations": {
|
||||
"/technologies/module-federation/api/migrations/20.5.0": {
|
||||
"/technologies/module-federation/api/migrations/21.2.0-package-updates": {
|
||||
"description": "",
|
||||
"file": "generated/packages/module-federation/migrations/20.5.0.json",
|
||||
"file": "generated/packages/module-federation/migrations/21.2.0-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "20.5.0",
|
||||
"name": "21.2.0-package-updates",
|
||||
"version": "21.2.0-beta.6",
|
||||
"originalFilePath": "/packages/module-federation",
|
||||
"path": "/technologies/module-federation/api/migrations/21.2.0-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
"/technologies/module-federation/api/migrations/20.5.0-package-updates": {
|
||||
"description": "",
|
||||
"file": "generated/packages/module-federation/migrations/20.5.0-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "20.5.0-package-updates",
|
||||
"version": "20.5.0-beta.5",
|
||||
"originalFilePath": "/packages/module-federation",
|
||||
"path": "/technologies/module-federation/api/migrations/20.5.0",
|
||||
"path": "/technologies/module-federation/api/migrations/20.5.0-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
"/technologies/module-federation/api/migrations/20.4.0-package-updates": {
|
||||
@@ -3255,6 +3265,39 @@
|
||||
"path": "/reference/core-api/nx/documents/logout",
|
||||
"tags": ["login"],
|
||||
"originalFilePath": "generated/cli/logout"
|
||||
},
|
||||
"/reference/core-api/nx/documents/fix-ci": {
|
||||
"id": "fix-ci",
|
||||
"name": "fix-ci",
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/fix-ci",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/nx/documents/fix-ci",
|
||||
"tags": ["nx-cloud", "ci"],
|
||||
"originalFilePath": "generated/cli/fix-ci"
|
||||
},
|
||||
"/reference/core-api/nx/documents/record": {
|
||||
"id": "record",
|
||||
"name": "record",
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/record",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/nx/documents/record",
|
||||
"tags": ["nx-cloud", "ci"],
|
||||
"originalFilePath": "generated/cli/record"
|
||||
},
|
||||
"/reference/core-api/nx/documents/start-ci-run": {
|
||||
"id": "start-ci-run",
|
||||
"name": "start-ci-run",
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/start-ci-run",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/nx/documents/start-ci-run",
|
||||
"tags": ["nx-cloud", "ci"],
|
||||
"originalFilePath": "generated/cli/start-ci-run"
|
||||
}
|
||||
},
|
||||
"root": "/packages/nx",
|
||||
@@ -4934,6 +4977,16 @@
|
||||
}
|
||||
},
|
||||
"migrations": {
|
||||
"/technologies/build-tools/vite/api/migrations/21.3.0-package-updates": {
|
||||
"description": "",
|
||||
"file": "generated/packages/vite/migrations/21.3.0-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "21.3.0-package-updates",
|
||||
"version": "21.3.0-beta.3",
|
||||
"originalFilePath": "/packages/vite",
|
||||
"path": "/technologies/build-tools/vite/api/migrations/21.3.0-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
"/technologies/build-tools/vite/api/migrations/21.2.0-package-updates": {
|
||||
"description": "",
|
||||
"file": "generated/packages/vite/migrations/21.2.0-package-updates.json",
|
||||
@@ -5577,6 +5630,15 @@
|
||||
"originalFilePath": "/libs/nx-packages/conformance/src/generators/create-rule/schema.json",
|
||||
"path": "/reference/core-api/conformance/generators/create-rule",
|
||||
"type": "generator"
|
||||
},
|
||||
"/reference/core-api/conformance/generators/preset": {
|
||||
"description": "Nx workspace preset which includes a working conformance rule",
|
||||
"file": "external-generated/packages/conformance/generators/preset.json",
|
||||
"hidden": false,
|
||||
"name": "preset",
|
||||
"originalFilePath": "/libs/nx-packages/conformance/src/generators/preset/schema.json",
|
||||
"path": "/reference/core-api/conformance/generators/preset",
|
||||
"type": "generator"
|
||||
}
|
||||
},
|
||||
"migrations": {},
|
||||
|
||||
@@ -413,14 +413,14 @@
|
||||
"file": "",
|
||||
"itemList": [
|
||||
{
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "",
|
||||
"id": "self-healing-ci",
|
||||
"name": "AI-Powered Self-Healing CI",
|
||||
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
|
||||
"mediaImage": "",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/ci/features/affected",
|
||||
"path": "/ci/features/self-healing-ci",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -445,6 +445,17 @@
|
||||
"path": "/ci/features/distribute-task-execution",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/ci/features/affected",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "dynamic-agents",
|
||||
"name": "Dynamically Allocate Agents",
|
||||
@@ -595,14 +606,14 @@
|
||||
"file": "",
|
||||
"itemList": [
|
||||
{
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "",
|
||||
"id": "self-healing-ci",
|
||||
"name": "AI-Powered Self-Healing CI",
|
||||
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
|
||||
"mediaImage": "",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/ci/features/affected",
|
||||
"path": "/ci/features/self-healing-ci",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -627,6 +638,17 @@
|
||||
"path": "/ci/features/distribute-task-execution",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/ci/features/affected",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
"id": "dynamic-agents",
|
||||
"name": "Dynamically Allocate Agents",
|
||||
@@ -665,15 +687,15 @@
|
||||
"path": "/features/ci-features",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/affected": {
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "",
|
||||
"/ci/features/self-healing-ci": {
|
||||
"id": "self-healing-ci",
|
||||
"name": "AI-Powered Self-Healing CI",
|
||||
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
|
||||
"mediaImage": "",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/ci/features/affected",
|
||||
"path": "/ci/features/self-healing-ci",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/remote-cache": {
|
||||
@@ -698,6 +720,17 @@
|
||||
"path": "/ci/features/distribute-task-execution",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/affected": {
|
||||
"id": "affected",
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/ci/features/affected",
|
||||
"tags": []
|
||||
},
|
||||
"/ci/features/dynamic-agents": {
|
||||
"id": "dynamic-agents",
|
||||
"name": "Dynamically Allocate Agents",
|
||||
@@ -924,8 +957,8 @@
|
||||
},
|
||||
{
|
||||
"id": "self-hosted-caching",
|
||||
"name": "Self-Host the Remote Cache",
|
||||
"description": "Host the remote cache without using Nx Cloud",
|
||||
"name": "Remote Cache",
|
||||
"description": "Different options of hosting remote cache",
|
||||
"mediaImage": "",
|
||||
"file": "shared/recipes/running-tasks/self-hosted-caching",
|
||||
"itemList": [],
|
||||
@@ -1673,8 +1706,8 @@
|
||||
},
|
||||
{
|
||||
"id": "self-hosted-caching",
|
||||
"name": "Self-Host the Remote Cache",
|
||||
"description": "Host the remote cache without using Nx Cloud",
|
||||
"name": "Remote Cache",
|
||||
"description": "Different options of hosting remote cache",
|
||||
"mediaImage": "",
|
||||
"file": "shared/recipes/running-tasks/self-hosted-caching",
|
||||
"itemList": [],
|
||||
@@ -1832,8 +1865,8 @@
|
||||
},
|
||||
"/recipes/running-tasks/self-hosted-caching": {
|
||||
"id": "self-hosted-caching",
|
||||
"name": "Self-Host the Remote Cache",
|
||||
"description": "Host the remote cache without using Nx Cloud",
|
||||
"name": "Remote Cache",
|
||||
"description": "Different options of hosting remote cache",
|
||||
"mediaImage": "",
|
||||
"file": "shared/recipes/running-tasks/self-hosted-caching",
|
||||
"itemList": [],
|
||||
|
||||
@@ -856,10 +856,10 @@
|
||||
],
|
||||
"self-hosted-caching": [
|
||||
{
|
||||
"description": "Host the remote cache without using Nx Cloud",
|
||||
"description": "Different options of hosting remote cache",
|
||||
"file": "shared/recipes/running-tasks/self-hosted-caching",
|
||||
"id": "self-hosted-caching",
|
||||
"name": "Self-Host the Remote Cache",
|
||||
"name": "Remote Cache",
|
||||
"path": "/recipes/running-tasks/self-hosted-caching"
|
||||
}
|
||||
],
|
||||
@@ -1612,6 +1612,29 @@
|
||||
"path": "/ci/recipes/enterprise/single-tenant/overview"
|
||||
}
|
||||
],
|
||||
"polygraph": [
|
||||
{
|
||||
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
|
||||
"file": "nx-cloud/enterprise/polygraph",
|
||||
"id": "polygraph",
|
||||
"name": "Polygraph",
|
||||
"path": "/ci/recipes/enterprise/polygraph"
|
||||
},
|
||||
{
|
||||
"description": "",
|
||||
"file": "nx-cloud/enterprise/metadata-only-workspace",
|
||||
"id": "metadata-only-workspace",
|
||||
"name": "Metadata Only Workspaces",
|
||||
"path": "/ci/recipes/enterprise/metadata-only-workspace"
|
||||
},
|
||||
{
|
||||
"description": "",
|
||||
"file": "nx-cloud/enterprise/custom-workflows",
|
||||
"id": "custom-workflows",
|
||||
"name": "Custom Workflows",
|
||||
"path": "/ci/recipes/enterprise/custom-workflows"
|
||||
}
|
||||
],
|
||||
"docker": [
|
||||
{
|
||||
"description": "",
|
||||
@@ -1638,5 +1661,51 @@
|
||||
"name": "affected",
|
||||
"path": "/reference/core-api/nx/documents/affected"
|
||||
}
|
||||
],
|
||||
"nx-cloud": [
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/fix-ci",
|
||||
"id": "fix-ci",
|
||||
"name": "fix-ci",
|
||||
"path": "/reference/core-api/nx/documents/fix-ci"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/record",
|
||||
"id": "record",
|
||||
"name": "record",
|
||||
"path": "/reference/core-api/nx/documents/record"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/start-ci-run",
|
||||
"id": "start-ci-run",
|
||||
"name": "start-ci-run",
|
||||
"path": "/reference/core-api/nx/documents/start-ci-run"
|
||||
}
|
||||
],
|
||||
"ci": [
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/fix-ci",
|
||||
"id": "fix-ci",
|
||||
"name": "fix-ci",
|
||||
"path": "/reference/core-api/nx/documents/fix-ci"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/record",
|
||||
"id": "record",
|
||||
"name": "record",
|
||||
"path": "/reference/core-api/nx/documents/record"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/start-ci-run",
|
||||
"id": "start-ci-run",
|
||||
"name": "start-ci-run",
|
||||
"path": "/reference/core-api/nx/documents/start-ci-run"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -2703,12 +2703,22 @@
|
||||
"migrations": [
|
||||
{
|
||||
"description": "",
|
||||
"file": "generated/packages/module-federation/migrations/20.5.0.json",
|
||||
"file": "generated/packages/module-federation/migrations/21.2.0-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "20.5.0",
|
||||
"name": "21.2.0-package-updates",
|
||||
"version": "21.2.0-beta.6",
|
||||
"originalFilePath": "/packages/module-federation",
|
||||
"path": "module-federation/migrations/21.2.0-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
{
|
||||
"description": "",
|
||||
"file": "generated/packages/module-federation/migrations/20.5.0-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "20.5.0-package-updates",
|
||||
"version": "20.5.0-beta.5",
|
||||
"originalFilePath": "/packages/module-federation",
|
||||
"path": "module-federation/migrations/20.5.0",
|
||||
"path": "module-federation/migrations/20.5.0-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
{
|
||||
@@ -3517,6 +3527,39 @@
|
||||
"path": "nx/documents/logout",
|
||||
"tags": ["login"],
|
||||
"originalFilePath": "generated/cli/logout"
|
||||
},
|
||||
{
|
||||
"id": "fix-ci",
|
||||
"name": "fix-ci",
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/fix-ci",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "nx/documents/fix-ci",
|
||||
"tags": ["nx-cloud", "ci"],
|
||||
"originalFilePath": "generated/cli/fix-ci"
|
||||
},
|
||||
{
|
||||
"id": "record",
|
||||
"name": "record",
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/record",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "nx/documents/record",
|
||||
"tags": ["nx-cloud", "ci"],
|
||||
"originalFilePath": "generated/cli/record"
|
||||
},
|
||||
{
|
||||
"id": "start-ci-run",
|
||||
"name": "start-ci-run",
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/start-ci-run",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "nx/documents/start-ci-run",
|
||||
"tags": ["nx-cloud", "ci"],
|
||||
"originalFilePath": "generated/cli/start-ci-run"
|
||||
}
|
||||
],
|
||||
"executors": [
|
||||
@@ -5302,6 +5345,16 @@
|
||||
}
|
||||
],
|
||||
"migrations": [
|
||||
{
|
||||
"description": "",
|
||||
"file": "generated/packages/vite/migrations/21.3.0-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "21.3.0-package-updates",
|
||||
"version": "21.3.0-beta.3",
|
||||
"originalFilePath": "/packages/vite",
|
||||
"path": "vite/migrations/21.3.0-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
{
|
||||
"description": "",
|
||||
"file": "generated/packages/vite/migrations/21.2.0-package-updates.json",
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
"$schema": "http://json-schema.org/draft-07/schema",
|
||||
"title": "Schema for Webpack Browser",
|
||||
"description": "Builds an Angular application using [webpack](https://webpack.js.org/).",
|
||||
"examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:browser` builder provided by the Angular CLI. It builds an Angular application using [webpack](https://webpack.js.org/).\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:webpack-browser` executor also supports the following:\n\n- Providing a custom webpack configuration\n- Incremental builds\n\n{% callout type=\"check\" title=\"Dev Server\" %}\nThe [`@nx/angular:dev-server` executor](/nx-api/angular/executors/dev-server) is required to serve your application when using the `@nx/angular:webpack-browser` to build it. It is a drop-in replacement for the Angular CLI's `@angular-devkit/build-angular:dev-server` builder and ensures the application is correctly served with Webpack when using the `@nx/angular:webpack-browser` executor.\n{% /callout %}\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Using a custom webpack configuration\" %}\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,\"8-10\"] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Incrementally Building your Application\" %}\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n{% callout type=\"note\" title=\"Performance\" %}\nThere may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.\n{% /callout %}\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,8] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"buildLibsFromSource\": false\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n{% /tabs %}\n",
|
||||
"examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:browser` builder provided by the Angular CLI. It builds an Angular application using [webpack](https://webpack.js.org/).\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:webpack-browser` executor also supports the following:\n\n- Providing a custom webpack configuration\n- Incremental builds\n\n{% callout type=\"check\" title=\"Dev Server\" %}\nThe [`@nx/angular:dev-server` executor](/nx-api/angular/executors/dev-server) is required to serve your application when using the `@nx/angular:webpack-browser` to build it. It is a drop-in replacement for the Angular CLI's `@angular-devkit/build-angular:dev-server` builder and ensures the application is correctly served with Webpack when using the `@nx/angular:webpack-browser` executor.\n{% /callout %}\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Using a custom webpack configuration\" %}\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,\"8-10\"] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Incrementally Building your Application\" %}\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n{% callout type=\"note\" title=\"Performance\" %}\nThere may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.\n{% /callout %}\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,8] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"buildLibsFromSource\": false\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Using a custom index.html transformer\" %}\n\nThe executor supports providing a custom function to transform the `index.html` file after it has been generated. This allows you to modify the HTML content before it is written to disk.\n\nTo use a custom index.html transformer, create a file with a function that exports the transformer:\n\n```javascript {% fileName=\"apps/appName/index-html-transformer.js\" %}\nmodule.exports = (target, indexHtml) => {\n // Add a custom meta tag\n const customMeta = `<meta name=\"custom-meta\" content=\"Custom value\">`;\n return indexHtml.replace('</head>', `${customMeta}\\n</head>`);\n};\n```\n\nThe transformer function receives two parameters:\n\n- `target`: The Angular build target configuration object containing properties like `project`, `target`, and `configuration`\n- `indexHtml`: The generated HTML content as a string\n\nThen update your `project.json` to use the transformer:\n\n```json {% fileName=\"project.json\" highlightLines=[5,8] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"indexHtmlTransformer\": \"apps/appName/index-html-transformer.js\"\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n{% /tabs %}\n",
|
||||
"type": "object",
|
||||
"presets": [
|
||||
{
|
||||
@@ -553,7 +553,7 @@
|
||||
"additionalProperties": false
|
||||
},
|
||||
"indexHtmlTransformer": {
|
||||
"description": "Path to transformer function to transform the index.html",
|
||||
"description": "Path to a file containing a function to transform the index.html. The function should have the signature: `(target: Target, indexHtml: string) => string`, where `target` is the build target configuration and `indexHtml` is the original HTML content.",
|
||||
"type": "string",
|
||||
"alias": "indexFileTransformer"
|
||||
},
|
||||
|
||||
@@ -140,7 +140,7 @@
|
||||
"default": true
|
||||
}
|
||||
},
|
||||
"examplesFile": "Linter can be configured in multiple ways. The basic way is to provide only `lintFilePatterns`, which is a mandatory property. This tells us where to look for files to lint.\n\n`project.json`:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Fixing linter issues\" %}\n\nLinter provides an automated way of fixing known issues. To ensure that those changes are properly cached, we need to add an `outputs` property to the `lint` target. Omitting the `outputs` property would produce an invalid cache record. Both of these properties are set by default when scaffolding a new project.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\nWith these settings, we can run the command with a `--fix` flag:\n\n```bash\nnx run frontend:lint --fix\n```\n\nWe can also set this flag via project configuration to always fix files when running lint:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"fix\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Custom output format\" %}\n\nESLint executor uses the `stylish` output format by default. You can change this by specifying the `format` property:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"format\": \"compact\"\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Silence warnings\" %}\n\nMigrated or legacy projects tend to have an overwhelming amount of lint errors. We might want to change those temporarily to be warnings so they don't block the development. But they would still clutter the report. We can run the command with `--quiet` to hide warning (errors would still break the lint):\n\n```bash\nnx run frontend:lint --quiet\n```\n\nWe can also set this via project configuration as a default option.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"quiet\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Flat Config file\" %}\n\n`ESLint` provides several ways of specifying the configuration. The default one is using `.eslintrc.json` but you can override it by setting the `eslintConfig` flag. The new `Flat Config` is now also supported:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"eslintConfig\": \"eslint.config.cjs\"\n }\n}\n```\n\n**Note:** In contrast to other configuration formats, the `Flat Config` requires that all configuration files are converted to `eslint.config.cjs`. Built-in migrations and generators support only `.eslintrc.json` at the moment.\n\n{% /tab %}\n{% /tabs %}\n\n---\n",
|
||||
"examplesFile": "Linter can be configured in multiple ways. The basic way is to provide only `lintFilePatterns`, which tells us where to look for files to lint. If not specified, it defaults to `['{projectRoot}']`.\n\n`project.json`:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Fixing linter issues\" %}\n\nLinter provides an automated way of fixing known issues. To ensure that those changes are properly cached, we need to add an `outputs` property to the `lint` target. Omitting the `outputs` property would produce an invalid cache record. Both of these properties are set by default when scaffolding a new project.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\nWith these settings, we can run the command with a `--fix` flag:\n\n```bash\nnx run frontend:lint --fix\n```\n\nWe can also set this flag via project configuration to always fix files when running lint:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"fix\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Custom output format\" %}\n\nESLint executor uses the `stylish` output format by default. You can change this by specifying the `format` property:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"format\": \"compact\"\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Silence warnings\" %}\n\nMigrated or legacy projects tend to have an overwhelming amount of lint errors. We might want to change those temporarily to be warnings so they don't block the development. But they would still clutter the report. We can run the command with `--quiet` to hide warning (errors would still break the lint):\n\n```bash\nnx run frontend:lint --quiet\n```\n\nWe can also set this via project configuration as a default option.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"quiet\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Flat Config file\" %}\n\n`ESLint` provides several ways of specifying the configuration. The default one is using `.eslintrc.json` but you can override it by setting the `eslintConfig` flag. The new `Flat Config` is now also supported:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"eslintConfig\": \"eslint.config.cjs\"\n }\n}\n```\n\n**Note:** In contrast to other configuration formats, the `Flat Config` requires that all configuration files are converted to `eslint.config.cjs`. Built-in migrations and generators support only `.eslintrc.json` at the moment.\n\n{% /tab %}\n{% /tabs %}\n\n---\n",
|
||||
"presets": []
|
||||
},
|
||||
"hasher": "./src/executors/lint/hasher",
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
{
|
||||
"name": "20.5.0-package-updates",
|
||||
"version": "20.5.0-beta.5",
|
||||
"packages": {
|
||||
"@module-federation/enhanced": {
|
||||
"version": "^0.9.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/runtime": {
|
||||
"version": "^0.9.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/sdk": {
|
||||
"version": "^0.9.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/node": {
|
||||
"version": "^2.6.26",
|
||||
"alwaysAddToPackageJson": false
|
||||
}
|
||||
},
|
||||
"aliases": [],
|
||||
"description": "",
|
||||
"hidden": false,
|
||||
"implementation": "",
|
||||
"path": "/packages/module-federation",
|
||||
"schema": null,
|
||||
"type": "migration"
|
||||
}
|
||||
@@ -1,27 +0,0 @@
|
||||
{
|
||||
"name": "20.5.0",
|
||||
"version": "20.5.0-beta.5",
|
||||
"@module-federation/enhanced": {
|
||||
"version": "^0.9.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/runtime": {
|
||||
"version": "^0.9.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/sdk": {
|
||||
"version": "^0.9.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/node": {
|
||||
"version": "^2.6.26",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"aliases": [],
|
||||
"description": "",
|
||||
"hidden": false,
|
||||
"implementation": "",
|
||||
"path": "/packages/module-federation",
|
||||
"schema": null,
|
||||
"type": "migration"
|
||||
}
|
||||
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"name": "21.2.0-package-updates",
|
||||
"version": "21.2.0-beta.6",
|
||||
"packages": {
|
||||
"@module-federation/enhanced": {
|
||||
"version": "^0.15.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/runtime": {
|
||||
"version": "^0.15.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
},
|
||||
"@module-federation/sdk": {
|
||||
"version": "^0.15.0",
|
||||
"alwaysAddToPackageJson": false
|
||||
}
|
||||
},
|
||||
"aliases": [],
|
||||
"description": "",
|
||||
"hidden": false,
|
||||
"implementation": "",
|
||||
"path": "/packages/module-federation",
|
||||
"schema": null,
|
||||
"type": "migration"
|
||||
}
|
||||
@@ -239,27 +239,32 @@ And if you generated a library with `--bundler`, then you can build a library as
|
||||
nx build my-new-lib
|
||||
```
|
||||
|
||||
After running a build, the output will be in the `{workspaceRoot}/dist/{projectRoot}` folder.
|
||||
After running a build, the output will be in the `.next` folder inside your app's project directory by default. The output directory can be changed through configuration.
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="Using inferred tasks" %}
|
||||
{% tab label="@nx/next/plugin and next.config.js" %}
|
||||
|
||||
You can customize the output folder path by update the bundler's config. For example vite's config can be updated in `vite.config.ts`:
|
||||
You can customize the output folder path by updating the Next.js config. For example, you can set a custom `distDir` in `next.config.js`:
|
||||
|
||||
```typescript {% fileName="apps/my-next-app/vite.config.ts" highlightLines=[4]%}
|
||||
import { defineConfig } from 'vite';
|
||||
export default defineConfig(() => ({
|
||||
build: {
|
||||
outDir: 'dist/my-next-app',
|
||||
},
|
||||
}));
|
||||
```javascript {% fileName="apps/my-next-app/next.config.js" highlightLines=[2]%}
|
||||
const nextConfig = {
|
||||
distDir: 'dist',
|
||||
};
|
||||
|
||||
module.exports = nextConfig;
|
||||
```
|
||||
|
||||
Note: This approach works best if you have `@nx/next/plugin` installed in your `nx.json`. You can add it with `nx add @nx/next`.
|
||||
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Using the @nx/next:build executor" %}
|
||||
|
||||
{% callout type="note" title="Legacy Configuration" %}
|
||||
This approach is for projects not using the `@nx/next/plugin` in `nx.json`. If you have the plugin configured, it will automatically infer tasks from your Next.js configuration. See the [Inferred Tasks concept page](/concepts/inferred-tasks) for more details.
|
||||
{% /callout %}
|
||||
|
||||
You can customize the output folder by setting `outputPath` in the project's `project.json` file
|
||||
|
||||
```json {% fileName="apps/my-next-app/project.json" highlightLines=[9]%}
|
||||
@@ -278,6 +283,8 @@ You can customize the output folder by setting `outputPath` in the project's `pr
|
||||
}
|
||||
```
|
||||
|
||||
Note that the `sourceRoot` property may not exist for all Next.js applications, as it depends on your project structure.
|
||||
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
@@ -106,6 +106,7 @@ Print the task graph to the console:
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
|
||||
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: 'fix-ci - CLI command'
|
||||
description: 'Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).'
|
||||
---
|
||||
|
||||
# fix-ci
|
||||
|
||||
Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).
|
||||
|
||||
## Usage
|
||||
|
||||
```shell
|
||||
nx fix-ci [options]
|
||||
```
|
||||
|
||||
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ----------- | ------- | ---------------------------------------------------------------------- |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
| Option | Type | Description |
|
||||
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--all` | boolean | Format all projects. |
|
||||
| `--base` | string | Base of the current branch (usually main). |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
|
||||
| `--head` | string | Latest commit of the current branch (usually HEAD). |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
|
||||
| `--projects` | string | Projects to format (comma/space delimited). |
|
||||
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
|
||||
| `--uncommitted` | boolean | Uncommitted changes. |
|
||||
| `--untracked` | boolean | Untracked changes. |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: 'record - CLI command'
|
||||
description: 'Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).'
|
||||
---
|
||||
|
||||
# record
|
||||
|
||||
Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).
|
||||
|
||||
## Usage
|
||||
|
||||
```shell
|
||||
nx record [options]
|
||||
```
|
||||
|
||||
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ----------- | ------- | ---------------------------------------------------------------------- |
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
@@ -110,6 +110,7 @@ Print the task graph to the console:
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
|
||||
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -83,6 +83,7 @@ Run's a target named build:test for the myapp project. Note the quotes around th
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||