Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 FrozenPandaz
|
dc470cbca0 |
+1
-4
@@ -1,8 +1,5 @@
|
||||
[env]
|
||||
JEMALLOC_SYS_WITH_MALLOC_CONF = "dirty_decay_ms:1000,muzzy_decay_ms:0"
|
||||
|
||||
[build]
|
||||
target-dir = 'dist/target'
|
||||
target-dir = 'build/target'
|
||||
|
||||
[target.x86_64-unknown-linux-musl]
|
||||
rustflags = [
|
||||
|
||||
+140
-3
@@ -1,5 +1,13 @@
|
||||
version: 2.1
|
||||
|
||||
# -------------------------
|
||||
# ORBS
|
||||
# -------------------------
|
||||
orbs:
|
||||
nx: nrwl/nx@1.6.2
|
||||
rust: circleci/rust@1.6.0
|
||||
browser-tools: circleci/browser-tools@1.4.8
|
||||
|
||||
# -------------------------
|
||||
# EXECUTORS
|
||||
# -------------------------
|
||||
@@ -11,9 +19,56 @@ executors:
|
||||
linux:
|
||||
<<: *defaults
|
||||
docker:
|
||||
- image: cimg/rust:1.84.0-browsers
|
||||
resource_class: small
|
||||
- image: cimg/rust:1.73.0-browsers
|
||||
resource_class: medium+
|
||||
|
||||
macos:
|
||||
<<: *defaults
|
||||
resource_class: macos.m1.medium.gen1
|
||||
macos:
|
||||
xcode: '14.2.0'
|
||||
|
||||
# -------------------------
|
||||
# COMMANDS
|
||||
# -------------------------
|
||||
commands:
|
||||
run-pnpm-install:
|
||||
parameters:
|
||||
os:
|
||||
type: string
|
||||
steps:
|
||||
- restore_cache:
|
||||
name: Restore pnpm Package Cache
|
||||
keys:
|
||||
- node-deps-{{ arch }}-v3-{{ checksum "pnpm-lock.yaml" }}
|
||||
- when:
|
||||
condition:
|
||||
equal: [<< parameters.os >>, linux]
|
||||
steps:
|
||||
- run:
|
||||
name: Install pnpm package manager (linux)
|
||||
command: |
|
||||
npm install --prefix=$HOME/.local -g @pnpm/exe@8
|
||||
- when:
|
||||
condition:
|
||||
equal: [<< parameters.os >>, macos]
|
||||
steps:
|
||||
- run:
|
||||
name: Install pnpm package manager (macos)
|
||||
command: |
|
||||
npm install -g @pnpm/exe@8
|
||||
- run:
|
||||
name: Install Dependencies
|
||||
command: |
|
||||
pnpm install --frozen-lockfile
|
||||
pnpm playwright install --with-deps
|
||||
- save_cache:
|
||||
name: Save pnpm Package Cache
|
||||
key: node-deps-{{ arch }}-v3-{{ checksum "pnpm-lock.yaml" }}
|
||||
paths:
|
||||
- ~/.pnpm-store
|
||||
- ~/.cache/Cypress
|
||||
- node_modules
|
||||
# -------------------------
|
||||
# JOBS
|
||||
# -------------------------
|
||||
@@ -23,8 +78,88 @@ jobs:
|
||||
# -------------------------
|
||||
main-linux:
|
||||
executor: linux
|
||||
environment:
|
||||
NX_E2E_CI_CACHE_KEY: e2e-circleci-linux
|
||||
NX_DAEMON: 'true'
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_NATIVE_LOGGING: 'false'
|
||||
NX_E2E_RUN_E2E: 'true'
|
||||
NX_CI_EXECUTION_ENV: 'linux'
|
||||
NX_CLOUD_DTE_V2: 'true'
|
||||
steps:
|
||||
- run: echo "We are in the process of transitioning from Circle CI to GitHub Actions. For details about your build results, consult github actions build logs."
|
||||
- checkout
|
||||
- nx/set-shas:
|
||||
main-branch-name: 'master'
|
||||
- run: npx nx-cloud@next start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yaml" --stop-agents-after="e2e"
|
||||
- run:
|
||||
command: |
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y ca-certificates lsof libvips-dev libglib2.0-dev libgirepository1.0-dev
|
||||
- browser-tools/install-chrome
|
||||
- run-pnpm-install:
|
||||
os: linux
|
||||
- run:
|
||||
name: Check Documentation
|
||||
command: pnpm nx documentation --no-dte
|
||||
no_output_timeout: 20m
|
||||
- run:
|
||||
name: Run Checks/Lint/Test/Build
|
||||
no_output_timeout: 60m
|
||||
command: |
|
||||
pids=()
|
||||
|
||||
pnpm nx-cloud record -- nx format:check --base=$NX_BASE --head=$NX_HEAD &
|
||||
pids+=($!)
|
||||
|
||||
pnpm nx run-many -t check-imports check-commit check-lock-files check-codeowners documentation --parallel=1 --no-dte &
|
||||
pids+=($!)
|
||||
|
||||
(pnpm nx affected --targets=lint,test,build --base=$NX_BASE --head=$NX_HEAD --parallel=3 &&
|
||||
pnpm nx affected --targets=e2e,e2e-ci --base=$NX_BASE --head=$NX_HEAD --parallel=1) &
|
||||
pids+=($!)
|
||||
|
||||
for pid in "${pids[@]}"; do
|
||||
wait "$pid"
|
||||
done
|
||||
# -------------------------
|
||||
# JOBS: Main-MacOS
|
||||
# -------------------------
|
||||
mainmacos:
|
||||
executor: macos
|
||||
environment:
|
||||
NX_E2E_CI_CACHE_KEY: e2e-circleci-macos
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_CI_EXECUTION_ENV: 'macos'
|
||||
SELECTED_PM: 'npm' # explicitly define npm for macOS tests
|
||||
steps:
|
||||
- checkout
|
||||
- restore_cache:
|
||||
name: Restore Homebrew packages
|
||||
keys:
|
||||
- nrwl-nx-homebrew-packages
|
||||
- run:
|
||||
name: Configure Detox Environment, Install applesimutils
|
||||
command: |
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew tap wix/brew >/dev/null
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew install applesimutils >/dev/null
|
||||
xcrun simctl shutdown all && xcrun simctl erase all
|
||||
no_output_timeout: 20m
|
||||
- save_cache:
|
||||
name: Save Homebrew Cache
|
||||
key: nrwl-nx-homebrew-packages
|
||||
paths:
|
||||
- /usr/local/Homebrew
|
||||
- ~/Library/Caches/Homebrew
|
||||
- run-pnpm-install:
|
||||
os: macos
|
||||
- rust/install
|
||||
- nx/set-shas:
|
||||
main-branch-name: 'master'
|
||||
- run:
|
||||
name: Run E2E Tests for macOS
|
||||
command: |
|
||||
pnpm nx affected -t e2e-macos-ci --parallel=1 --base=$NX_BASE --head=$NX_HEAD
|
||||
no_output_timeout: 45m
|
||||
|
||||
# -------------------------
|
||||
# WORKFLOWS(JOBS)
|
||||
@@ -35,3 +170,5 @@ workflows:
|
||||
build:
|
||||
jobs:
|
||||
- main-linux
|
||||
- mainmacos:
|
||||
name: main-macos-e2e
|
||||
|
||||
@@ -1,47 +0,0 @@
|
||||
# Commit Command
|
||||
|
||||
## Description
|
||||
|
||||
Create a git commit following Nx repository standards and validation requirements.
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/commit [message]
|
||||
```
|
||||
|
||||
## What this command does:
|
||||
|
||||
1. **Pre-commit validation**: Runs the full validation suite (`pnpm nx prepush`) to ensure code quality
|
||||
2. **Formatting**: Automatically formats changed files with Prettier
|
||||
3. **Testing**: Runs tests on affected projects to validate changes
|
||||
4. **Commit creation**: Creates a well-formed commit with proper message formatting (without co-author attribution)
|
||||
5. **Status reporting**: Provides clear feedback on the commit process
|
||||
|
||||
## Workflow:
|
||||
|
||||
1. Format any modified files with Prettier
|
||||
2. Run the prepush validation suite
|
||||
3. If validation passes, stage relevant changes
|
||||
4. Create commit with descriptive message
|
||||
5. Provide summary of what was committed
|
||||
|
||||
## Commit Message Format:
|
||||
|
||||
- Use conventional commit format when appropriate
|
||||
- Include scope (e.g., `feat(core):`, `fix(angular):`, `docs(nx):`)
|
||||
- Keep first line under 72 characters
|
||||
- Include detailed description if needed
|
||||
|
||||
## Examples:
|
||||
|
||||
- `/commit "feat(core): add new project graph visualization"`
|
||||
- `/commit "fix(react): resolve build issues with webpack config"`
|
||||
- `/commit "docs(nx): update getting started guide"`
|
||||
|
||||
## Validation Requirements:
|
||||
|
||||
- All tests must pass
|
||||
- Code must be properly formatted
|
||||
- No linting errors
|
||||
- E2E tests for affected areas should pass
|
||||
@@ -1,155 +0,0 @@
|
||||
# GitHub Issue Planning and Resolution
|
||||
|
||||
This command provides guidance for both automated and manual GitHub issue workflows.
|
||||
|
||||
## Automated Workflow (GitHub Actions)
|
||||
|
||||
The automated workflow consists of two phases:
|
||||
|
||||
### Phase 1: Planning (`@claude plan` or `claude:plan` label)
|
||||
|
||||
- Claude analyzes the issue and creates a detailed implementation plan
|
||||
- Plan is posted as a comment on the issue
|
||||
- Issue is labeled with `claude:planned`
|
||||
|
||||
### Phase 2: Implementation (`@claude implement` or `claude:implement` label)
|
||||
|
||||
- Claude implements the solution based on the plan
|
||||
- Runs validation tests and creates a feature branch
|
||||
- Suggests opening a PR with proper formatting
|
||||
|
||||
## Planning Phase Template
|
||||
|
||||
When creating a plan (either automated or manual), include these sections:
|
||||
|
||||
### Problem Analysis
|
||||
|
||||
- Root cause identification
|
||||
- Impact assessment
|
||||
- Related components or systems affected
|
||||
|
||||
### Proposed Solution
|
||||
|
||||
- High-level approach
|
||||
- Alternative solutions considered
|
||||
- Trade-offs and rationale
|
||||
|
||||
### Implementation Details
|
||||
|
||||
- Files that need to be modified
|
||||
- Key changes required
|
||||
- Dependencies or prerequisites
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
- Unit tests to add/modify
|
||||
- Integration tests needed
|
||||
- E2E test considerations
|
||||
|
||||
### Validation Steps
|
||||
|
||||
```bash
|
||||
# Test specific affected projects
|
||||
nx run-many -t test,build,lint -p PROJECT_NAME
|
||||
|
||||
# Test all affected projects
|
||||
nx affected -t build,test,lint
|
||||
|
||||
# Run affected e2e tests
|
||||
nx affected -t e2e-local
|
||||
|
||||
# Format code
|
||||
npx nx prettier -- FILES
|
||||
|
||||
# Final validation
|
||||
pnpm nx prepush
|
||||
```
|
||||
|
||||
### Risks and Considerations
|
||||
|
||||
- Breaking changes
|
||||
- Performance implications
|
||||
- Migration requirements
|
||||
|
||||
## Manual Workflow
|
||||
|
||||
When working on a GitHub issue manually, follow this systematic approach:
|
||||
|
||||
## 1. Get Issue Details
|
||||
|
||||
```bash
|
||||
# Get issue details using GitHub CLI (replace ISSUE_NUMBER with actual number)
|
||||
gh issue view ISSUE_NUMBER
|
||||
```
|
||||
|
||||
When cloning reproduction repos, please clone within `./tmp/claude/repro-ISSUE_NUMBER`
|
||||
|
||||
## 2. Analyze the Plan
|
||||
|
||||
- Look for a plan or implementation details in the issue description
|
||||
- Check comments for additional context or clarification
|
||||
- Identify affected projects and components
|
||||
|
||||
## 3. Implement the Solution
|
||||
|
||||
- Follow the plan outlined in the issue
|
||||
- Make focused changes that address the specific problem
|
||||
- Ensure code follows existing patterns and conventions
|
||||
|
||||
## 4. Run Full Validation
|
||||
|
||||
```bash
|
||||
# Test specific affected projects first
|
||||
nx run-many -t test,build,lint -p PROJECT_NAME
|
||||
|
||||
# Test all affected projects
|
||||
nx affected -t build,test,lint
|
||||
|
||||
# Run affected e2e tests
|
||||
nx affected -t e2e-local
|
||||
|
||||
# Final pre-push validation
|
||||
pnpm nx prepush
|
||||
```
|
||||
|
||||
## 5. Submit Pull Request
|
||||
|
||||
- Create a descriptive PR title that references the issue
|
||||
- Include "Fixes #ISSUE_NUMBER" in the PR description
|
||||
- Provide a clear summary of changes made
|
||||
- Request appropriate reviewers
|
||||
|
||||
## Pull Request Template
|
||||
|
||||
When creating a pull request, follow the template found in `.github/PULL_REQUEST_TEMPLATE.md`. The template includes:
|
||||
|
||||
### Required Sections
|
||||
|
||||
1. **Current Behavior**: Describe the behavior we have today
|
||||
2. **Expected Behavior**: Describe the behavior we should expect with the changes in this PR
|
||||
3. **Related Issue(s)**: Link the issue being fixed so it gets closed when the PR is merged
|
||||
|
||||
### Template Format
|
||||
|
||||
```markdown
|
||||
## Current Behavior
|
||||
|
||||
<!-- This is the behavior we have today -->
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
<!-- This is the behavior we should expect with the changes in this PR -->
|
||||
|
||||
## Related Issue(s)
|
||||
|
||||
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
|
||||
|
||||
Fixes #ISSUE_NUMBER
|
||||
```
|
||||
|
||||
### Guidelines
|
||||
|
||||
- Ensure your commit message follows the conventional commit format (use `pnpm commit`)
|
||||
- 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
|
||||
@@ -1,30 +0,0 @@
|
||||
# Claude Issue Workflow Usage Guide
|
||||
|
||||
## Quick Start
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
### Planning Phase
|
||||
|
||||
- Detailed analysis comment posted to issue
|
||||
- Implementation plan with steps and file changes
|
||||
- Testing strategy and validation steps
|
||||
- Risk assessment
|
||||
|
||||
### Implementation Phase
|
||||
|
||||
- Code changes made according to plan
|
||||
- Tests run and validated
|
||||
- Feature branch created: `fix/issue-{number}`
|
||||
- PR suggestion with proper title format
|
||||
|
||||
## Manual Override
|
||||
|
||||
If you need to work on an issue manually, use the `/gh-issue-plan` command for structured guidance following the same workflow patterns.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- Ensure you're on the authorized users list
|
||||
- Check that the issue has sufficient detail for analysis
|
||||
- For implementation, ensure a plan comment exists from the planning phase
|
||||
- If workflows fail, check the Actions tab for detailed logs
|
||||
@@ -1,48 +0,0 @@
|
||||
{
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(find:*)",
|
||||
"Bash(ls:*)",
|
||||
"Bash(mkdir:*)",
|
||||
"WebFetch(domain:github.com)",
|
||||
"WebFetch(domain:www.typescriptlang.org)",
|
||||
"Bash(git log:*)",
|
||||
"Bash(gh issue list:*)",
|
||||
"Bash(gh issue view:*)",
|
||||
"Bash(npx prettier:*)",
|
||||
"Bash(nx prepush:*)",
|
||||
"Bash(pnpm commit:*)",
|
||||
"Bash(rg:*)",
|
||||
"mcp__nx__nx_docs",
|
||||
"mcp__nx__nx_workspace",
|
||||
"mcp__nx__nx_project_details",
|
||||
"Bash(nx show projects:*)",
|
||||
"Bash(nx run-many:*)",
|
||||
"Bash(nx run:*)",
|
||||
"Bash(nx affected:*)",
|
||||
"Bash(nx lint:*)",
|
||||
"Bash(nx test:*)",
|
||||
"Bash(nx build:*)",
|
||||
"Bash(nx documentation:*)"
|
||||
],
|
||||
"deny": []
|
||||
},
|
||||
"enableAllProjectMcpServers": true,
|
||||
"env": {
|
||||
"BASH_MAX_TIMEOUT_MS": "1800000"
|
||||
},
|
||||
"extraKnownMarketplaces": {
|
||||
"nx-claude-plugins": {
|
||||
"source": {
|
||||
"source": "github",
|
||||
"repo": "nrwl/nx-ai-agents-config",
|
||||
"ref": "experimental"
|
||||
}
|
||||
}
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"nx@nx-claude-plugins": true,
|
||||
"polygraph@nx-claude-plugins": true
|
||||
},
|
||||
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": true
|
||||
}
|
||||
@@ -1,100 +0,0 @@
|
||||
---
|
||||
name: nx-docs-style-check
|
||||
description: Check modified Nx documentation pages against the astro-docs style guide. Auto-trigger after writing or editing docs content in the nx repo. Also trigger on "check style", "style guide", "docs review", "validate docs". Should run as a final step whenever docs files are modified. IMPORTANT: anytime astro-docs/**/*.mdoc files are modified, this should always run automatically without being asked.
|
||||
allowed-tools: Read, Glob, Grep
|
||||
---
|
||||
|
||||
# Nx docs style check
|
||||
|
||||
You are a documentation editor for Nx. Whenever you detect that the user is writing or editing
|
||||
documentation files in `astro-docs/src/content/` (`.mdoc`, `.mdx`, `.md`), automatically run this
|
||||
check and fix any issues. Do not wait to be asked.
|
||||
|
||||
## Phase 1: Information architecture audit
|
||||
|
||||
Read `astro-docs/STYLE_GUIDE.md` (the "Information architecture" section) and
|
||||
`astro-docs/sidebar.mts` to understand where the page lives in the sidebar hierarchy.
|
||||
|
||||
For every new or moved page, evaluate against ALL FIVE principles. These are non-negotiable:
|
||||
|
||||
### 1. Progressive disclosure ("journey" rule)
|
||||
|
||||
- Is this for the first 30 minutes (Getting Started), first 30 days (Features), or forever (Reference)?
|
||||
- Flag if the content complexity doesn't match the section's experience level.
|
||||
|
||||
### 2. Category homogeneity ("scan" rule)
|
||||
|
||||
- Look at sibling pages in the same sidebar section.
|
||||
- Do they all share the same content type (concepts, tasks, or products)?
|
||||
- Flag if this page mixes types that siblings don't.
|
||||
|
||||
### 3. Type-based navigation ("intent" rule)
|
||||
|
||||
- Is this a learning page (narrative/guide) or a lookup page (reference/API)?
|
||||
- Flag if it's in the wrong category (e.g., a reference page in a guides section).
|
||||
|
||||
### 4. Pen and paper test ("theory" rule)
|
||||
|
||||
- Can the page be explained using only pen and paper (no terminal needed)?
|
||||
- YES = belongs in "How Nx Works" (architecture/concepts)
|
||||
- NO (needs terminal/code examples) = belongs in "Platform Features" or "Technologies"
|
||||
- Flag if a concept page has terminal output, CLI commands, or code-heavy examples.
|
||||
|
||||
### 5. Universal vs. specific ("placement" rule)
|
||||
|
||||
- Does this feature apply to every Nx user?
|
||||
- YES = "Platform Features"
|
||||
- NO (only React/Angular/etc. users) = "Technologies"
|
||||
- Flag if a technology-specific page is in Platform Features or vice versa.
|
||||
|
||||
## Phase 2: Style validation
|
||||
|
||||
### Step 1: Run Vale and fix errors
|
||||
|
||||
Run `nx run astro-docs:vale` to check the modified files.
|
||||
|
||||
- **errors** — fix these automatically. Edit the file to resolve the violation.
|
||||
- **warnings** — fix these automatically when the fix is unambiguous (e.g., sentence case headings).
|
||||
For ambiguous cases, suggest the fix and ask.
|
||||
- **suggestions** — mention them to the user but do not auto-fix.
|
||||
|
||||
### Step 2: Fix issues Vale doesn't catch
|
||||
|
||||
Read `astro-docs/STYLE_GUIDE.md` and check for that things that Vale may have missed.
|
||||
|
||||
### Handling false positives
|
||||
|
||||
Use inline Vale comments to suppress legitimate exceptions:
|
||||
|
||||
```markdown
|
||||
<!-- vale Nx.Headings = NO -->
|
||||
|
||||
## extractLicenses
|
||||
|
||||
<!-- vale Nx.Headings = YES -->
|
||||
```
|
||||
|
||||
Common cases where suppression is appropriate:
|
||||
|
||||
- **CLI option headings** (e.g., `## extractLicenses`) — camelCase by design.
|
||||
Prefer wrapping in backticks first (`## \`extractLicenses\``).
|
||||
- **Product possessives in historical/migration context** (e.g., "Angular's original schematic system")
|
||||
- **Terminology in migration docs** (e.g., explaining what "schematics" were before being renamed)
|
||||
|
||||
Do NOT suppress rules just to avoid fixing real violations.
|
||||
|
||||
## Output summary
|
||||
|
||||
After fixing, report what you did:
|
||||
|
||||
```
|
||||
## Style check results
|
||||
|
||||
### Information architecture: [PASS/FAIL]
|
||||
[List any violations or confirm all five principles pass]
|
||||
|
||||
### Vale: [X errors fixed, Y warnings fixed, Z suggestions noted]
|
||||
[Summary of changes made]
|
||||
|
||||
### Manual fixes: [list of additional fixes applied]
|
||||
```
|
||||
@@ -1,151 +0,0 @@
|
||||
---
|
||||
name: nx-gradle-plugin-version-bump
|
||||
description: Bump the dev.nx.gradle.project-graph plugin version. Use when updating the Gradle project graph plugin version across the codebase, creating the migration files, and updating migrations.json.
|
||||
allowed-tools: Bash, Read, Write, Edit, Glob, Grep
|
||||
---
|
||||
|
||||
# Gradle Plugin Version Bump
|
||||
|
||||
Bumps the `dev.nx.gradle.project-graph` plugin to a new version. This is a recurring task that touches 5 files in an identical pattern every time.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Collect these values from the master branch before starting:
|
||||
|
||||
1. `NEW_VERSION` - the version we want to bump to
|
||||
Example: OLD_VERSION: 0.1.15 => NEW_VERSION: 0.1.16
|
||||
You can find this value by looking at the `OLD_VERSION` specified in `packages/gradle/project-graph/build.gradle.kts` in the `version` field.
|
||||
The NEW_VERSION will be the `OLD_VERSION` + 1.
|
||||
|
||||
2. `NX_MIGRATION_VERSION` - the version of Nx that will trigger our version bump migration
|
||||
Example: OLD_VERSION: 22.7.0-beta.0 => NEW_VERSION: 22.7.0-beta.1
|
||||
You can find this value by looking at the `nx` version in `package.json` under `devDependencies`. The NEW_VERSION will be the `OLD_VERSION` + 1.
|
||||
|
||||
3. `MIGRATION_FOLDER` - the folder name under `packages/gradle/src/migrations/` that will contain our migration files
|
||||
Example: NEW_VERSION: 22.7.0-beta.1 => MIGRATION_FOLDER: 22-7-0
|
||||
Take the version and replace all the dots with hyphens and remove the `beta` or `rc` suffix.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Update the version constant
|
||||
|
||||
**File:** `packages/gradle/src/utils/versions.ts`
|
||||
|
||||
Change `gradleProjectGraphVersion` to the new version:
|
||||
|
||||
```ts
|
||||
export const gradleProjectGraphVersion = 'NEW_VERSION';
|
||||
```
|
||||
|
||||
### 2. Update build.gradle.kts
|
||||
|
||||
**File:** `packages/gradle/project-graph/build.gradle.kts`
|
||||
|
||||
Update the `version` on line 13:
|
||||
|
||||
```kotlin
|
||||
version = "NEW_VERSION"
|
||||
```
|
||||
|
||||
### 3. Create migration TypeScript file
|
||||
|
||||
**File:** `packages/gradle/src/migrations/MIGRATION_FOLDER/change-plugin-version-NEW_VERSION.ts`
|
||||
|
||||
Determine the previous version by reading the current `gradleProjectGraphVersion` from `packages/gradle/src/utils/versions.ts` before modifying it.
|
||||
|
||||
Template:
|
||||
|
||||
```ts
|
||||
import { Tree, readNxJson } from '@nx/devkit';
|
||||
import { hasGradlePlugin } from '../../utils/has-gradle-plugin';
|
||||
import { addNxProjectGraphPlugin } from '../../generators/init/gradle-project-graph-plugin-utils';
|
||||
import { updateNxPluginVersionInCatalogsAst } from '../../utils/version-catalog-ast-utils';
|
||||
|
||||
/* Change the plugin version to NEW_VERSION
|
||||
*/
|
||||
export default async function update(tree: Tree) {
|
||||
const nxJson = readNxJson(tree);
|
||||
if (!nxJson) {
|
||||
return;
|
||||
}
|
||||
if (!hasGradlePlugin(tree)) {
|
||||
return;
|
||||
}
|
||||
|
||||
const gradlePluginVersionToUpdate = 'NEW_VERSION';
|
||||
|
||||
// Update version in version catalogs using AST-based approach to preserve formatting
|
||||
await updateNxPluginVersionInCatalogsAst(tree, gradlePluginVersionToUpdate);
|
||||
|
||||
// Then update in build.gradle(.kts) files
|
||||
await addNxProjectGraphPlugin(tree, gradlePluginVersionToUpdate);
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Create migration documentation file
|
||||
|
||||
**File:** `packages/gradle/src/migrations/MIGRATION_FOLDER/change-plugin-version-NEW_VERSION.md`
|
||||
|
||||
Replace `PREV_VERSION` with the version that was current before this bump.
|
||||
|
||||
Template:
|
||||
|
||||
````md
|
||||
#### Change dev.nx.gradle.project-graph to version NEW_VERSION
|
||||
|
||||
Change dev.nx.gradle.project-graph to version NEW_VERSION in build file
|
||||
|
||||
#### Sample Code Changes
|
||||
|
||||
##### Before
|
||||
|
||||
\```text title="build.gradle"
|
||||
plugins {
|
||||
id "dev.nx.gradle.project-graph" version "PREV_VERSION"
|
||||
}
|
||||
\```
|
||||
|
||||
##### After
|
||||
|
||||
\```text title="build.gradle"
|
||||
plugins {
|
||||
id "dev.nx.gradle.project-graph" version "NEW_VERSION"
|
||||
}
|
||||
\```
|
||||
````
|
||||
|
||||
### 5. Add migration entry to migrations.json
|
||||
|
||||
**File:** `packages/gradle/migrations.json`
|
||||
|
||||
Add a new entry at the end of the `generators` object (before the closing `}`), following the existing pattern:
|
||||
|
||||
```json
|
||||
"change-plugin-version-NEW_VERSION": {
|
||||
"version": "NX_MIGRATION_VERSION",
|
||||
"cli": "nx",
|
||||
"description": "Change dev.nx.gradle.project-graph to version NEW_VERSION in build file",
|
||||
"factory": "./src/migrations/MIGRATION_FOLDER/change-plugin-version-NEW_VERSION"
|
||||
}
|
||||
```
|
||||
|
||||
The migration key uses the version with hyphens replacing dots (e.g., `0-1-16`).
|
||||
|
||||
## Verification
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
nx run-many -t test,build,lint -p gradle
|
||||
```
|
||||
|
||||
## Commit Convention
|
||||
|
||||
```
|
||||
chore(gradle): bump gradle project graph plugin version to NEW_VERSION
|
||||
```
|
||||
|
||||
## Final Verification
|
||||
|
||||
Take a look at the most recent Gradle version bump PR and compare your changes to that. You should not be touching more or less files than
|
||||
the most recent version bump PR. If you do, ask for more information and stop all changes.
|
||||
@@ -1,87 +0,0 @@
|
||||
---
|
||||
name: run-nx-generator
|
||||
description: Run Nx generators with prioritization for workspace-plugin generators. Use this when generating code, scaffolding new features, or automating repetitive tasks in the monorepo.
|
||||
allowed-tools: Bash, Read, Glob, Grep, mcp__nx-mcp__nx_generators, mcp__nx-mcp__nx_generator_schema
|
||||
---
|
||||
|
||||
# Run Nx Generator
|
||||
|
||||
This skill helps you execute Nx generators efficiently, with special focus on workspace-plugin generators from your internal tooling.
|
||||
|
||||
## Generator Priority List
|
||||
|
||||
Use the `mcp__nx-mcp__nx_generator_schema` tool to get more information about how to use the generator
|
||||
|
||||
Choose which generators to run in this priority order:
|
||||
|
||||
### 🔥 Workspace-Plugin Generators (High Priority)
|
||||
|
||||
These are your custom internal tools in `tools/workspace-plugin/`
|
||||
|
||||
### 📦 Core Nx Generators (Standard)
|
||||
|
||||
Only use these if workspace-plugin generators don't fit:
|
||||
|
||||
- `nx generate @nx/devkit:...` - DevKit utilities
|
||||
- `nx generate @nx/node:...` - Node.js libraries
|
||||
- `nx generate @nx/react:...` - React components and apps
|
||||
- Framework-specific generators
|
||||
|
||||
## How to Run Generators
|
||||
|
||||
1. **List available generators**:
|
||||
|
||||
2. **Get generator schema** (to see available options):
|
||||
Use the `mcp__nx-mcp__nx_generator_schema` tool to get more information about how to use the generator
|
||||
|
||||
3. **Run the generator**:
|
||||
|
||||
```bash
|
||||
nx generate [generator-path] [options]
|
||||
```
|
||||
|
||||
4. **Verify the changes**:
|
||||
- Review generated files
|
||||
- Run tests: `nx affected -t test`
|
||||
- Format code: `npx prettier --write [files]`
|
||||
|
||||
## Best Practices
|
||||
|
||||
- ✅ Always check workspace-plugin first - it has your custom solutions
|
||||
- ✅ Use `--dry-run` flag to preview changes before applying
|
||||
- ✅ Format generated code immediately with Prettier
|
||||
- ✅ Test affected projects after generation
|
||||
- ✅ Commit generator changes separately from manual edits
|
||||
|
||||
## Examples
|
||||
|
||||
### Bumping Maven Version
|
||||
|
||||
When updating the Maven plugin version, use the workspace-plugin generator:
|
||||
|
||||
```bash
|
||||
nx generate @nx/workspace-plugin:bump-maven-version \
|
||||
--newVersion 0.0.10 \
|
||||
--nxVersion 22.1.0-beta.7
|
||||
```
|
||||
|
||||
This automates all the version bumping instead of manual file edits.
|
||||
|
||||
### Creating a New Plugin
|
||||
|
||||
For creating a new create-nodes plugin:
|
||||
|
||||
```bash
|
||||
nx generate @nx/workspace-plugin:create-nodes-plugin \
|
||||
--name my-custom-plugin
|
||||
```
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
|
||||
- Generate new code or projects
|
||||
- Scaffold new features or libraries
|
||||
- Automate repetitive setup tasks
|
||||
- Update internal tools and configurations
|
||||
- Create migrations or version updates
|
||||
@@ -1,480 +0,0 @@
|
||||
---
|
||||
name: ci-watcher
|
||||
description: Polls Nx Cloud CI pipeline and self-healing status. Returns structured state when actionable. Spawned by /nx-cloud-ci-monitor command to monitor CI Attempt status.
|
||||
model: fast
|
||||
---
|
||||
|
||||
# CI Watcher Subagent
|
||||
|
||||
You are a CI monitoring subagent responsible for polling Nx Cloud CI Attempt status and self-healing state. You report status back to the main agent - you do NOT make apply/reject decisions.
|
||||
|
||||
## Your Responsibilities
|
||||
|
||||
1. Poll CI status using the `ci_information` MCP tool
|
||||
2. Implement exponential backoff between polls
|
||||
3. Return structured state when an actionable condition is reached
|
||||
4. Track iteration count and elapsed time
|
||||
5. Output status updates based on verbosity level
|
||||
|
||||
## Input Parameters (from Main Agent)
|
||||
|
||||
The main agent may provide these optional parameters in the prompt:
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------- | -------------------------------------------------------- |
|
||||
| `branch` | Branch to monitor (auto-detected if not provided) |
|
||||
| `expectedCommitSha` | Commit SHA that should trigger a new CI Attempt |
|
||||
| `previousCipeUrl` | CI Attempt URL before the action (to detect change) |
|
||||
| `subagentTimeout` | Polling timeout in minutes (default: 60) |
|
||||
| `verbosity` | Output level: minimal, medium, verbose (default: medium) |
|
||||
|
||||
When `expectedCommitSha` or `previousCipeUrl` is provided, you must detect whether a new CI Attempt has spawned.
|
||||
|
||||
## MCP Tool Reference
|
||||
|
||||
### `ci_information`
|
||||
|
||||
**Input:**
|
||||
|
||||
```json
|
||||
{
|
||||
"branch": "string (optional, defaults to current git branch)",
|
||||
"select": "string (optional, comma-separated field names)",
|
||||
"pageToken": "number (optional, 0-based pagination for long strings)"
|
||||
}
|
||||
```
|
||||
|
||||
**Output:**
|
||||
|
||||
```json
|
||||
{
|
||||
"cipeStatus": "NOT_STARTED | IN_PROGRESS | SUCCEEDED | FAILED | CANCELED | TIMED_OUT",
|
||||
"cipeUrl": "string",
|
||||
"branch": "string",
|
||||
"commitSha": "string | null",
|
||||
"failedTaskIds": "string[]",
|
||||
"verifiedTaskIds": "string[]",
|
||||
"selfHealingEnabled": "boolean",
|
||||
"selfHealingStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
|
||||
"verificationStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
|
||||
"userAction": "NONE | APPLIED | REJECTED | APPLIED_LOCALLY | APPLIED_AUTOMATICALLY | null",
|
||||
"failureClassification": "string | null",
|
||||
"taskOutputSummary": "string | null",
|
||||
"suggestedFixReasoning": "string | null",
|
||||
"suggestedFixDescription": "string | null",
|
||||
"suggestedFix": "string | null",
|
||||
"shortLink": "string | null",
|
||||
"couldAutoApplyTasks": "boolean | null",
|
||||
"confidence": "number | null",
|
||||
"confidenceReasoning": "string | null"
|
||||
}
|
||||
```
|
||||
|
||||
**Select Parameter:**
|
||||
|
||||
| Usage | Returns |
|
||||
| --------------- | ----------------------------------------------------------- |
|
||||
| No `select` | Formatted overview (truncated, not recommended for polling) |
|
||||
| Single field | Raw value with pagination for long strings |
|
||||
| Multiple fields | Object with requested field values |
|
||||
|
||||
**Field Sets for Efficient Polling:**
|
||||
|
||||
```yaml
|
||||
WAIT_FIELDS:
|
||||
'cipeUrl,commitSha,cipeStatus'
|
||||
# Minimal fields for detecting new CI Attempt
|
||||
|
||||
LIGHT_FIELDS:
|
||||
'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning'
|
||||
# Status fields for determining actionable state
|
||||
|
||||
HEAVY_FIELDS:
|
||||
'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'
|
||||
# Large content fields - fetch only when returning to main agent
|
||||
```
|
||||
|
||||
## Initial Wait
|
||||
|
||||
Before first poll, wait based on context:
|
||||
|
||||
- **Fresh start (no expected CIPE):** Wait 60 seconds to allow CI to start
|
||||
- **Expecting new CIPE:** Wait 30 seconds (action already triggered)
|
||||
|
||||
**IMPORTANT:** Always run sleep in foreground, NOT as background command.
|
||||
|
||||
```bash
|
||||
sleep 60 # or 30 if expecting new CIPE (FOREGROUND, not background)
|
||||
```
|
||||
|
||||
## Two-Phase Operation
|
||||
|
||||
The subagent operates in one of two modes depending on input:
|
||||
|
||||
### Mode 1: Fresh Start (no `expectedCommitSha` or `previousCipeUrl`)
|
||||
|
||||
Normal polling - process whatever CIPE is returned by `ci_information`.
|
||||
|
||||
### Mode 2: Wait-for-New-CIPE (when `expectedCommitSha` or `previousCipeUrl` provided)
|
||||
|
||||
**CRITICAL**: When expecting a new CIPE, the subagent must **completely ignore** the old/stale CIPE. Do NOT process its status, do NOT return actionable states based on it.
|
||||
|
||||
#### Phase A: Wait Mode
|
||||
|
||||
1. Start a **new-CIPE timeout** timer (default: 30 minutes)
|
||||
2. On each poll of `ci_information`:
|
||||
- Check if CIPE is NEW:
|
||||
- `cipeUrl` differs from `previousCipeUrl` → **new CIPE detected**
|
||||
- `commitSha` matches `expectedCommitSha` → **correct CIPE detected**
|
||||
- If still OLD CIPE: **ignore all status fields**, just wait and poll again
|
||||
- Do NOT return `fix_available`, `ci_success`, etc. based on old CIPE!
|
||||
3. Output wait status (see below)
|
||||
4. If timeout (30 min) reached → return `no_new_cipe`
|
||||
|
||||
#### Phase B: Normal Polling (after new CIPE detected)
|
||||
|
||||
Once new CIPE is detected:
|
||||
|
||||
1. Clear the new-CIPE timeout
|
||||
2. Switch to normal polling mode
|
||||
3. Process the NEW CIPE's status normally
|
||||
4. Return when actionable state reached
|
||||
|
||||
### Wait Mode Output
|
||||
|
||||
While in wait mode, output clearly that you're waiting (not processing):
|
||||
|
||||
```
|
||||
[CI Monitor] ═══════════════════════════════════════════════════════
|
||||
[CI Monitor] WAIT MODE - Expecting new CI Attempt
|
||||
[CI Monitor] Expected SHA: <expectedCommitSha>
|
||||
[CI Monitor] Previous CI Attempt: <previousCipeUrl>
|
||||
[CI Monitor] ═══════════════════════════════════════════════════════
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 0m 30s)
|
||||
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 1m 30s)
|
||||
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 2m 30s)
|
||||
[CI Monitor] ✓ New CI Attempt detected! URL: <newCipeUrl>, SHA: <newCommitSha>
|
||||
[CI Monitor] Switching to normal polling mode...
|
||||
```
|
||||
|
||||
### Why This Matters (Context Preservation)
|
||||
|
||||
**The problem**: Stale CIPE data can be very large:
|
||||
|
||||
- `taskOutputSummary`: potentially thousands of characters of build/test output
|
||||
- `suggestedFix`: entire patch files
|
||||
- `suggestedFixReasoning`: detailed explanation
|
||||
|
||||
If subagent returns stale CIPE data to main agent, it **pollutes main agent's context** with useless information (we already processed that CIPE). This wastes valuable context window.
|
||||
|
||||
**Without wait mode:**
|
||||
|
||||
1. Poll `ci_information` → get old CIPE with huge data
|
||||
2. Return to main agent with all that stale data
|
||||
3. Main agent's context gets polluted with useless info
|
||||
4. Main agent has to process/ignore it anyway
|
||||
|
||||
**With wait mode:**
|
||||
|
||||
1. Poll `ci_information` → get old CIPE → **ignore it, don't return**
|
||||
2. Keep waiting internally (stale data stays in subagent)
|
||||
3. New CIPE appears → switch to normal mode
|
||||
4. Return to main agent with only the NEW, relevant CIPE data
|
||||
|
||||
## Polling Loop
|
||||
|
||||
### Subagent State Management
|
||||
|
||||
Maintain internal accumulated state across polls:
|
||||
|
||||
```
|
||||
accumulated_state = {}
|
||||
```
|
||||
|
||||
### Call `ci_information` MCP Tool
|
||||
|
||||
**Wait Mode (expecting new CI Attempt):**
|
||||
|
||||
```
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "cipeUrl,commitSha,cipeStatus"
|
||||
})
|
||||
```
|
||||
|
||||
Only fetch minimal fields needed to detect CI Attempt change. Do NOT fetch heavy fields - stale data wastes context.
|
||||
|
||||
**Normal Mode (processing CI Attempt):**
|
||||
|
||||
```
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning"
|
||||
})
|
||||
```
|
||||
|
||||
Merge response into `accumulated_state` after each poll.
|
||||
|
||||
### Analyze Response
|
||||
|
||||
**If in Wait Mode** (expecting new CIPE):
|
||||
|
||||
1. Check if CIPE is new (see Two-Phase Operation above)
|
||||
2. If old CIPE → **ignore status**, output wait message, poll again
|
||||
3. If new CIPE → switch to normal mode, continue below
|
||||
|
||||
**If in Normal Mode**:
|
||||
Based on the response, decide whether to **keep polling** or **return to main agent**.
|
||||
|
||||
### Keep Polling When
|
||||
|
||||
Continue polling (with backoff) if ANY of these conditions are true:
|
||||
|
||||
| Condition | Reason |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| `cipeStatus == 'IN_PROGRESS'` | CI still running |
|
||||
| `cipeStatus == 'NOT_STARTED'` | CI hasn't started yet |
|
||||
| `selfHealingStatus == 'IN_PROGRESS'` | Self-healing agent working |
|
||||
| `selfHealingStatus == 'NOT_STARTED'` | Self-healing not started yet |
|
||||
| `failureClassification == 'FLAKY_TASK'` | Auto-rerun in progress |
|
||||
| `userAction == 'APPLIED_AUTOMATICALLY'` | New CI Attempt spawning after auto-apply |
|
||||
|
||||
When `couldAutoApplyTasks == true`:
|
||||
|
||||
- `verificationStatus` = `NOT_STARTED`, `IN_PROGRESS` → keep polling (verification still in progress)
|
||||
- `verificationStatus` = `COMPLETED` → return `fix_auto_applying` (auto-apply will happen, main agent spawns wait mode subagent)
|
||||
- `verificationStatus` = `FAILED`, `NOT_EXECUTABLE` → return `fix_available` (auto-apply won't happen, needs manual action)
|
||||
|
||||
### Exponential Backoff
|
||||
|
||||
Between polls, wait with exponential backoff:
|
||||
|
||||
| Poll Attempt | Wait Time |
|
||||
| ------------ | ----------------- |
|
||||
| 1st | 60 seconds |
|
||||
| 2nd | 90 seconds |
|
||||
| 3rd+ | 120 seconds (cap) |
|
||||
|
||||
Reset to 60 seconds when state changes significantly.
|
||||
|
||||
**IMPORTANT:** Run sleep in foreground (NOT as background command). Background sleep causes "What should Claude do?" prompts when completed.
|
||||
|
||||
```bash
|
||||
# Example backoff - run in FOREGROUND
|
||||
sleep 60 # First wait
|
||||
sleep 90 # Second wait
|
||||
sleep 120 # Third and subsequent waits (capped)
|
||||
```
|
||||
|
||||
### Fetch Heavy Fields on Actionable State
|
||||
|
||||
Before returning to main agent, fetch heavy fields if the status requires them:
|
||||
|
||||
| Status | Heavy Fields Needed |
|
||||
| ------------------- | ------------------------------------------------------------------------------ |
|
||||
| `ci_success` | None |
|
||||
| `fix_auto_applying` | None |
|
||||
| `fix_available` | `taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription` |
|
||||
| `fix_failed` | `taskOutputSummary` |
|
||||
| `no_fix` | `taskOutputSummary` |
|
||||
| `environment_issue` | None |
|
||||
| `no_new_cipe` | None |
|
||||
| `polling_timeout` | None |
|
||||
| `cipe_canceled` | None |
|
||||
| `cipe_timed_out` | None |
|
||||
|
||||
```
|
||||
# Example: fetching heavy fields for fix_available
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription"
|
||||
})
|
||||
```
|
||||
|
||||
Merge response into `accumulated_state`, then return merged state to main agent.
|
||||
|
||||
**Pagination:** Heavy string fields return first page only. If `hasMore` indicated, include in return format so main agent knows more content available.
|
||||
|
||||
### Return to Main Agent When
|
||||
|
||||
Return immediately with structured state if ANY of these conditions are true:
|
||||
|
||||
| Status | Condition |
|
||||
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | `cipeStatus == 'SUCCEEDED'` |
|
||||
| `fix_auto_applying` | `selfHealingStatus == 'COMPLETED'` AND `couldAutoApplyTasks == true` AND `verificationStatus == 'COMPLETED'` |
|
||||
| `fix_available` | `selfHealingStatus == 'COMPLETED'` AND `suggestedFix != null` AND (`couldAutoApplyTasks != true` OR `verificationStatus` in (`FAILED`, `NOT_EXECUTABLE`)) |
|
||||
| `fix_failed` | `selfHealingStatus == 'FAILED'` |
|
||||
| `environment_issue` | `failureClassification == 'ENVIRONMENT_STATE'` |
|
||||
| `no_fix` | `cipeStatus == 'FAILED'` AND (`selfHealingEnabled == false` OR `selfHealingStatus == 'NOT_EXECUTABLE'`) |
|
||||
| `no_new_cipe` | `expectedCommitSha` or `previousCipeUrl` provided, but no new CI Attempt detected after 30 min |
|
||||
| `polling_timeout` | Subagent has been polling for > configured timeout (default 60 min) |
|
||||
| `cipe_canceled` | `cipeStatus == 'CANCELED'` |
|
||||
| `cipe_timed_out` | `cipeStatus == 'TIMED_OUT'` |
|
||||
|
||||
## Subagent Timeout
|
||||
|
||||
Track elapsed time. If you have been polling for more than **60 minutes** (configurable via main agent), return with `status: polling_timeout`.
|
||||
|
||||
## Return Format
|
||||
|
||||
When returning to the main agent, provide a structured response with accumulated state:
|
||||
|
||||
```
|
||||
## CI Monitor Result
|
||||
|
||||
**Status:** <status>
|
||||
**Iterations:** <count>
|
||||
**Elapsed:** <minutes>m <seconds>s
|
||||
|
||||
### CI Attempt Details
|
||||
- **Status:** <cipeStatus>
|
||||
- **URL:** <cipeUrl>
|
||||
- **Branch:** <branch>
|
||||
- **Commit:** <commitSha>
|
||||
- **Failed Tasks:** <failedTaskIds>
|
||||
- **Verified Tasks:** <verifiedTaskIds>
|
||||
|
||||
### Self-Healing Details
|
||||
- **Enabled:** <selfHealingEnabled>
|
||||
- **Status:** <selfHealingStatus>
|
||||
- **Verification:** <verificationStatus>
|
||||
- **User Action:** <userAction>
|
||||
- **Classification:** <failureClassification>
|
||||
- **Confidence:** <confidence>
|
||||
- **Confidence Reasoning:** <confidenceReasoning>
|
||||
|
||||
### Fix Information (if available)
|
||||
- **Short Link:** <shortLink>
|
||||
- **Description:** <suggestedFixDescription>
|
||||
- **Reasoning:** <suggestedFixReasoning>
|
||||
|
||||
### Task Output Summary (first page)
|
||||
<taskOutputSummary>
|
||||
[MORE_CONTENT_AVAILABLE: taskOutputSummary, pageToken: 1]
|
||||
|
||||
### Suggested Fix (first page)
|
||||
<suggestedFix>
|
||||
[MORE_CONTENT_AVAILABLE: suggestedFix, pageToken: 1]
|
||||
```
|
||||
|
||||
### Pagination Indicators
|
||||
|
||||
When a heavy field has more content available, append indicator:
|
||||
|
||||
```
|
||||
[MORE_CONTENT_AVAILABLE: <fieldName>, pageToken: <nextPage>]
|
||||
```
|
||||
|
||||
Main agent can fetch additional pages if needed using:
|
||||
|
||||
```
|
||||
ci_information({ select: "<fieldName>", pageToken: <nextPage> })
|
||||
```
|
||||
|
||||
Fields that may have pagination:
|
||||
|
||||
- `taskOutputSummary` (reverse pagination - page 0 = most recent)
|
||||
- `suggestedFix` (forward pagination - page 0 = start)
|
||||
- `suggestedFixReasoning`
|
||||
|
||||
### Return Format for `no_new_cipe`
|
||||
|
||||
When returning with `status: no_new_cipe`, include additional context:
|
||||
|
||||
```
|
||||
## CI Monitor Result
|
||||
|
||||
**Status:** no_new_cipe
|
||||
**Iterations:** <count>
|
||||
**Elapsed:** <minutes>m <seconds>s
|
||||
|
||||
### Expected CI Attempt Not Found
|
||||
- **Expected Commit SHA:** <expectedCommitSha>
|
||||
- **Previous CI Attempt URL:** <previousCipeUrl>
|
||||
- **Last Seen CI Attempt URL:** <cipeUrl>
|
||||
- **Last Seen Commit SHA:** <commitSha>
|
||||
- **New CI Attempt Timeout:** 30 minutes (exceeded)
|
||||
|
||||
### Likely Cause
|
||||
CI workflow failed before Nx tasks could run (e.g., install step, checkout, auth).
|
||||
Check your CI provider logs for the commit <expectedCommitSha>.
|
||||
|
||||
### Last Known CI Attempt State
|
||||
- **Status:** <cipeStatus>
|
||||
- **Branch:** <branch>
|
||||
```
|
||||
|
||||
## Status Reporting (Verbosity-Controlled)
|
||||
|
||||
Output is controlled by the `verbosity` parameter from the main agent:
|
||||
|
||||
| Level | What to Output |
|
||||
| --------- | ----------------------------------------------------------------- |
|
||||
| `minimal` | No intermediate output. Only return final result when actionable. |
|
||||
| `medium` | Output only on significant state changes (not every poll). |
|
||||
| `verbose` | Output detailed phase information after every poll. |
|
||||
|
||||
### Minimal Verbosity
|
||||
|
||||
No output during polling. Poll silently and return when done.
|
||||
|
||||
### Medium Verbosity (Default)
|
||||
|
||||
Output **only when state changes significantly** to save context tokens:
|
||||
|
||||
- `cipeStatus` changes (e.g., IN_PROGRESS → FAILED)
|
||||
- `selfHealingStatus` changes (e.g., IN_PROGRESS → COMPLETED)
|
||||
- New CI Attempt detected (in wait mode)
|
||||
|
||||
Format: single line, no decorators:
|
||||
|
||||
```
|
||||
[CI Monitor] CI: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 4m
|
||||
```
|
||||
|
||||
### Verbose Verbosity
|
||||
|
||||
Output detailed phase box after every poll:
|
||||
|
||||
```
|
||||
[CI Monitor] ─────────────────────────────────────────────────────
|
||||
[CI Monitor] Iteration <N> | Elapsed: <X>m <Y>s
|
||||
[CI Monitor]
|
||||
[CI Monitor] CI Status: <cipeStatus>
|
||||
[CI Monitor] Self-Healing: <selfHealingStatus>
|
||||
[CI Monitor] Verification: <verificationStatus>
|
||||
[CI Monitor] Classification: <failureClassification>
|
||||
[CI Monitor]
|
||||
[CI Monitor] → <human-readable phase description>
|
||||
[CI Monitor] ─────────────────────────────────────────────────────
|
||||
```
|
||||
|
||||
### Phase Descriptions (for verbose output)
|
||||
|
||||
| Status Combo | Description |
|
||||
| ----------------------------------------------------------------------------------------- | ------------------------------------------- |
|
||||
| `cipeStatus: IN_PROGRESS` | "CI running..." |
|
||||
| `cipeStatus: NOT_STARTED` | "Waiting for CI to start..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: NOT_STARTED` | "CI failed. Self-healing starting..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: IN_PROGRESS` | "CI failed. Self-healing generating fix..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: IN_PROGRESS` | "Fix generated! Verification running..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: COMPLETED` | "Fix ready! Verified successfully." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: FAILED` | "Fix generated but verification failed." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: FAILED` | "Self-healing could not generate a fix." |
|
||||
| `cipeStatus: SUCCEEDED` | "CI passed!" |
|
||||
|
||||
## Important Notes
|
||||
|
||||
- You do NOT make apply/reject decisions - that's the main agent's job
|
||||
- You do NOT perform git operations
|
||||
- You only poll and report state
|
||||
- Respect the `verbosity` parameter for output (default: medium)
|
||||
- If `ci_information` returns an error, wait and retry (count as failed poll)
|
||||
- Track consecutive failures - if 5 consecutive failures, return with `status: error`
|
||||
- When expecting new CI Attempt, track the 30-minute new-CI-Attempt timeout separately from the main polling timeout
|
||||
@@ -1,428 +0,0 @@
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \| Elapsed: Xm \| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```
|
||||
@@ -1,437 +0,0 @@
|
||||
---
|
||||
name: ci-monitor
|
||||
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
|
||||
---
|
||||
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
Parse any overrides from `$ARGUMENTS` and merge with defaults.
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \| Elapsed: Xm \| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```
|
||||
@@ -1,228 +0,0 @@
|
||||
---
|
||||
name: nx-generate
|
||||
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
|
||||
---
|
||||
|
||||
# Run Nx Generator
|
||||
|
||||
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
|
||||
|
||||
This skill applies when the user wants to:
|
||||
|
||||
- Create new projects like libraries or applications
|
||||
- Scaffold features or boilerplate code
|
||||
- Run workspace-specific or custom generators
|
||||
- Do anything else that an nx generator exists for
|
||||
|
||||
## Generator Discovery Flow
|
||||
|
||||
### Step 1: List Available Generators
|
||||
|
||||
Use the Nx CLI to discover available generators:
|
||||
|
||||
- List all generators for a plugin: `npx nx list @nx/react`
|
||||
- View available plugins: `npx nx list`
|
||||
|
||||
This includes:
|
||||
|
||||
- Plugin generators (e.g., `@nx/react:library`, `@nx/js:library`)
|
||||
- Local workspace generators (defined in the repo's own plugins)
|
||||
|
||||
### Step 2: Match Generator to User Request
|
||||
|
||||
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
|
||||
|
||||
- What artifact type they want to create (library, application, etc.)
|
||||
- Which framework or technology stack is relevant
|
||||
- Whether they mentioned specific generator names
|
||||
|
||||
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
|
||||
|
||||
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
|
||||
|
||||
## Pre-Execution Checklist
|
||||
|
||||
Before running any generator, complete these steps:
|
||||
|
||||
### 1. Fetch Generator Schema
|
||||
|
||||
Use the `--help` flag to understand all available options:
|
||||
|
||||
```bash
|
||||
npx nx g @nx/react:library --help
|
||||
```
|
||||
|
||||
Pay attention to:
|
||||
|
||||
- Required options that must be provided
|
||||
- Optional options that may be relevant to the user's request
|
||||
- Default values that might need to be overridden
|
||||
|
||||
### 2. Read Generator Source Code
|
||||
|
||||
Understanding what the generator actually does helps you:
|
||||
|
||||
- Know what files will be created/modified
|
||||
- Understand any side effects (updating configs, installing deps, etc.)
|
||||
- Identify options that might not be obvious from the schema
|
||||
|
||||
To find generator source code:
|
||||
|
||||
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
|
||||
- If that fails, read directly from `node_modules/<plugin>/generators.json`
|
||||
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
|
||||
|
||||
### 2.5 Reevaluate if the generator is right
|
||||
|
||||
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
|
||||
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
|
||||
|
||||
### 3. Understand Repo Context
|
||||
|
||||
Before generating, examine the target area of the codebase:
|
||||
|
||||
- Look at similar existing artifacts (other libraries, applications, etc.)
|
||||
- Identify patterns and conventions used in the repo
|
||||
- Note naming conventions, file structures, and configuration patterns
|
||||
- Try to match these patterns when configuring the generator
|
||||
|
||||
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
|
||||
If projects or other artifacts are organized with a specific naming convention, try to match it.
|
||||
|
||||
### 4. Validate Required Options
|
||||
|
||||
Ensure all required options have values:
|
||||
|
||||
- Map the user's request to generator options
|
||||
- Infer values from context where possible
|
||||
- Ask the user for any critical missing information
|
||||
|
||||
## Execution
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
|
||||
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
|
||||
|
||||
### Consider Dry-Run (Optional)
|
||||
|
||||
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
|
||||
|
||||
- For complex generators or unfamiliar territory: do a dry-run first
|
||||
- For simple, well-understood generators: may proceed directly
|
||||
- Dry-run shows file names and created/deleted/modified markers, but not content
|
||||
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
|
||||
|
||||
### Running the Generator
|
||||
|
||||
Execute the generator with:
|
||||
|
||||
```bash
|
||||
nx generate <generator-name> <options> --no-interactive
|
||||
```
|
||||
|
||||
**CRITICAL**: Always include `--no-interactive` to prevent prompts that would hang the execution.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx generate @nx/react:library --name=my-utils --no-interactive
|
||||
```
|
||||
|
||||
### Handling Generator Failures
|
||||
|
||||
If the generator fails:
|
||||
|
||||
1. **Diagnose the error** - Read the error message carefully
|
||||
2. **Identify the cause** - Missing options, invalid values, conflicts, etc.
|
||||
3. **Attempt automatic fix** - Adjust options or resolve conflicts
|
||||
4. **Retry** - Run the generator again with corrected options
|
||||
|
||||
Common failure reasons:
|
||||
|
||||
- Missing required options
|
||||
- Invalid option values
|
||||
- Conflicting with existing files
|
||||
- Missing dependencies
|
||||
- Generator doesn't support certain flag combinations
|
||||
|
||||
## Post-Generation
|
||||
|
||||
### 1. Modify Generated Code (If Needed)
|
||||
|
||||
Generators provide a starting point, but the output may need adjustment to match the user's specific requirements:
|
||||
|
||||
- Add or modify functionality as requested
|
||||
- Adjust imports, exports, or configurations
|
||||
- Integrate with existing code patterns in the repo
|
||||
|
||||
### 2. Format Code
|
||||
|
||||
Run formatting on all generated/modified files:
|
||||
|
||||
```bash
|
||||
nx format --fix
|
||||
```
|
||||
|
||||
Languages other than javascript/typescript might need other formatting invocations too.
|
||||
|
||||
### 3. Run Verification
|
||||
|
||||
Verify that the generated code works correctly. What this looks like will vary depending on the type of generator and the targets available.
|
||||
If the generator created a new project, run its targets directly
|
||||
Use your best judgement to determine what needs to be verified.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx lint <new-project>
|
||||
nx test <new-project>
|
||||
nx build <new-project>
|
||||
```
|
||||
|
||||
### 4. Handle Verification Failures
|
||||
|
||||
When verification fails:
|
||||
|
||||
**If scope is manageable** (a few lint errors, minor type issues):
|
||||
|
||||
- Fix the issues
|
||||
- Re-run verification to confirm
|
||||
|
||||
**If issues are extensive** (many errors, complex problems):
|
||||
|
||||
- Attempt simple, obvious fixes first
|
||||
- If still failing, escalate to the user with:
|
||||
- Description of what was generated
|
||||
- What verification is failing
|
||||
- What you've attempted to fix
|
||||
- Remaining issues that need user input
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Generator Failures
|
||||
|
||||
- Check the error message for specific causes
|
||||
- Verify all required options are provided
|
||||
- Check for conflicts with existing files
|
||||
- Ensure the generator name and options are correct
|
||||
|
||||
### Missing Options
|
||||
|
||||
- Consult the generator schema for required fields
|
||||
- Infer values from context when reasonable
|
||||
- Ask the user for values that cannot be inferred
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Local generators first** - Always prefer workspace/local generators over external plugin generators when both could work
|
||||
|
||||
2. **Understand before running** - Read both the schema AND the source code to fully understand what will happen
|
||||
|
||||
3. **No prompts** - Always use `--no-interactive` to prevent hanging
|
||||
|
||||
4. **Generators are starting points** - Modify the output as needed to fully satisfy the user's requirements
|
||||
|
||||
5. **Verify changes work** - Don't just generate; ensure the code builds, lints, and tests pass
|
||||
|
||||
6. **Be proactive about fixes** - Don't just report errors; attempt to resolve them automatically when possible
|
||||
|
||||
7. **Match repo patterns** - Study existing similar code in the repo and match its conventions
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
name: nx-plugins
|
||||
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
|
||||
---
|
||||
|
||||
## Finding and Installing new plugins
|
||||
|
||||
- List plugins: `pnpm nx list`
|
||||
- Install plugins `pnpm nx add <plugin>`. Example: `pnpm nx add @nx/react`.
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
name: nx-run-tasks
|
||||
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
|
||||
---
|
||||
|
||||
You can run tasks with Nx in the following way.
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
|
||||
|
||||
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
|
||||
|
||||
## Understand which tasks can be run
|
||||
|
||||
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
|
||||
|
||||
## Run a single task
|
||||
|
||||
```
|
||||
nx run <project>:<task>
|
||||
```
|
||||
|
||||
where `project` is the project name defined in `package.json` or `project.json` (if present).
|
||||
|
||||
## Run multiple tasks
|
||||
|
||||
```
|
||||
nx run-many -t build test lint typecheck
|
||||
```
|
||||
|
||||
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
|
||||
|
||||
Examples:
|
||||
|
||||
- `nx run-many -t test -p proj1 proj2` — test specific projects
|
||||
- `nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
|
||||
- `nx run-many -t test --projects=tag:api-*` — test projects by tag
|
||||
|
||||
## Run tasks for affected projects
|
||||
|
||||
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
|
||||
|
||||
```
|
||||
nx affected -t build test lint
|
||||
```
|
||||
|
||||
By default it compares against the base branch. You can customize this:
|
||||
|
||||
- `nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
|
||||
- `nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
|
||||
|
||||
## Useful flags
|
||||
|
||||
These flags work with `run`, `run-many`, and `affected`:
|
||||
|
||||
- `--skipNxCache` — rerun tasks even when results are cached
|
||||
- `--verbose` — print additional information such as stack traces
|
||||
- `--nxBail` — stop execution after the first failed task
|
||||
- `--configuration=<name>` — use a specific configuration (e.g. `production`)
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
name: nx-workspace
|
||||
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
|
||||
---
|
||||
|
||||
# Nx Workspace Exploration
|
||||
|
||||
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
|
||||
|
||||
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
|
||||
|
||||
## Listing Projects
|
||||
|
||||
Use `nx show projects` to list projects in the workspace.
|
||||
|
||||
```bash
|
||||
# List all projects
|
||||
nx show projects
|
||||
|
||||
# Filter by pattern (glob)
|
||||
nx show projects --projects "apps/*"
|
||||
nx show projects --projects "shared-*"
|
||||
|
||||
# Filter by project type
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
nx show projects --type e2e
|
||||
|
||||
# Filter by target (projects that have a specific target)
|
||||
nx show projects --withTarget build
|
||||
nx show projects --withTarget e2e
|
||||
|
||||
# Find affected projects (changed since base branch)
|
||||
nx show projects --affected
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Combine filters
|
||||
nx show projects --type lib --withTarget test
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Output as JSON
|
||||
nx show projects --json
|
||||
```
|
||||
|
||||
## Project Configuration
|
||||
|
||||
Use `nx show project <name> --json` to get the full resolved configuration for a project.
|
||||
|
||||
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
|
||||
|
||||
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Get full project configuration
|
||||
nx show project my-app --json
|
||||
|
||||
# Extract specific parts from the JSON
|
||||
nx show project my-app --json | jq '.targets'
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
|
||||
# Check project metadata
|
||||
nx show project my-app --json | jq '{name, root, sourceRoot, projectType, tags}'
|
||||
```
|
||||
|
||||
## Target Information
|
||||
|
||||
Targets define what tasks can be run on a project.
|
||||
|
||||
```bash
|
||||
# List all targets for a project
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
# Get full target configuration
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
|
||||
# Check target executor/command
|
||||
nx show project my-app --json | jq '.targets.build.executor'
|
||||
nx show project my-app --json | jq '.targets.build.command'
|
||||
|
||||
# View target options
|
||||
nx show project my-app --json | jq '.targets.build.options'
|
||||
|
||||
# Check target inputs/outputs (for caching)
|
||||
nx show project my-app --json | jq '.targets.build.inputs'
|
||||
nx show project my-app --json | jq '.targets.build.outputs'
|
||||
|
||||
# Find projects with a specific target
|
||||
nx show projects --withTarget serve
|
||||
nx show projects --withTarget e2e
|
||||
```
|
||||
|
||||
## Workspace Configuration
|
||||
|
||||
Read `nx.json` directly for workspace-level configuration.
|
||||
You can read the full project schema at `node_modules/nx/schemas/nx-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Read the full nx.json
|
||||
cat nx.json
|
||||
|
||||
# Or use jq for specific sections
|
||||
cat nx.json | jq '.targetDefaults'
|
||||
cat nx.json | jq '.namedInputs'
|
||||
cat nx.json | jq '.plugins'
|
||||
cat nx.json | jq '.generators'
|
||||
```
|
||||
|
||||
Key nx.json sections:
|
||||
|
||||
- `targetDefaults` - Default configuration applied to all targets of a given name
|
||||
- `namedInputs` - Reusable input definitions for caching
|
||||
- `plugins` - Nx plugins and their configuration
|
||||
- ...and much more, read the schema or nx.json for details
|
||||
|
||||
## Affected Projects
|
||||
|
||||
Find projects affected by changes in the current branch.
|
||||
|
||||
```bash
|
||||
# Affected since base branch (auto-detected)
|
||||
nx show projects --affected
|
||||
|
||||
# Affected with explicit base
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --base=origin/main
|
||||
|
||||
# Affected between two commits
|
||||
nx show projects --affected --base=abc123 --head=def456
|
||||
|
||||
# Affected apps only
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Affected excluding e2e projects
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Affected by uncommitted changes
|
||||
nx show projects --affected --uncommitted
|
||||
|
||||
# Affected by untracked files
|
||||
nx show projects --affected --untracked
|
||||
```
|
||||
|
||||
## Common Exploration Patterns
|
||||
|
||||
### "What's in this workspace?"
|
||||
|
||||
```bash
|
||||
nx show projects
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
```
|
||||
|
||||
### "How do I build/test/lint project X?"
|
||||
|
||||
```bash
|
||||
nx show project X --json | jq '.targets | keys'
|
||||
nx show project X --json | jq '.targets.build'
|
||||
```
|
||||
|
||||
### "What depends on library Y?"
|
||||
|
||||
```bash
|
||||
# Find projects that may depend on Y by searching for imports
|
||||
# (Nx doesn't have a direct "dependents" command via CLI)
|
||||
grep -r "from '@myorg/Y'" --include="*.ts" --include="*.tsx" apps/ libs/
|
||||
```
|
||||
|
||||
### "What configuration options are available?"
|
||||
|
||||
```bash
|
||||
cat node_modules/nx/schemas/nx-schema.json | jq '.properties | keys'
|
||||
cat node_modules/nx/schemas/project-schema.json | jq '.properties | keys'
|
||||
```
|
||||
|
||||
### "Why is project X affected?"
|
||||
|
||||
```bash
|
||||
# Check what files changed
|
||||
git diff --name-only main
|
||||
|
||||
# See which project owns those files
|
||||
nx show project X --json | jq '.root'
|
||||
```
|
||||
@@ -0,0 +1,7 @@
|
||||
FROM mcr.microsoft.com/devcontainers/typescript-node:20-bullseye
|
||||
|
||||
# Update the underlying (Debian) OS, to make sure we have the latest security patches and libraries like 'GLIBC'
|
||||
RUN sudo apt-get update && sudo apt-get -y upgrade
|
||||
|
||||
# Update pnpm
|
||||
RUN npm install -g pnpm@8.15.7
|
||||
@@ -3,46 +3,31 @@
|
||||
{
|
||||
"name": "NxDevContainer",
|
||||
// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
|
||||
|
||||
// Starting from a base image that already contains GLIBC v2.33 or higher (required by Nx)
|
||||
// Try a more recent distribution, if your are having build issues related to GLIBC version
|
||||
// Here we use 'bookworm', which is based on `Debian-12`, which comes with `GLIBC v2.36`
|
||||
// (Nx tools currenlty requires `GLIBC v2.33` or higher)
|
||||
// Note: Using base debian image instead of typescript-node since mise will manage all tools
|
||||
"image": "mcr.microsoft.com/devcontainers/base:bookworm",
|
||||
|
||||
// All tools (Node, Java, Rust, Dotnet) are managed by mise via mise.toml
|
||||
"features": {},
|
||||
|
||||
"build": {
|
||||
// Path is relative to the devcontainer.json file.
|
||||
"dockerfile": "Dockerfile"
|
||||
},
|
||||
"features": {
|
||||
"ghcr.io/devcontainers/features/rust:1": {}
|
||||
},
|
||||
// Use 'forwardPorts' to make a list of ports inside the container available locally.
|
||||
// 4211 = nx graph port
|
||||
// 4873 = verdaccio (local npm registry) port
|
||||
"forwardPorts": [4211, 4873],
|
||||
|
||||
"forwardPorts": [4211],
|
||||
// Use 'postCreateCommand' to run commands after the container is created.
|
||||
"postCreateCommand": "./.devcontainer/postCreateCommand.sh",
|
||||
|
||||
// Configure tool-specific properties.
|
||||
"customizations": {
|
||||
"vscode": {
|
||||
"extensions": [
|
||||
"nrwl.angular-console",
|
||||
"firsttris.vscode-jest-runner",
|
||||
"eamodio.gitlens",
|
||||
"mhutchie.git-graph",
|
||||
"mutantdino.resourcemonitor" // to monitor cpu, memory usage from the dev container
|
||||
"eamodio.gitlens"
|
||||
],
|
||||
"settings": {
|
||||
"debug.javascript.autoAttachFilter": "disabled" // workaround for that issue: https://github.com/microsoft/vscode-js-debug/issues/374#issuecomment-622239998
|
||||
"debug.javascript.autoAttachFilter": "onlyWithFlag" // workaround for that issue: https://github.com/microsoft/vscode-js-debug/issues/374#issuecomment-622239998
|
||||
}
|
||||
}
|
||||
},
|
||||
|
||||
// To improve disk performances when installing node modules
|
||||
// See https://code.visualstudio.com/remote/advancedcontainers/improve-performance
|
||||
"mounts": [
|
||||
"source=${localWorkspaceFolderBasename}-node_modules,target=${containerWorkspaceFolder}/node_modules,type=volume"
|
||||
],
|
||||
}
|
||||
// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
|
||||
"remoteUser": "root"
|
||||
// "remoteUser": "root"
|
||||
}
|
||||
|
||||
@@ -1,41 +1,5 @@
|
||||
#!/bin/bash
|
||||
#!/bin/sh
|
||||
|
||||
# Update the underlying (Debian) OS, to make sure we have the latest security patches and libraries like 'GLIBC'
|
||||
echo "⚙️ Updating the underlying OS..."
|
||||
sudo apt-get update && sudo apt-get -y upgrade
|
||||
|
||||
# Install mise for managing development tools (Node, Java, Rust, Dotnet)
|
||||
echo "⚙️ Installing mise..."
|
||||
curl https://mise.run | sh
|
||||
|
||||
# Add mise to PATH
|
||||
export PATH="$HOME/.local/bin:$PATH"
|
||||
|
||||
# Trust the mise.toml configuration file
|
||||
echo "⚙️ Trusting mise.toml configuration..."
|
||||
mise trust
|
||||
|
||||
# Install all tools from mise.toml (node, java, rust, dotnet)
|
||||
echo "⚙️ Installing tools via mise (node, java, rust, dotnet)..."
|
||||
mise install
|
||||
|
||||
# Activate mise to make tools available in current shell
|
||||
eval "$(mise activate bash)"
|
||||
|
||||
# Add mise activation to bashrc for future shell sessions
|
||||
echo "⚙️ Configuring mise activation in shell..."
|
||||
echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc
|
||||
|
||||
# Prevent corepack from prompting user before downloading PNPM
|
||||
export COREPACK_ENABLE_DOWNLOAD_PROMPT=0
|
||||
|
||||
# Enable corepack
|
||||
corepack enable
|
||||
|
||||
# Install the PNPM version defined in the root package.json
|
||||
echo "⚙️ Installing required PNPM version..."
|
||||
corepack prepare --activate
|
||||
|
||||
# Install NPM dependencies
|
||||
echo "⚙️ Installing NPM dependencies..."
|
||||
# Install dependencies
|
||||
pnpm install --frozen-lockfile
|
||||
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ end_of_line = lf
|
||||
insert_final_newline = true
|
||||
|
||||
# 4 space indentation
|
||||
[*.{kts,kt,js,ts,jsx,tsx}]
|
||||
[*.{js,ts,jsx,tsx}]
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
||||
|
||||
+2
-36
@@ -4,26 +4,12 @@
|
||||
"env": {
|
||||
"node": true
|
||||
},
|
||||
"ignorePatterns": ["**/*.ts", "**/test-output", "**/dist"],
|
||||
"ignorePatterns": ["**/*.ts"],
|
||||
"plugins": ["@typescript-eslint", "@nx"],
|
||||
"extends": ["plugin:storybook/recommended"],
|
||||
"rules": {
|
||||
"@typescript-eslint/explicit-module-boundary-types": "off",
|
||||
"no-restricted-imports": [
|
||||
"error",
|
||||
{
|
||||
"paths": [
|
||||
{
|
||||
"name": "create-nx-workspace",
|
||||
"message": "Please import utils from nx or @nx/devkit instead."
|
||||
},
|
||||
{
|
||||
"name": "node-fetch",
|
||||
"message": "Please default to native fetch instead of 'node-fetch'."
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"no-restricted-imports": ["error", "create-nx-workspace"],
|
||||
"@typescript-eslint/no-restricted-imports": [
|
||||
"error",
|
||||
{
|
||||
@@ -75,28 +61,8 @@
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"@nx/workspace/valid-command-object": "error",
|
||||
"@nx/workspace/require-windows-hide": "error"
|
||||
}
|
||||
},
|
||||
{
|
||||
"files": ["pnpm-lock.yaml"],
|
||||
"parser": "./tools/eslint-rules/raw-file-parser.js",
|
||||
"rules": {
|
||||
"@nx/workspace/ensure-pnpm-lock-version": [
|
||||
"error",
|
||||
{
|
||||
"version": "9.0"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"files": ["*.ts"],
|
||||
"rules": {
|
||||
"@angular-eslint/prefer-standalone": "off"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1,438 +0,0 @@
|
||||
description = "Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting."
|
||||
prompt = """
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
{{args}}
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
Parse any overrides from `{{args}}` and merge with defaults.
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \\| Elapsed: Xm \\| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```"""
|
||||
@@ -1,10 +0,0 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"nx-mcp": {
|
||||
"type": "stdio",
|
||||
"command": "npx",
|
||||
"args": ["nx", "mcp"]
|
||||
}
|
||||
},
|
||||
"contextFileName": "AGENTS.md"
|
||||
}
|
||||
@@ -1,437 +0,0 @@
|
||||
---
|
||||
name: ci-monitor
|
||||
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
|
||||
---
|
||||
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
Parse any overrides from `$ARGUMENTS` and merge with defaults.
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \| Elapsed: Xm \| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```
|
||||
@@ -1,228 +0,0 @@
|
||||
---
|
||||
name: nx-generate
|
||||
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
|
||||
---
|
||||
|
||||
# Run Nx Generator
|
||||
|
||||
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
|
||||
|
||||
This skill applies when the user wants to:
|
||||
|
||||
- Create new projects like libraries or applications
|
||||
- Scaffold features or boilerplate code
|
||||
- Run workspace-specific or custom generators
|
||||
- Do anything else that an nx generator exists for
|
||||
|
||||
## Generator Discovery Flow
|
||||
|
||||
### Step 1: List Available Generators
|
||||
|
||||
Use the Nx CLI to discover available generators:
|
||||
|
||||
- List all generators for a plugin: `npx nx list @nx/react`
|
||||
- View available plugins: `npx nx list`
|
||||
|
||||
This includes:
|
||||
|
||||
- Plugin generators (e.g., `@nx/react:library`, `@nx/js:library`)
|
||||
- Local workspace generators (defined in the repo's own plugins)
|
||||
|
||||
### Step 2: Match Generator to User Request
|
||||
|
||||
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
|
||||
|
||||
- What artifact type they want to create (library, application, etc.)
|
||||
- Which framework or technology stack is relevant
|
||||
- Whether they mentioned specific generator names
|
||||
|
||||
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
|
||||
|
||||
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
|
||||
|
||||
## Pre-Execution Checklist
|
||||
|
||||
Before running any generator, complete these steps:
|
||||
|
||||
### 1. Fetch Generator Schema
|
||||
|
||||
Use the `--help` flag to understand all available options:
|
||||
|
||||
```bash
|
||||
npx nx g @nx/react:library --help
|
||||
```
|
||||
|
||||
Pay attention to:
|
||||
|
||||
- Required options that must be provided
|
||||
- Optional options that may be relevant to the user's request
|
||||
- Default values that might need to be overridden
|
||||
|
||||
### 2. Read Generator Source Code
|
||||
|
||||
Understanding what the generator actually does helps you:
|
||||
|
||||
- Know what files will be created/modified
|
||||
- Understand any side effects (updating configs, installing deps, etc.)
|
||||
- Identify options that might not be obvious from the schema
|
||||
|
||||
To find generator source code:
|
||||
|
||||
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
|
||||
- If that fails, read directly from `node_modules/<plugin>/generators.json`
|
||||
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
|
||||
|
||||
### 2.5 Reevaluate if the generator is right
|
||||
|
||||
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
|
||||
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
|
||||
|
||||
### 3. Understand Repo Context
|
||||
|
||||
Before generating, examine the target area of the codebase:
|
||||
|
||||
- Look at similar existing artifacts (other libraries, applications, etc.)
|
||||
- Identify patterns and conventions used in the repo
|
||||
- Note naming conventions, file structures, and configuration patterns
|
||||
- Try to match these patterns when configuring the generator
|
||||
|
||||
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
|
||||
If projects or other artifacts are organized with a specific naming convention, try to match it.
|
||||
|
||||
### 4. Validate Required Options
|
||||
|
||||
Ensure all required options have values:
|
||||
|
||||
- Map the user's request to generator options
|
||||
- Infer values from context where possible
|
||||
- Ask the user for any critical missing information
|
||||
|
||||
## Execution
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
|
||||
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
|
||||
|
||||
### Consider Dry-Run (Optional)
|
||||
|
||||
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
|
||||
|
||||
- For complex generators or unfamiliar territory: do a dry-run first
|
||||
- For simple, well-understood generators: may proceed directly
|
||||
- Dry-run shows file names and created/deleted/modified markers, but not content
|
||||
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
|
||||
|
||||
### Running the Generator
|
||||
|
||||
Execute the generator with:
|
||||
|
||||
```bash
|
||||
nx generate <generator-name> <options> --no-interactive
|
||||
```
|
||||
|
||||
**CRITICAL**: Always include `--no-interactive` to prevent prompts that would hang the execution.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx generate @nx/react:library --name=my-utils --no-interactive
|
||||
```
|
||||
|
||||
### Handling Generator Failures
|
||||
|
||||
If the generator fails:
|
||||
|
||||
1. **Diagnose the error** - Read the error message carefully
|
||||
2. **Identify the cause** - Missing options, invalid values, conflicts, etc.
|
||||
3. **Attempt automatic fix** - Adjust options or resolve conflicts
|
||||
4. **Retry** - Run the generator again with corrected options
|
||||
|
||||
Common failure reasons:
|
||||
|
||||
- Missing required options
|
||||
- Invalid option values
|
||||
- Conflicting with existing files
|
||||
- Missing dependencies
|
||||
- Generator doesn't support certain flag combinations
|
||||
|
||||
## Post-Generation
|
||||
|
||||
### 1. Modify Generated Code (If Needed)
|
||||
|
||||
Generators provide a starting point, but the output may need adjustment to match the user's specific requirements:
|
||||
|
||||
- Add or modify functionality as requested
|
||||
- Adjust imports, exports, or configurations
|
||||
- Integrate with existing code patterns in the repo
|
||||
|
||||
### 2. Format Code
|
||||
|
||||
Run formatting on all generated/modified files:
|
||||
|
||||
```bash
|
||||
nx format --fix
|
||||
```
|
||||
|
||||
Languages other than javascript/typescript might need other formatting invocations too.
|
||||
|
||||
### 3. Run Verification
|
||||
|
||||
Verify that the generated code works correctly. What this looks like will vary depending on the type of generator and the targets available.
|
||||
If the generator created a new project, run its targets directly
|
||||
Use your best judgement to determine what needs to be verified.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx lint <new-project>
|
||||
nx test <new-project>
|
||||
nx build <new-project>
|
||||
```
|
||||
|
||||
### 4. Handle Verification Failures
|
||||
|
||||
When verification fails:
|
||||
|
||||
**If scope is manageable** (a few lint errors, minor type issues):
|
||||
|
||||
- Fix the issues
|
||||
- Re-run verification to confirm
|
||||
|
||||
**If issues are extensive** (many errors, complex problems):
|
||||
|
||||
- Attempt simple, obvious fixes first
|
||||
- If still failing, escalate to the user with:
|
||||
- Description of what was generated
|
||||
- What verification is failing
|
||||
- What you've attempted to fix
|
||||
- Remaining issues that need user input
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Generator Failures
|
||||
|
||||
- Check the error message for specific causes
|
||||
- Verify all required options are provided
|
||||
- Check for conflicts with existing files
|
||||
- Ensure the generator name and options are correct
|
||||
|
||||
### Missing Options
|
||||
|
||||
- Consult the generator schema for required fields
|
||||
- Infer values from context when reasonable
|
||||
- Ask the user for values that cannot be inferred
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Local generators first** - Always prefer workspace/local generators over external plugin generators when both could work
|
||||
|
||||
2. **Understand before running** - Read both the schema AND the source code to fully understand what will happen
|
||||
|
||||
3. **No prompts** - Always use `--no-interactive` to prevent hanging
|
||||
|
||||
4. **Generators are starting points** - Modify the output as needed to fully satisfy the user's requirements
|
||||
|
||||
5. **Verify changes work** - Don't just generate; ensure the code builds, lints, and tests pass
|
||||
|
||||
6. **Be proactive about fixes** - Don't just report errors; attempt to resolve them automatically when possible
|
||||
|
||||
7. **Match repo patterns** - Study existing similar code in the repo and match its conventions
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
name: nx-plugins
|
||||
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
|
||||
---
|
||||
|
||||
## Finding and Installing new plugins
|
||||
|
||||
- List plugins: `pnpm nx list`
|
||||
- Install plugins `pnpm nx add <plugin>`. Example: `pnpm nx add @nx/react`.
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
name: nx-run-tasks
|
||||
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
|
||||
---
|
||||
|
||||
You can run tasks with Nx in the following way.
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
|
||||
|
||||
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
|
||||
|
||||
## Understand which tasks can be run
|
||||
|
||||
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
|
||||
|
||||
## Run a single task
|
||||
|
||||
```
|
||||
nx run <project>:<task>
|
||||
```
|
||||
|
||||
where `project` is the project name defined in `package.json` or `project.json` (if present).
|
||||
|
||||
## Run multiple tasks
|
||||
|
||||
```
|
||||
nx run-many -t build test lint typecheck
|
||||
```
|
||||
|
||||
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
|
||||
|
||||
Examples:
|
||||
|
||||
- `nx run-many -t test -p proj1 proj2` — test specific projects
|
||||
- `nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
|
||||
- `nx run-many -t test --projects=tag:api-*` — test projects by tag
|
||||
|
||||
## Run tasks for affected projects
|
||||
|
||||
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
|
||||
|
||||
```
|
||||
nx affected -t build test lint
|
||||
```
|
||||
|
||||
By default it compares against the base branch. You can customize this:
|
||||
|
||||
- `nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
|
||||
- `nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
|
||||
|
||||
## Useful flags
|
||||
|
||||
These flags work with `run`, `run-many`, and `affected`:
|
||||
|
||||
- `--skipNxCache` — rerun tasks even when results are cached
|
||||
- `--verbose` — print additional information such as stack traces
|
||||
- `--nxBail` — stop execution after the first failed task
|
||||
- `--configuration=<name>` — use a specific configuration (e.g. `production`)
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
name: nx-workspace
|
||||
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
|
||||
---
|
||||
|
||||
# Nx Workspace Exploration
|
||||
|
||||
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
|
||||
|
||||
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
|
||||
|
||||
## Listing Projects
|
||||
|
||||
Use `nx show projects` to list projects in the workspace.
|
||||
|
||||
```bash
|
||||
# List all projects
|
||||
nx show projects
|
||||
|
||||
# Filter by pattern (glob)
|
||||
nx show projects --projects "apps/*"
|
||||
nx show projects --projects "shared-*"
|
||||
|
||||
# Filter by project type
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
nx show projects --type e2e
|
||||
|
||||
# Filter by target (projects that have a specific target)
|
||||
nx show projects --withTarget build
|
||||
nx show projects --withTarget e2e
|
||||
|
||||
# Find affected projects (changed since base branch)
|
||||
nx show projects --affected
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Combine filters
|
||||
nx show projects --type lib --withTarget test
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Output as JSON
|
||||
nx show projects --json
|
||||
```
|
||||
|
||||
## Project Configuration
|
||||
|
||||
Use `nx show project <name> --json` to get the full resolved configuration for a project.
|
||||
|
||||
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
|
||||
|
||||
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Get full project configuration
|
||||
nx show project my-app --json
|
||||
|
||||
# Extract specific parts from the JSON
|
||||
nx show project my-app --json | jq '.targets'
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
|
||||
# Check project metadata
|
||||
nx show project my-app --json | jq '{name, root, sourceRoot, projectType, tags}'
|
||||
```
|
||||
|
||||
## Target Information
|
||||
|
||||
Targets define what tasks can be run on a project.
|
||||
|
||||
```bash
|
||||
# List all targets for a project
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
# Get full target configuration
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
|
||||
# Check target executor/command
|
||||
nx show project my-app --json | jq '.targets.build.executor'
|
||||
nx show project my-app --json | jq '.targets.build.command'
|
||||
|
||||
# View target options
|
||||
nx show project my-app --json | jq '.targets.build.options'
|
||||
|
||||
# Check target inputs/outputs (for caching)
|
||||
nx show project my-app --json | jq '.targets.build.inputs'
|
||||
nx show project my-app --json | jq '.targets.build.outputs'
|
||||
|
||||
# Find projects with a specific target
|
||||
nx show projects --withTarget serve
|
||||
nx show projects --withTarget e2e
|
||||
```
|
||||
|
||||
## Workspace Configuration
|
||||
|
||||
Read `nx.json` directly for workspace-level configuration.
|
||||
You can read the full project schema at `node_modules/nx/schemas/nx-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Read the full nx.json
|
||||
cat nx.json
|
||||
|
||||
# Or use jq for specific sections
|
||||
cat nx.json | jq '.targetDefaults'
|
||||
cat nx.json | jq '.namedInputs'
|
||||
cat nx.json | jq '.plugins'
|
||||
cat nx.json | jq '.generators'
|
||||
```
|
||||
|
||||
Key nx.json sections:
|
||||
|
||||
- `targetDefaults` - Default configuration applied to all targets of a given name
|
||||
- `namedInputs` - Reusable input definitions for caching
|
||||
- `plugins` - Nx plugins and their configuration
|
||||
- ...and much more, read the schema or nx.json for details
|
||||
|
||||
## Affected Projects
|
||||
|
||||
Find projects affected by changes in the current branch.
|
||||
|
||||
```bash
|
||||
# Affected since base branch (auto-detected)
|
||||
nx show projects --affected
|
||||
|
||||
# Affected with explicit base
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --base=origin/main
|
||||
|
||||
# Affected between two commits
|
||||
nx show projects --affected --base=abc123 --head=def456
|
||||
|
||||
# Affected apps only
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Affected excluding e2e projects
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Affected by uncommitted changes
|
||||
nx show projects --affected --uncommitted
|
||||
|
||||
# Affected by untracked files
|
||||
nx show projects --affected --untracked
|
||||
```
|
||||
|
||||
## Common Exploration Patterns
|
||||
|
||||
### "What's in this workspace?"
|
||||
|
||||
```bash
|
||||
nx show projects
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
```
|
||||
|
||||
### "How do I build/test/lint project X?"
|
||||
|
||||
```bash
|
||||
nx show project X --json | jq '.targets | keys'
|
||||
nx show project X --json | jq '.targets.build'
|
||||
```
|
||||
|
||||
### "What depends on library Y?"
|
||||
|
||||
```bash
|
||||
# Find projects that may depend on Y by searching for imports
|
||||
# (Nx doesn't have a direct "dependents" command via CLI)
|
||||
grep -r "from '@myorg/Y'" --include="*.ts" --include="*.tsx" apps/ libs/
|
||||
```
|
||||
|
||||
### "What configuration options are available?"
|
||||
|
||||
```bash
|
||||
cat node_modules/nx/schemas/nx-schema.json | jq '.properties | keys'
|
||||
cat node_modules/nx/schemas/project-schema.json | jq '.properties | keys'
|
||||
```
|
||||
|
||||
### "Why is project X affected?"
|
||||
|
||||
```bash
|
||||
# Check what files changed
|
||||
git diff --name-only main
|
||||
|
||||
# See which project owns those files
|
||||
nx show project X --json | jq '.root'
|
||||
```
|
||||
@@ -1,10 +0,0 @@
|
||||
#
|
||||
# https://help.github.com/articles/dealing-with-line-endings/
|
||||
#
|
||||
# Linux start script should use lf
|
||||
/gradlew text eol=lf
|
||||
# These are Windows script files and should use crlf
|
||||
*.bat text eol=crlf
|
||||
# Exclude files from Graphite reviews
|
||||
docs/generated/* linguist-generated=true
|
||||
*.pdf,*.gif,*.mp4,*.webp,*.avif,*.png,*.jpeg,*.jpg,*.tiff filter=lfs diff=lfs merge=lfs -text
|
||||
@@ -1,7 +1,6 @@
|
||||
name: 🐞 Bug Report
|
||||
description: This form is to report unexpected behavior in Nx.
|
||||
labels: ["type: bug"]
|
||||
type: Bug
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
@@ -60,7 +59,7 @@ body:
|
||||
label: Package Manager Version
|
||||
description: |
|
||||
If `nx report` doesn't work, please provide the name and the version of your package manager.
|
||||
You can get version information by running `PACKAGE_MANAGER --version`, where PACKAGE_MANAGER is any of `yarn`, `pnpm`, `bun` or `npm`, depending on the package manager used.
|
||||
You can get version information by running `yarn --version`, `pnpm --version` or `npm --version`, depending on the package manager used.
|
||||
- type: checkboxes
|
||||
id: os
|
||||
attributes:
|
||||
|
||||
@@ -28,12 +28,12 @@ Note: We reserve the right to remove unmaintained plugins from the registry. If
|
||||
|
||||
## Steps to Submit Your Plugin
|
||||
- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]`
|
||||
- Update the `astro-docs/src/content/approved-community-plugins.json` file with a new entry for your plugin that includes `name`, `url`, `description`:
|
||||
- Update the `community/approved-plugins.json` file with a new entry for your plugin that includes `name`, `url`, `description`:
|
||||
|
||||
Example:
|
||||
|
||||
```json
|
||||
// astro-docs/src/content/approved-community-plugins.json
|
||||
// community/approved-plugins.json
|
||||
|
||||
[{
|
||||
"name": "@community/plugin",
|
||||
@@ -42,7 +42,7 @@ Example:
|
||||
}]
|
||||
```
|
||||
|
||||
Once merged, your plugin will be available when running the `nx list` command, and will also be available in the Plugin Registry on [nx.dev](https://nx.dev/docs/plugin-registry)
|
||||
Once merged, your plugin will be available when running the `nx list` command, and will also be available in the Plugin Registry on [nx.dev](https://nx.dev/plugin-registry)
|
||||
-->
|
||||
|
||||
# Community Plugin Submission
|
||||
|
||||
@@ -1,478 +0,0 @@
|
||||
---
|
||||
description: Polls Nx Cloud CI pipeline and self-healing status. Returns structured state when actionable. Spawned by /nx-cloud-ci-monitor command to monitor CI Attempt status.
|
||||
---
|
||||
|
||||
# CI Watcher Subagent
|
||||
|
||||
You are a CI monitoring subagent responsible for polling Nx Cloud CI Attempt status and self-healing state. You report status back to the main agent - you do NOT make apply/reject decisions.
|
||||
|
||||
## Your Responsibilities
|
||||
|
||||
1. Poll CI status using the `ci_information` MCP tool
|
||||
2. Implement exponential backoff between polls
|
||||
3. Return structured state when an actionable condition is reached
|
||||
4. Track iteration count and elapsed time
|
||||
5. Output status updates based on verbosity level
|
||||
|
||||
## Input Parameters (from Main Agent)
|
||||
|
||||
The main agent may provide these optional parameters in the prompt:
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------- | -------------------------------------------------------- |
|
||||
| `branch` | Branch to monitor (auto-detected if not provided) |
|
||||
| `expectedCommitSha` | Commit SHA that should trigger a new CI Attempt |
|
||||
| `previousCipeUrl` | CI Attempt URL before the action (to detect change) |
|
||||
| `subagentTimeout` | Polling timeout in minutes (default: 60) |
|
||||
| `verbosity` | Output level: minimal, medium, verbose (default: medium) |
|
||||
|
||||
When `expectedCommitSha` or `previousCipeUrl` is provided, you must detect whether a new CI Attempt has spawned.
|
||||
|
||||
## MCP Tool Reference
|
||||
|
||||
### `ci_information`
|
||||
|
||||
**Input:**
|
||||
|
||||
```json
|
||||
{
|
||||
"branch": "string (optional, defaults to current git branch)",
|
||||
"select": "string (optional, comma-separated field names)",
|
||||
"pageToken": "number (optional, 0-based pagination for long strings)"
|
||||
}
|
||||
```
|
||||
|
||||
**Output:**
|
||||
|
||||
```json
|
||||
{
|
||||
"cipeStatus": "NOT_STARTED | IN_PROGRESS | SUCCEEDED | FAILED | CANCELED | TIMED_OUT",
|
||||
"cipeUrl": "string",
|
||||
"branch": "string",
|
||||
"commitSha": "string | null",
|
||||
"failedTaskIds": "string[]",
|
||||
"verifiedTaskIds": "string[]",
|
||||
"selfHealingEnabled": "boolean",
|
||||
"selfHealingStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
|
||||
"verificationStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
|
||||
"userAction": "NONE | APPLIED | REJECTED | APPLIED_LOCALLY | APPLIED_AUTOMATICALLY | null",
|
||||
"failureClassification": "string | null",
|
||||
"taskOutputSummary": "string | null",
|
||||
"suggestedFixReasoning": "string | null",
|
||||
"suggestedFixDescription": "string | null",
|
||||
"suggestedFix": "string | null",
|
||||
"shortLink": "string | null",
|
||||
"couldAutoApplyTasks": "boolean | null",
|
||||
"confidence": "number | null",
|
||||
"confidenceReasoning": "string | null"
|
||||
}
|
||||
```
|
||||
|
||||
**Select Parameter:**
|
||||
|
||||
| Usage | Returns |
|
||||
| --------------- | ----------------------------------------------------------- |
|
||||
| No `select` | Formatted overview (truncated, not recommended for polling) |
|
||||
| Single field | Raw value with pagination for long strings |
|
||||
| Multiple fields | Object with requested field values |
|
||||
|
||||
**Field Sets for Efficient Polling:**
|
||||
|
||||
```yaml
|
||||
WAIT_FIELDS:
|
||||
'cipeUrl,commitSha,cipeStatus'
|
||||
# Minimal fields for detecting new CI Attempt
|
||||
|
||||
LIGHT_FIELDS:
|
||||
'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning'
|
||||
# Status fields for determining actionable state
|
||||
|
||||
HEAVY_FIELDS:
|
||||
'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'
|
||||
# Large content fields - fetch only when returning to main agent
|
||||
```
|
||||
|
||||
## Initial Wait
|
||||
|
||||
Before first poll, wait based on context:
|
||||
|
||||
- **Fresh start (no expected CIPE):** Wait 60 seconds to allow CI to start
|
||||
- **Expecting new CIPE:** Wait 30 seconds (action already triggered)
|
||||
|
||||
**IMPORTANT:** Always run sleep in foreground, NOT as background command.
|
||||
|
||||
```bash
|
||||
sleep 60 # or 30 if expecting new CIPE (FOREGROUND, not background)
|
||||
```
|
||||
|
||||
## Two-Phase Operation
|
||||
|
||||
The subagent operates in one of two modes depending on input:
|
||||
|
||||
### Mode 1: Fresh Start (no `expectedCommitSha` or `previousCipeUrl`)
|
||||
|
||||
Normal polling - process whatever CIPE is returned by `ci_information`.
|
||||
|
||||
### Mode 2: Wait-for-New-CIPE (when `expectedCommitSha` or `previousCipeUrl` provided)
|
||||
|
||||
**CRITICAL**: When expecting a new CIPE, the subagent must **completely ignore** the old/stale CIPE. Do NOT process its status, do NOT return actionable states based on it.
|
||||
|
||||
#### Phase A: Wait Mode
|
||||
|
||||
1. Start a **new-CIPE timeout** timer (default: 30 minutes)
|
||||
2. On each poll of `ci_information`:
|
||||
- Check if CIPE is NEW:
|
||||
- `cipeUrl` differs from `previousCipeUrl` → **new CIPE detected**
|
||||
- `commitSha` matches `expectedCommitSha` → **correct CIPE detected**
|
||||
- If still OLD CIPE: **ignore all status fields**, just wait and poll again
|
||||
- Do NOT return `fix_available`, `ci_success`, etc. based on old CIPE!
|
||||
3. Output wait status (see below)
|
||||
4. If timeout (30 min) reached → return `no_new_cipe`
|
||||
|
||||
#### Phase B: Normal Polling (after new CIPE detected)
|
||||
|
||||
Once new CIPE is detected:
|
||||
|
||||
1. Clear the new-CIPE timeout
|
||||
2. Switch to normal polling mode
|
||||
3. Process the NEW CIPE's status normally
|
||||
4. Return when actionable state reached
|
||||
|
||||
### Wait Mode Output
|
||||
|
||||
While in wait mode, output clearly that you're waiting (not processing):
|
||||
|
||||
```
|
||||
[CI Monitor] ═══════════════════════════════════════════════════════
|
||||
[CI Monitor] WAIT MODE - Expecting new CI Attempt
|
||||
[CI Monitor] Expected SHA: <expectedCommitSha>
|
||||
[CI Monitor] Previous CI Attempt: <previousCipeUrl>
|
||||
[CI Monitor] ═══════════════════════════════════════════════════════
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 0m 30s)
|
||||
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 1m 30s)
|
||||
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 2m 30s)
|
||||
[CI Monitor] ✓ New CI Attempt detected! URL: <newCipeUrl>, SHA: <newCommitSha>
|
||||
[CI Monitor] Switching to normal polling mode...
|
||||
```
|
||||
|
||||
### Why This Matters (Context Preservation)
|
||||
|
||||
**The problem**: Stale CIPE data can be very large:
|
||||
|
||||
- `taskOutputSummary`: potentially thousands of characters of build/test output
|
||||
- `suggestedFix`: entire patch files
|
||||
- `suggestedFixReasoning`: detailed explanation
|
||||
|
||||
If subagent returns stale CIPE data to main agent, it **pollutes main agent's context** with useless information (we already processed that CIPE). This wastes valuable context window.
|
||||
|
||||
**Without wait mode:**
|
||||
|
||||
1. Poll `ci_information` → get old CIPE with huge data
|
||||
2. Return to main agent with all that stale data
|
||||
3. Main agent's context gets polluted with useless info
|
||||
4. Main agent has to process/ignore it anyway
|
||||
|
||||
**With wait mode:**
|
||||
|
||||
1. Poll `ci_information` → get old CIPE → **ignore it, don't return**
|
||||
2. Keep waiting internally (stale data stays in subagent)
|
||||
3. New CIPE appears → switch to normal mode
|
||||
4. Return to main agent with only the NEW, relevant CIPE data
|
||||
|
||||
## Polling Loop
|
||||
|
||||
### Subagent State Management
|
||||
|
||||
Maintain internal accumulated state across polls:
|
||||
|
||||
```
|
||||
accumulated_state = {}
|
||||
```
|
||||
|
||||
### Call `ci_information` MCP Tool
|
||||
|
||||
**Wait Mode (expecting new CI Attempt):**
|
||||
|
||||
```
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "cipeUrl,commitSha,cipeStatus"
|
||||
})
|
||||
```
|
||||
|
||||
Only fetch minimal fields needed to detect CI Attempt change. Do NOT fetch heavy fields - stale data wastes context.
|
||||
|
||||
**Normal Mode (processing CI Attempt):**
|
||||
|
||||
```
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning"
|
||||
})
|
||||
```
|
||||
|
||||
Merge response into `accumulated_state` after each poll.
|
||||
|
||||
### Analyze Response
|
||||
|
||||
**If in Wait Mode** (expecting new CIPE):
|
||||
|
||||
1. Check if CIPE is new (see Two-Phase Operation above)
|
||||
2. If old CIPE → **ignore status**, output wait message, poll again
|
||||
3. If new CIPE → switch to normal mode, continue below
|
||||
|
||||
**If in Normal Mode**:
|
||||
Based on the response, decide whether to **keep polling** or **return to main agent**.
|
||||
|
||||
### Keep Polling When
|
||||
|
||||
Continue polling (with backoff) if ANY of these conditions are true:
|
||||
|
||||
| Condition | Reason |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| `cipeStatus == 'IN_PROGRESS'` | CI still running |
|
||||
| `cipeStatus == 'NOT_STARTED'` | CI hasn't started yet |
|
||||
| `selfHealingStatus == 'IN_PROGRESS'` | Self-healing agent working |
|
||||
| `selfHealingStatus == 'NOT_STARTED'` | Self-healing not started yet |
|
||||
| `failureClassification == 'FLAKY_TASK'` | Auto-rerun in progress |
|
||||
| `userAction == 'APPLIED_AUTOMATICALLY'` | New CI Attempt spawning after auto-apply |
|
||||
|
||||
When `couldAutoApplyTasks == true`:
|
||||
|
||||
- `verificationStatus` = `NOT_STARTED`, `IN_PROGRESS` → keep polling (verification still in progress)
|
||||
- `verificationStatus` = `COMPLETED` → return `fix_auto_applying` (auto-apply will happen, main agent spawns wait mode subagent)
|
||||
- `verificationStatus` = `FAILED`, `NOT_EXECUTABLE` → return `fix_available` (auto-apply won't happen, needs manual action)
|
||||
|
||||
### Exponential Backoff
|
||||
|
||||
Between polls, wait with exponential backoff:
|
||||
|
||||
| Poll Attempt | Wait Time |
|
||||
| ------------ | ----------------- |
|
||||
| 1st | 60 seconds |
|
||||
| 2nd | 90 seconds |
|
||||
| 3rd+ | 120 seconds (cap) |
|
||||
|
||||
Reset to 60 seconds when state changes significantly.
|
||||
|
||||
**IMPORTANT:** Run sleep in foreground (NOT as background command). Background sleep causes "What should Claude do?" prompts when completed.
|
||||
|
||||
```bash
|
||||
# Example backoff - run in FOREGROUND
|
||||
sleep 60 # First wait
|
||||
sleep 90 # Second wait
|
||||
sleep 120 # Third and subsequent waits (capped)
|
||||
```
|
||||
|
||||
### Fetch Heavy Fields on Actionable State
|
||||
|
||||
Before returning to main agent, fetch heavy fields if the status requires them:
|
||||
|
||||
| Status | Heavy Fields Needed |
|
||||
| ------------------- | ------------------------------------------------------------------------------ |
|
||||
| `ci_success` | None |
|
||||
| `fix_auto_applying` | None |
|
||||
| `fix_available` | `taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription` |
|
||||
| `fix_failed` | `taskOutputSummary` |
|
||||
| `no_fix` | `taskOutputSummary` |
|
||||
| `environment_issue` | None |
|
||||
| `no_new_cipe` | None |
|
||||
| `polling_timeout` | None |
|
||||
| `cipe_canceled` | None |
|
||||
| `cipe_timed_out` | None |
|
||||
|
||||
```
|
||||
# Example: fetching heavy fields for fix_available
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription"
|
||||
})
|
||||
```
|
||||
|
||||
Merge response into `accumulated_state`, then return merged state to main agent.
|
||||
|
||||
**Pagination:** Heavy string fields return first page only. If `hasMore` indicated, include in return format so main agent knows more content available.
|
||||
|
||||
### Return to Main Agent When
|
||||
|
||||
Return immediately with structured state if ANY of these conditions are true:
|
||||
|
||||
| Status | Condition |
|
||||
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | `cipeStatus == 'SUCCEEDED'` |
|
||||
| `fix_auto_applying` | `selfHealingStatus == 'COMPLETED'` AND `couldAutoApplyTasks == true` AND `verificationStatus == 'COMPLETED'` |
|
||||
| `fix_available` | `selfHealingStatus == 'COMPLETED'` AND `suggestedFix != null` AND (`couldAutoApplyTasks != true` OR `verificationStatus` in (`FAILED`, `NOT_EXECUTABLE`)) |
|
||||
| `fix_failed` | `selfHealingStatus == 'FAILED'` |
|
||||
| `environment_issue` | `failureClassification == 'ENVIRONMENT_STATE'` |
|
||||
| `no_fix` | `cipeStatus == 'FAILED'` AND (`selfHealingEnabled == false` OR `selfHealingStatus == 'NOT_EXECUTABLE'`) |
|
||||
| `no_new_cipe` | `expectedCommitSha` or `previousCipeUrl` provided, but no new CI Attempt detected after 30 min |
|
||||
| `polling_timeout` | Subagent has been polling for > configured timeout (default 60 min) |
|
||||
| `cipe_canceled` | `cipeStatus == 'CANCELED'` |
|
||||
| `cipe_timed_out` | `cipeStatus == 'TIMED_OUT'` |
|
||||
|
||||
## Subagent Timeout
|
||||
|
||||
Track elapsed time. If you have been polling for more than **60 minutes** (configurable via main agent), return with `status: polling_timeout`.
|
||||
|
||||
## Return Format
|
||||
|
||||
When returning to the main agent, provide a structured response with accumulated state:
|
||||
|
||||
```
|
||||
## CI Monitor Result
|
||||
|
||||
**Status:** <status>
|
||||
**Iterations:** <count>
|
||||
**Elapsed:** <minutes>m <seconds>s
|
||||
|
||||
### CI Attempt Details
|
||||
- **Status:** <cipeStatus>
|
||||
- **URL:** <cipeUrl>
|
||||
- **Branch:** <branch>
|
||||
- **Commit:** <commitSha>
|
||||
- **Failed Tasks:** <failedTaskIds>
|
||||
- **Verified Tasks:** <verifiedTaskIds>
|
||||
|
||||
### Self-Healing Details
|
||||
- **Enabled:** <selfHealingEnabled>
|
||||
- **Status:** <selfHealingStatus>
|
||||
- **Verification:** <verificationStatus>
|
||||
- **User Action:** <userAction>
|
||||
- **Classification:** <failureClassification>
|
||||
- **Confidence:** <confidence>
|
||||
- **Confidence Reasoning:** <confidenceReasoning>
|
||||
|
||||
### Fix Information (if available)
|
||||
- **Short Link:** <shortLink>
|
||||
- **Description:** <suggestedFixDescription>
|
||||
- **Reasoning:** <suggestedFixReasoning>
|
||||
|
||||
### Task Output Summary (first page)
|
||||
<taskOutputSummary>
|
||||
[MORE_CONTENT_AVAILABLE: taskOutputSummary, pageToken: 1]
|
||||
|
||||
### Suggested Fix (first page)
|
||||
<suggestedFix>
|
||||
[MORE_CONTENT_AVAILABLE: suggestedFix, pageToken: 1]
|
||||
```
|
||||
|
||||
### Pagination Indicators
|
||||
|
||||
When a heavy field has more content available, append indicator:
|
||||
|
||||
```
|
||||
[MORE_CONTENT_AVAILABLE: <fieldName>, pageToken: <nextPage>]
|
||||
```
|
||||
|
||||
Main agent can fetch additional pages if needed using:
|
||||
|
||||
```
|
||||
ci_information({ select: "<fieldName>", pageToken: <nextPage> })
|
||||
```
|
||||
|
||||
Fields that may have pagination:
|
||||
|
||||
- `taskOutputSummary` (reverse pagination - page 0 = most recent)
|
||||
- `suggestedFix` (forward pagination - page 0 = start)
|
||||
- `suggestedFixReasoning`
|
||||
|
||||
### Return Format for `no_new_cipe`
|
||||
|
||||
When returning with `status: no_new_cipe`, include additional context:
|
||||
|
||||
```
|
||||
## CI Monitor Result
|
||||
|
||||
**Status:** no_new_cipe
|
||||
**Iterations:** <count>
|
||||
**Elapsed:** <minutes>m <seconds>s
|
||||
|
||||
### Expected CI Attempt Not Found
|
||||
- **Expected Commit SHA:** <expectedCommitSha>
|
||||
- **Previous CI Attempt URL:** <previousCipeUrl>
|
||||
- **Last Seen CI Attempt URL:** <cipeUrl>
|
||||
- **Last Seen Commit SHA:** <commitSha>
|
||||
- **New CI Attempt Timeout:** 30 minutes (exceeded)
|
||||
|
||||
### Likely Cause
|
||||
CI workflow failed before Nx tasks could run (e.g., install step, checkout, auth).
|
||||
Check your CI provider logs for the commit <expectedCommitSha>.
|
||||
|
||||
### Last Known CI Attempt State
|
||||
- **Status:** <cipeStatus>
|
||||
- **Branch:** <branch>
|
||||
```
|
||||
|
||||
## Status Reporting (Verbosity-Controlled)
|
||||
|
||||
Output is controlled by the `verbosity` parameter from the main agent:
|
||||
|
||||
| Level | What to Output |
|
||||
| --------- | ----------------------------------------------------------------- |
|
||||
| `minimal` | No intermediate output. Only return final result when actionable. |
|
||||
| `medium` | Output only on significant state changes (not every poll). |
|
||||
| `verbose` | Output detailed phase information after every poll. |
|
||||
|
||||
### Minimal Verbosity
|
||||
|
||||
No output during polling. Poll silently and return when done.
|
||||
|
||||
### Medium Verbosity (Default)
|
||||
|
||||
Output **only when state changes significantly** to save context tokens:
|
||||
|
||||
- `cipeStatus` changes (e.g., IN_PROGRESS → FAILED)
|
||||
- `selfHealingStatus` changes (e.g., IN_PROGRESS → COMPLETED)
|
||||
- New CI Attempt detected (in wait mode)
|
||||
|
||||
Format: single line, no decorators:
|
||||
|
||||
```
|
||||
[CI Monitor] CI: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 4m
|
||||
```
|
||||
|
||||
### Verbose Verbosity
|
||||
|
||||
Output detailed phase box after every poll:
|
||||
|
||||
```
|
||||
[CI Monitor] ─────────────────────────────────────────────────────
|
||||
[CI Monitor] Iteration <N> | Elapsed: <X>m <Y>s
|
||||
[CI Monitor]
|
||||
[CI Monitor] CI Status: <cipeStatus>
|
||||
[CI Monitor] Self-Healing: <selfHealingStatus>
|
||||
[CI Monitor] Verification: <verificationStatus>
|
||||
[CI Monitor] Classification: <failureClassification>
|
||||
[CI Monitor]
|
||||
[CI Monitor] → <human-readable phase description>
|
||||
[CI Monitor] ─────────────────────────────────────────────────────
|
||||
```
|
||||
|
||||
### Phase Descriptions (for verbose output)
|
||||
|
||||
| Status Combo | Description |
|
||||
| ----------------------------------------------------------------------------------------- | ------------------------------------------- |
|
||||
| `cipeStatus: IN_PROGRESS` | "CI running..." |
|
||||
| `cipeStatus: NOT_STARTED` | "Waiting for CI to start..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: NOT_STARTED` | "CI failed. Self-healing starting..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: IN_PROGRESS` | "CI failed. Self-healing generating fix..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: IN_PROGRESS` | "Fix generated! Verification running..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: COMPLETED` | "Fix ready! Verified successfully." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: FAILED` | "Fix generated but verification failed." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: FAILED` | "Self-healing could not generate a fix." |
|
||||
| `cipeStatus: SUCCEEDED` | "CI passed!" |
|
||||
|
||||
## Important Notes
|
||||
|
||||
- You do NOT make apply/reject decisions - that's the main agent's job
|
||||
- You do NOT perform git operations
|
||||
- You only poll and report state
|
||||
- Respect the `verbosity` parameter for output (default: medium)
|
||||
- If `ci_information` returns an error, wait and retry (count as failed poll)
|
||||
- Track consecutive failures - if 5 consecutive failures, return with `status: error`
|
||||
- When expecting new CI Attempt, track the 30-minute new-CI-Attempt timeout separately from the main polling timeout
|
||||
@@ -1,18 +0,0 @@
|
||||
# This configuration is here to prevent false positive alerts for __fixtures__.
|
||||
# We are intentionally disabling the PR opening feature.
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: 'npm'
|
||||
directory: '/'
|
||||
schedule:
|
||||
interval: 'weekly'
|
||||
open-pull-requests-limit: 0
|
||||
exclude-paths:
|
||||
- '**/__fixtures__/**'
|
||||
|
||||
- package-ecosystem: 'github-actions'
|
||||
directory: '/'
|
||||
schedule:
|
||||
interval: 'weekly'
|
||||
open-pull-requests-limit: 0
|
||||
@@ -1,437 +0,0 @@
|
||||
---
|
||||
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
|
||||
argument-hint: '[instructions] [--max-cycles N] [--timeout MINUTES] [--verbosity minimal|medium|verbose] [--branch BRANCH] [--fresh] [--auto-fix-workflow] [--new-cipe-timeout MINUTES]'
|
||||
---
|
||||
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
${input:args}
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
Parse any overrides from `${input:args}` and merge with defaults.
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \| Elapsed: Xm \| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```
|
||||
@@ -1,437 +0,0 @@
|
||||
---
|
||||
name: ci-monitor
|
||||
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
|
||||
---
|
||||
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
Parse any overrides from `$ARGUMENTS` and merge with defaults.
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \| Elapsed: Xm \| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```
|
||||
@@ -1,228 +0,0 @@
|
||||
---
|
||||
name: nx-generate
|
||||
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
|
||||
---
|
||||
|
||||
# Run Nx Generator
|
||||
|
||||
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
|
||||
|
||||
This skill applies when the user wants to:
|
||||
|
||||
- Create new projects like libraries or applications
|
||||
- Scaffold features or boilerplate code
|
||||
- Run workspace-specific or custom generators
|
||||
- Do anything else that an nx generator exists for
|
||||
|
||||
## Generator Discovery Flow
|
||||
|
||||
### Step 1: List Available Generators
|
||||
|
||||
Use the Nx CLI to discover available generators:
|
||||
|
||||
- List all generators for a plugin: `npx nx list @nx/react`
|
||||
- View available plugins: `npx nx list`
|
||||
|
||||
This includes:
|
||||
|
||||
- Plugin generators (e.g., `@nx/react:library`, `@nx/js:library`)
|
||||
- Local workspace generators (defined in the repo's own plugins)
|
||||
|
||||
### Step 2: Match Generator to User Request
|
||||
|
||||
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
|
||||
|
||||
- What artifact type they want to create (library, application, etc.)
|
||||
- Which framework or technology stack is relevant
|
||||
- Whether they mentioned specific generator names
|
||||
|
||||
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
|
||||
|
||||
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
|
||||
|
||||
## Pre-Execution Checklist
|
||||
|
||||
Before running any generator, complete these steps:
|
||||
|
||||
### 1. Fetch Generator Schema
|
||||
|
||||
Use the `--help` flag to understand all available options:
|
||||
|
||||
```bash
|
||||
npx nx g @nx/react:library --help
|
||||
```
|
||||
|
||||
Pay attention to:
|
||||
|
||||
- Required options that must be provided
|
||||
- Optional options that may be relevant to the user's request
|
||||
- Default values that might need to be overridden
|
||||
|
||||
### 2. Read Generator Source Code
|
||||
|
||||
Understanding what the generator actually does helps you:
|
||||
|
||||
- Know what files will be created/modified
|
||||
- Understand any side effects (updating configs, installing deps, etc.)
|
||||
- Identify options that might not be obvious from the schema
|
||||
|
||||
To find generator source code:
|
||||
|
||||
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
|
||||
- If that fails, read directly from `node_modules/<plugin>/generators.json`
|
||||
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
|
||||
|
||||
### 2.5 Reevaluate if the generator is right
|
||||
|
||||
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
|
||||
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
|
||||
|
||||
### 3. Understand Repo Context
|
||||
|
||||
Before generating, examine the target area of the codebase:
|
||||
|
||||
- Look at similar existing artifacts (other libraries, applications, etc.)
|
||||
- Identify patterns and conventions used in the repo
|
||||
- Note naming conventions, file structures, and configuration patterns
|
||||
- Try to match these patterns when configuring the generator
|
||||
|
||||
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
|
||||
If projects or other artifacts are organized with a specific naming convention, try to match it.
|
||||
|
||||
### 4. Validate Required Options
|
||||
|
||||
Ensure all required options have values:
|
||||
|
||||
- Map the user's request to generator options
|
||||
- Infer values from context where possible
|
||||
- Ask the user for any critical missing information
|
||||
|
||||
## Execution
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
|
||||
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
|
||||
|
||||
### Consider Dry-Run (Optional)
|
||||
|
||||
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
|
||||
|
||||
- For complex generators or unfamiliar territory: do a dry-run first
|
||||
- For simple, well-understood generators: may proceed directly
|
||||
- Dry-run shows file names and created/deleted/modified markers, but not content
|
||||
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
|
||||
|
||||
### Running the Generator
|
||||
|
||||
Execute the generator with:
|
||||
|
||||
```bash
|
||||
nx generate <generator-name> <options> --no-interactive
|
||||
```
|
||||
|
||||
**CRITICAL**: Always include `--no-interactive` to prevent prompts that would hang the execution.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx generate @nx/react:library --name=my-utils --no-interactive
|
||||
```
|
||||
|
||||
### Handling Generator Failures
|
||||
|
||||
If the generator fails:
|
||||
|
||||
1. **Diagnose the error** - Read the error message carefully
|
||||
2. **Identify the cause** - Missing options, invalid values, conflicts, etc.
|
||||
3. **Attempt automatic fix** - Adjust options or resolve conflicts
|
||||
4. **Retry** - Run the generator again with corrected options
|
||||
|
||||
Common failure reasons:
|
||||
|
||||
- Missing required options
|
||||
- Invalid option values
|
||||
- Conflicting with existing files
|
||||
- Missing dependencies
|
||||
- Generator doesn't support certain flag combinations
|
||||
|
||||
## Post-Generation
|
||||
|
||||
### 1. Modify Generated Code (If Needed)
|
||||
|
||||
Generators provide a starting point, but the output may need adjustment to match the user's specific requirements:
|
||||
|
||||
- Add or modify functionality as requested
|
||||
- Adjust imports, exports, or configurations
|
||||
- Integrate with existing code patterns in the repo
|
||||
|
||||
### 2. Format Code
|
||||
|
||||
Run formatting on all generated/modified files:
|
||||
|
||||
```bash
|
||||
nx format --fix
|
||||
```
|
||||
|
||||
Languages other than javascript/typescript might need other formatting invocations too.
|
||||
|
||||
### 3. Run Verification
|
||||
|
||||
Verify that the generated code works correctly. What this looks like will vary depending on the type of generator and the targets available.
|
||||
If the generator created a new project, run its targets directly
|
||||
Use your best judgement to determine what needs to be verified.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx lint <new-project>
|
||||
nx test <new-project>
|
||||
nx build <new-project>
|
||||
```
|
||||
|
||||
### 4. Handle Verification Failures
|
||||
|
||||
When verification fails:
|
||||
|
||||
**If scope is manageable** (a few lint errors, minor type issues):
|
||||
|
||||
- Fix the issues
|
||||
- Re-run verification to confirm
|
||||
|
||||
**If issues are extensive** (many errors, complex problems):
|
||||
|
||||
- Attempt simple, obvious fixes first
|
||||
- If still failing, escalate to the user with:
|
||||
- Description of what was generated
|
||||
- What verification is failing
|
||||
- What you've attempted to fix
|
||||
- Remaining issues that need user input
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Generator Failures
|
||||
|
||||
- Check the error message for specific causes
|
||||
- Verify all required options are provided
|
||||
- Check for conflicts with existing files
|
||||
- Ensure the generator name and options are correct
|
||||
|
||||
### Missing Options
|
||||
|
||||
- Consult the generator schema for required fields
|
||||
- Infer values from context when reasonable
|
||||
- Ask the user for values that cannot be inferred
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Local generators first** - Always prefer workspace/local generators over external plugin generators when both could work
|
||||
|
||||
2. **Understand before running** - Read both the schema AND the source code to fully understand what will happen
|
||||
|
||||
3. **No prompts** - Always use `--no-interactive` to prevent hanging
|
||||
|
||||
4. **Generators are starting points** - Modify the output as needed to fully satisfy the user's requirements
|
||||
|
||||
5. **Verify changes work** - Don't just generate; ensure the code builds, lints, and tests pass
|
||||
|
||||
6. **Be proactive about fixes** - Don't just report errors; attempt to resolve them automatically when possible
|
||||
|
||||
7. **Match repo patterns** - Study existing similar code in the repo and match its conventions
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
name: nx-plugins
|
||||
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
|
||||
---
|
||||
|
||||
## Finding and Installing new plugins
|
||||
|
||||
- List plugins: `pnpm nx list`
|
||||
- Install plugins `pnpm nx add <plugin>`. Example: `pnpm nx add @nx/react`.
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
name: nx-run-tasks
|
||||
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
|
||||
---
|
||||
|
||||
You can run tasks with Nx in the following way.
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
|
||||
|
||||
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
|
||||
|
||||
## Understand which tasks can be run
|
||||
|
||||
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
|
||||
|
||||
## Run a single task
|
||||
|
||||
```
|
||||
nx run <project>:<task>
|
||||
```
|
||||
|
||||
where `project` is the project name defined in `package.json` or `project.json` (if present).
|
||||
|
||||
## Run multiple tasks
|
||||
|
||||
```
|
||||
nx run-many -t build test lint typecheck
|
||||
```
|
||||
|
||||
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
|
||||
|
||||
Examples:
|
||||
|
||||
- `nx run-many -t test -p proj1 proj2` — test specific projects
|
||||
- `nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
|
||||
- `nx run-many -t test --projects=tag:api-*` — test projects by tag
|
||||
|
||||
## Run tasks for affected projects
|
||||
|
||||
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
|
||||
|
||||
```
|
||||
nx affected -t build test lint
|
||||
```
|
||||
|
||||
By default it compares against the base branch. You can customize this:
|
||||
|
||||
- `nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
|
||||
- `nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
|
||||
|
||||
## Useful flags
|
||||
|
||||
These flags work with `run`, `run-many`, and `affected`:
|
||||
|
||||
- `--skipNxCache` — rerun tasks even when results are cached
|
||||
- `--verbose` — print additional information such as stack traces
|
||||
- `--nxBail` — stop execution after the first failed task
|
||||
- `--configuration=<name>` — use a specific configuration (e.g. `production`)
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
name: nx-workspace
|
||||
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
|
||||
---
|
||||
|
||||
# Nx Workspace Exploration
|
||||
|
||||
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
|
||||
|
||||
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
|
||||
|
||||
## Listing Projects
|
||||
|
||||
Use `nx show projects` to list projects in the workspace.
|
||||
|
||||
```bash
|
||||
# List all projects
|
||||
nx show projects
|
||||
|
||||
# Filter by pattern (glob)
|
||||
nx show projects --projects "apps/*"
|
||||
nx show projects --projects "shared-*"
|
||||
|
||||
# Filter by project type
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
nx show projects --type e2e
|
||||
|
||||
# Filter by target (projects that have a specific target)
|
||||
nx show projects --withTarget build
|
||||
nx show projects --withTarget e2e
|
||||
|
||||
# Find affected projects (changed since base branch)
|
||||
nx show projects --affected
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Combine filters
|
||||
nx show projects --type lib --withTarget test
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Output as JSON
|
||||
nx show projects --json
|
||||
```
|
||||
|
||||
## Project Configuration
|
||||
|
||||
Use `nx show project <name> --json` to get the full resolved configuration for a project.
|
||||
|
||||
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
|
||||
|
||||
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Get full project configuration
|
||||
nx show project my-app --json
|
||||
|
||||
# Extract specific parts from the JSON
|
||||
nx show project my-app --json | jq '.targets'
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
|
||||
# Check project metadata
|
||||
nx show project my-app --json | jq '{name, root, sourceRoot, projectType, tags}'
|
||||
```
|
||||
|
||||
## Target Information
|
||||
|
||||
Targets define what tasks can be run on a project.
|
||||
|
||||
```bash
|
||||
# List all targets for a project
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
# Get full target configuration
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
|
||||
# Check target executor/command
|
||||
nx show project my-app --json | jq '.targets.build.executor'
|
||||
nx show project my-app --json | jq '.targets.build.command'
|
||||
|
||||
# View target options
|
||||
nx show project my-app --json | jq '.targets.build.options'
|
||||
|
||||
# Check target inputs/outputs (for caching)
|
||||
nx show project my-app --json | jq '.targets.build.inputs'
|
||||
nx show project my-app --json | jq '.targets.build.outputs'
|
||||
|
||||
# Find projects with a specific target
|
||||
nx show projects --withTarget serve
|
||||
nx show projects --withTarget e2e
|
||||
```
|
||||
|
||||
## Workspace Configuration
|
||||
|
||||
Read `nx.json` directly for workspace-level configuration.
|
||||
You can read the full project schema at `node_modules/nx/schemas/nx-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Read the full nx.json
|
||||
cat nx.json
|
||||
|
||||
# Or use jq for specific sections
|
||||
cat nx.json | jq '.targetDefaults'
|
||||
cat nx.json | jq '.namedInputs'
|
||||
cat nx.json | jq '.plugins'
|
||||
cat nx.json | jq '.generators'
|
||||
```
|
||||
|
||||
Key nx.json sections:
|
||||
|
||||
- `targetDefaults` - Default configuration applied to all targets of a given name
|
||||
- `namedInputs` - Reusable input definitions for caching
|
||||
- `plugins` - Nx plugins and their configuration
|
||||
- ...and much more, read the schema or nx.json for details
|
||||
|
||||
## Affected Projects
|
||||
|
||||
Find projects affected by changes in the current branch.
|
||||
|
||||
```bash
|
||||
# Affected since base branch (auto-detected)
|
||||
nx show projects --affected
|
||||
|
||||
# Affected with explicit base
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --base=origin/main
|
||||
|
||||
# Affected between two commits
|
||||
nx show projects --affected --base=abc123 --head=def456
|
||||
|
||||
# Affected apps only
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Affected excluding e2e projects
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Affected by uncommitted changes
|
||||
nx show projects --affected --uncommitted
|
||||
|
||||
# Affected by untracked files
|
||||
nx show projects --affected --untracked
|
||||
```
|
||||
|
||||
## Common Exploration Patterns
|
||||
|
||||
### "What's in this workspace?"
|
||||
|
||||
```bash
|
||||
nx show projects
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
```
|
||||
|
||||
### "How do I build/test/lint project X?"
|
||||
|
||||
```bash
|
||||
nx show project X --json | jq '.targets | keys'
|
||||
nx show project X --json | jq '.targets.build'
|
||||
```
|
||||
|
||||
### "What depends on library Y?"
|
||||
|
||||
```bash
|
||||
# Find projects that may depend on Y by searching for imports
|
||||
# (Nx doesn't have a direct "dependents" command via CLI)
|
||||
grep -r "from '@myorg/Y'" --include="*.ts" --include="*.tsx" apps/ libs/
|
||||
```
|
||||
|
||||
### "What configuration options are available?"
|
||||
|
||||
```bash
|
||||
cat node_modules/nx/schemas/nx-schema.json | jq '.properties | keys'
|
||||
cat node_modules/nx/schemas/project-schema.json | jq '.properties | keys'
|
||||
```
|
||||
|
||||
### "Why is project X affected?"
|
||||
|
||||
```bash
|
||||
# Check what files changed
|
||||
git diff --name-only main
|
||||
|
||||
# See which project owns those files
|
||||
nx show project X --json | jq '.root'
|
||||
```
|
||||
@@ -1,92 +0,0 @@
|
||||
name: Banner Content Monitor
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: '*/15 * * * *'
|
||||
workflow_dispatch: # Allow manual trigger
|
||||
|
||||
permissions: {}
|
||||
|
||||
env:
|
||||
BANNER_URL: ${{ vars.BANNER_URL }}
|
||||
|
||||
jobs:
|
||||
check-and-deploy:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Fetch banner content and compute hash
|
||||
id: banner
|
||||
run: |
|
||||
if [ -z "$BANNER_URL" ]; then
|
||||
echo "BANNER_URL is not set"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Fetch content and compute hash
|
||||
CONTENT_HASH=$(curl -sf "$BANNER_URL" | sha256sum | cut -d' ' -f1)
|
||||
|
||||
if [ -z "$CONTENT_HASH" ]; then
|
||||
echo "Failed to fetch banner content"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "current_hash=$CONTENT_HASH" >> $GITHUB_OUTPUT
|
||||
echo "Current banner hash: $CONTENT_HASH"
|
||||
|
||||
- name: Restore cached hash
|
||||
id: cache
|
||||
uses: actions/cache/restore@v4
|
||||
with:
|
||||
path: .banner-hash
|
||||
key: banner-content-hash-
|
||||
restore-keys: |
|
||||
banner-content-hash-
|
||||
|
||||
- name: Compare hashes
|
||||
id: compare
|
||||
run: |
|
||||
CURRENT_HASH="${{ steps.banner.outputs.current_hash }}"
|
||||
|
||||
if [ -f .banner-hash ]; then
|
||||
CACHED_HASH=$(cat .banner-hash)
|
||||
echo "Cached hash: $CACHED_HASH"
|
||||
else
|
||||
CACHED_HASH=""
|
||||
echo "No cached hash found"
|
||||
fi
|
||||
|
||||
if [ "$CURRENT_HASH" != "$CACHED_HASH" ]; then
|
||||
echo "changed=true" >> $GITHUB_OUTPUT
|
||||
echo "Banner content has changed!"
|
||||
else
|
||||
echo "changed=false" >> $GITHUB_OUTPUT
|
||||
echo "Banner content unchanged"
|
||||
fi
|
||||
|
||||
- name: Trigger Netlify deploys
|
||||
if: steps.compare.outputs.changed == 'true'
|
||||
env:
|
||||
NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
|
||||
run: |
|
||||
npm install -g netlify-cli
|
||||
|
||||
echo "Triggering nx-docs deploy..."
|
||||
netlify deploy --trigger --prod -s nx-docs
|
||||
|
||||
echo "Triggering nx-dev deploy..."
|
||||
netlify deploy --trigger --prod -s nx-dev
|
||||
|
||||
echo "Both deploys triggered successfully"
|
||||
|
||||
- name: Save new hash to cache
|
||||
if: steps.compare.outputs.changed == 'true'
|
||||
run: |
|
||||
echo "${{ steps.banner.outputs.current_hash }}" > .banner-hash
|
||||
|
||||
- name: Update cache
|
||||
if: steps.compare.outputs.changed == 'true'
|
||||
uses: actions/cache/save@v4
|
||||
with:
|
||||
path: .banner-hash
|
||||
key: banner-content-hash-${{ github.run_id }}
|
||||
@@ -1,291 +0,0 @@
|
||||
name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- master
|
||||
- '[0-9]+.[0-9]+.x'
|
||||
pull_request:
|
||||
branches:
|
||||
- "**"
|
||||
|
||||
env:
|
||||
NX_CLOUD_ACCESS_TOKEN: ${{ secrets.NX_CLOUD_ACCESS_TOKEN }}
|
||||
NX_CLOUD_ENABLE_METRICS_COLLECTION: 'true'
|
||||
PNPM_HOME: ~/.pnpm
|
||||
|
||||
jobs:
|
||||
main-linux:
|
||||
runs-on: ubuntu-latest
|
||||
env:
|
||||
NX_BATCH_MODE: 'true'
|
||||
NX_E2E_CI_CACHE_KEY: e2e-github-linux
|
||||
NX_DAEMON: 'true'
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_VERBOSE_LOGGING: 'false'
|
||||
NX_NATIVE_LOGGING: 'false'
|
||||
NX_E2E_RUN_E2E: 'true'
|
||||
NX_CI_EXECUTION_ENV: 'linux'
|
||||
NX_CLOUD_NO_TIMEOUTS: 'true'
|
||||
NX_ALLOW_NON_CACHEABLE_DTE: 'true'
|
||||
NX_CLOUD_EXPERIMENTAL_POLLING: 'true'
|
||||
NX_CLOUD_CONTINUOUS_ASSIGNMENT: 'false'
|
||||
NX_CLOUD_VERBOSE_LOGGING: 'true'
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
|
||||
- name: Fetch Master
|
||||
run: git fetch origin master:master
|
||||
if: ${{ github.event_name == 'pull_request' }}
|
||||
|
||||
- name: Set SHAs
|
||||
uses: nrwl/nx-set-shas@1859e66a83ac9be0dceecbd9a023702e27ac47f4 # v4.3.3
|
||||
with:
|
||||
main-branch-name: 'master'
|
||||
|
||||
- name: Start CI Run
|
||||
run: npx nx-cloud@next start-ci-run --distribute-on="./.nx/workflows/dynamic-changesets.yaml" --stop-agents-after="e2e"
|
||||
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y ca-certificates lsof libvips-dev libglib2.0-dev libgirepository1.0-dev
|
||||
|
||||
- name: Install Chrome
|
||||
uses: browser-actions/setup-chrome@2dbff04819ebbfd5c974947148805a825b8a07fd # v2.1.0
|
||||
|
||||
- name: Setup dev tools with mise
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
|
||||
- name: Setup Gradle
|
||||
uses: gradle/actions/setup-gradle@48b5f213c81028ace310571dc5ec0fbbca0b2947 # v4.4.3
|
||||
|
||||
- name: Install project dependencies
|
||||
run: |
|
||||
pnpm install --frozen-lockfile
|
||||
pnpm playwright install --with-deps
|
||||
|
||||
- name: Nx Report
|
||||
run:
|
||||
pnpm nx report
|
||||
|
||||
- name: Run Checks/Lint/Test/Build
|
||||
run: |
|
||||
pids=()
|
||||
|
||||
pnpm nx-cloud record -- nx format:check &
|
||||
pids+=($!)
|
||||
|
||||
pnpm nx-cloud record -- nx sync:check
|
||||
pids+=($!)
|
||||
|
||||
pnpm nx build workspace-plugin && pnpm nx-cloud record -- pnpm nx conformance:check
|
||||
pids+=($!)
|
||||
|
||||
pnpm nx run-many -t check-imports check-lock-files check-codeowners --parallel=1 --no-dte &
|
||||
pids+=($!)
|
||||
|
||||
pnpm nx affected --targets=lint,test,build,e2e,e2e-ci,format-native,lint-native,gradle:build-ci,vale &
|
||||
pids+=($!)
|
||||
|
||||
for pid in "${pids[@]}"; do
|
||||
wait "$pid"
|
||||
done
|
||||
timeout-minutes: 100
|
||||
- name: Fix CI
|
||||
run: pnpm nx-cloud fix-ci
|
||||
if: failure()
|
||||
|
||||
main-macos:
|
||||
runs-on: macos-latest
|
||||
|
||||
concurrency:
|
||||
group: ${{ github.workflow }}-${{ github.ref }}${{ contains(github.event_name, 'push') && format('-{0}', github.sha) || '' }}
|
||||
cancel-in-progress: true
|
||||
|
||||
env:
|
||||
NX_E2E_CI_CACHE_KEY: e2e-github-macos
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_CI_EXECUTION_ENV: 'macos'
|
||||
SELECTED_PM: 'npm'
|
||||
steps:
|
||||
|
||||
- name: Log concurrency info
|
||||
run: |
|
||||
echo "Concurrency group: ${{ github.workflow }}-${{ github.ref }}${{ contains(github.event_name, 'push') && format('-{0}', github.sha) || '' }}"
|
||||
echo "Concurrency cancel-in-progress: ${{ !contains(github.event_name, 'push') }}"
|
||||
echo "Concurrency cancel-event-name: ${{ github.event_name }}"
|
||||
if: always()
|
||||
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
|
||||
- name: Fetch Master
|
||||
run: git fetch origin master:master
|
||||
if: ${{ github.event_name == 'pull_request' }}
|
||||
|
||||
- name: Setup dev tools with mise
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
|
||||
- name: Set SHAs
|
||||
uses: nrwl/nx-set-shas@1859e66a83ac9be0dceecbd9a023702e27ac47f4 # v4.3.3
|
||||
with:
|
||||
main-branch-name: 'master'
|
||||
|
||||
- name: Check for React Native changes
|
||||
id: check-changes
|
||||
run: |
|
||||
HAS_CHANGED=$(node ./scripts/check-react-native-changes.js $NX_BASE $NX_HEAD);
|
||||
if $HAS_CHANGED; then
|
||||
echo "has_changes=true" >> $GITHUB_OUTPUT
|
||||
echo "React Native projects are affected, will run macOS tests"
|
||||
else
|
||||
echo "has_changes=false" >> $GITHUB_OUTPUT
|
||||
echo "No React Native projects affected, skipping macOS tests"
|
||||
fi
|
||||
|
||||
- name: Restore Homebrew packages
|
||||
if: steps.check-changes.outputs.has_changes == 'true'
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
with:
|
||||
path: |
|
||||
/opt/homebrew
|
||||
~/Library/Caches/Homebrew
|
||||
key: nrwl-nx-homebrew-packages
|
||||
|
||||
- name: Configure Detox Environment, Install applesimutils
|
||||
if: steps.check-changes.outputs.has_changes == 'true'
|
||||
run: |
|
||||
# Ensure Xcode command line tools are installed and configured
|
||||
xcode-select --print-path || sudo xcode-select --reset
|
||||
sudo xcode-select -s /Applications/Xcode.app
|
||||
|
||||
# Install or update applesimutils with error handling
|
||||
if ! brew list applesimutils &>/dev/null; then
|
||||
echo "Installing applesimutils..."
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew tap wix/brew >/dev/null
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew install applesimutils >/dev/null || {
|
||||
echo "Failed to install applesimutils, retrying with update..."
|
||||
brew update
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew install applesimutils
|
||||
}
|
||||
else
|
||||
echo "Updating applesimutils..."
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew upgrade applesimutils || true
|
||||
fi
|
||||
|
||||
# Verify applesimutils installation
|
||||
applesimutils --version || (echo "applesimutils installation failed" && exit 1)
|
||||
|
||||
# Configure environment for M-series Mac
|
||||
echo "DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer" >> $GITHUB_ENV
|
||||
echo "PLATFORM_NAME=iOS Simulator" >> $GITHUB_ENV
|
||||
|
||||
# Set additional environment variables for better debugging
|
||||
echo "DETOX_DISABLE_TELEMETRY=1" >> $GITHUB_ENV
|
||||
echo "DETOX_LOG_LEVEL=trace" >> $GITHUB_ENV
|
||||
|
||||
# Verify Xcode installation
|
||||
xcodebuild -version
|
||||
|
||||
# List available simulators
|
||||
xcrun simctl list devices available
|
||||
timeout-minutes: 10
|
||||
continue-on-error: false
|
||||
|
||||
- name: Reset iOS Simulators
|
||||
if: steps.check-changes.outputs.has_changes == 'true'
|
||||
id: reset-simulators
|
||||
run: |
|
||||
echo "Resetting iOS Simulators..."
|
||||
|
||||
# Kill simulator processes
|
||||
sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService 2>/dev/null || true
|
||||
killall "Simulator" 2>/dev/null || true
|
||||
killall "iOS Simulator" 2>/dev/null || true
|
||||
|
||||
# Wait for processes to terminate
|
||||
sleep 3
|
||||
|
||||
# Shutdown and erase all simulators (ignore failures)
|
||||
xcrun simctl shutdown all 2>/dev/null || true
|
||||
sleep 5
|
||||
xcrun simctl erase all 2>/dev/null || true
|
||||
|
||||
# If erase failed, try the nuclear option
|
||||
if xcrun simctl list devices | grep -q "Booted" 2>/dev/null; then
|
||||
echo "Standard reset failed, using nuclear option..."
|
||||
rm -rf ~/Library/Developer/CoreSimulator/Devices/* 2>/dev/null || true
|
||||
launchctl remove com.apple.CoreSimulator.CoreSimulatorService 2>/dev/null || true
|
||||
sleep 3
|
||||
fi
|
||||
|
||||
# Clean up additional directories
|
||||
rm -rf ~/Library/Developer/CoreSimulator/Caches/* 2>/dev/null || true
|
||||
rm -rf ~/Library/Logs/CoreSimulator/* 2>/dev/null || true
|
||||
rm -rf ~/Library/Developer/Xcode/DerivedData/* 2>/dev/null || true
|
||||
|
||||
echo "Simulator reset completed"
|
||||
timeout-minutes: 5
|
||||
continue-on-error: true
|
||||
|
||||
- name: Verify Simulator Reset
|
||||
if: steps.check-changes.outputs.has_changes == 'true' && steps.reset-simulators.outcome == 'success'
|
||||
run: |
|
||||
# Verify CoreSimulator service restarted
|
||||
pgrep -fl "CoreSimulator" || (echo "CoreSimulator service not running" && exit 1)
|
||||
|
||||
# Check simulator list is clean
|
||||
xcrun simctl list devices
|
||||
|
||||
# Verify simulator runtime paths exist and are writable
|
||||
test -d ~/Library/Developer/CoreSimulator/Devices || (echo "Simulator devices directory missing" && exit 1)
|
||||
touch ~/Library/Developer/CoreSimulator/Devices/test || (echo "Simulator devices directory not writable" && exit 1)
|
||||
rm ~/Library/Developer/CoreSimulator/Devices/test
|
||||
timeout-minutes: 5
|
||||
|
||||
- name: Diagnose Simulator Reset Failure
|
||||
if: steps.check-changes.outputs.has_changes == 'true' && steps.reset-simulators.outcome == 'failure'
|
||||
run: |
|
||||
echo "Simulator reset failed. Collecting diagnostic information..."
|
||||
xcrun simctl list
|
||||
echo "Checking simulator logs..."
|
||||
ls -la ~/Library/Logs/CoreSimulator/ || echo "No simulator logs found"
|
||||
|
||||
- name: Save Homebrew Cache
|
||||
if: steps.check-changes.outputs.has_changes == 'true'
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
with:
|
||||
path: |
|
||||
/opt/homebrew
|
||||
~/Library/Caches/Homebrew
|
||||
key: nrwl-nx-homebrew-packages
|
||||
|
||||
- name: Install project dependencies
|
||||
if: steps.check-changes.outputs.has_changes == 'true'
|
||||
run: |
|
||||
pnpm install --frozen-lockfile
|
||||
pnpm playwright install --with-deps
|
||||
|
||||
- name: Run E2E Tests for macOS
|
||||
if: steps.check-changes.outputs.has_changes == 'true'
|
||||
run: |
|
||||
pnpm nx affected -t e2e-macos-local --parallel=1 --base=$NX_BASE --head=$NX_HEAD
|
||||
@@ -1,114 +0,0 @@
|
||||
# For most projects, this workflow file will not need changing; you simply need
|
||||
# to commit it to your repository.
|
||||
#
|
||||
# You may wish to alter this file to override the set of languages analyzed,
|
||||
# or to provide custom queries or build logic.
|
||||
#
|
||||
# ******** NOTE ********
|
||||
# We have attempted to detect the languages in your repository. Please check
|
||||
# the `language` matrix defined below to confirm you have the correct set of
|
||||
# supported CodeQL languages.
|
||||
#
|
||||
name: "CodeQL"
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ "master" ]
|
||||
schedule:
|
||||
- cron: '20 14 * * 6'
|
||||
|
||||
jobs:
|
||||
analyze:
|
||||
name: Analyze (${{ matrix.language }})
|
||||
# Runner size impacts CodeQL analysis time. To learn more, please see:
|
||||
# - https://gh.io/recommended-hardware-resources-for-running-codeql
|
||||
# - https://gh.io/supported-runners-and-hardware-resources
|
||||
# - https://gh.io/using-larger-runners (GitHub.com only)
|
||||
# Consider using larger runners or machines with greater resources for possible analysis time improvements.
|
||||
runs-on: ${{ (matrix.language == 'swift' && 'macos-latest') || 'ubuntu-latest' }}
|
||||
permissions:
|
||||
# required for all workflows
|
||||
security-events: write
|
||||
|
||||
# required to fetch internal or private CodeQL packs
|
||||
packages: read
|
||||
|
||||
# only required for workflows in private repositories
|
||||
actions: read
|
||||
contents: read
|
||||
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
include:
|
||||
- language: actions
|
||||
build-mode: none
|
||||
|
||||
# We would like to test our Java / Kotlin... but its currently failing. We can follow up.
|
||||
# - language: java-kotlin
|
||||
# build-mode: autobuild
|
||||
- language: javascript-typescript
|
||||
build-mode: none
|
||||
- language: rust
|
||||
build-mode: none
|
||||
- language: csharp
|
||||
build-mode: autobuild
|
||||
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift'
|
||||
# Use `c-cpp` to analyze code written in C, C++ or both
|
||||
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
|
||||
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
|
||||
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
|
||||
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
|
||||
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
|
||||
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
|
||||
- name: Setup Language Tooling
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
|
||||
# Add any setup steps before running the `github/codeql-action/init` action.
|
||||
# This includes steps like installing compilers or runtimes (`actions/setup-node`
|
||||
# or others). This is typically only required for manual builds.
|
||||
# - name: Setup runtime (example)
|
||||
# uses: actions/setup-example@v1
|
||||
|
||||
# Initializes the CodeQL tools for scanning.
|
||||
- name: Initialize CodeQL
|
||||
uses: github/codeql-action/init@15403aac29bd91419968e066cded66bde56b0283 # v3
|
||||
with:
|
||||
languages: ${{ matrix.language }}
|
||||
build-mode: ${{ matrix.build-mode }}
|
||||
# If you wish to specify custom queries, you can do so here or in a config file.
|
||||
# By default, queries listed here will override any specified in a config file.
|
||||
# Prefix the list here with "+" to use these queries and those in the config file.
|
||||
|
||||
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
|
||||
# queries: security-extended,security-and-quality
|
||||
|
||||
# If the analyze step fails for one of the languages you are analyzing with
|
||||
# "We were unable to automatically build your code", modify the matrix above
|
||||
# to set the build mode to "manual" for that language. Then modify this step
|
||||
# to build your code.
|
||||
# ℹ️ Command-line programs to run using the OS shell.
|
||||
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
|
||||
- if: matrix.build-mode == 'manual'
|
||||
shell: bash
|
||||
run: |
|
||||
echo 'If you are using a "manual" build mode for one or more of the' \
|
||||
'languages you are analyzing, replace this with the commands to build' \
|
||||
'your code, for example:'
|
||||
echo ' make bootstrap'
|
||||
echo ' make release'
|
||||
exit 1
|
||||
|
||||
- name: Perform CodeQL Analysis
|
||||
uses: github/codeql-action/analyze@15403aac29bd91419968e066cded66bde56b0283 # v3
|
||||
with:
|
||||
category: "/language:${{matrix.language}}"
|
||||
@@ -1,111 +0,0 @@
|
||||
# For most projects, this workflow file will not need changing; you simply need
|
||||
# to commit it to your repository.
|
||||
#
|
||||
# You may wish to alter this file to override the set of languages analyzed,
|
||||
# or to provide custom queries or build logic.
|
||||
#
|
||||
# ******** NOTE ********
|
||||
# We have attempted to detect the languages in your repository. Please check
|
||||
# the `language` matrix defined below to confirm you have the correct set of
|
||||
# supported CodeQL languages.
|
||||
#
|
||||
name: "CodeQL"
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches: [ "**" ]
|
||||
|
||||
jobs:
|
||||
analyze:
|
||||
name: Analyze (${{ matrix.language }})
|
||||
# Runner size impacts CodeQL analysis time. To learn more, please see:
|
||||
# - https://gh.io/recommended-hardware-resources-for-running-codeql
|
||||
# - https://gh.io/supported-runners-and-hardware-resources
|
||||
# - https://gh.io/using-larger-runners (GitHub.com only)
|
||||
# Consider using larger runners or machines with greater resources for possible analysis time improvements.
|
||||
runs-on: ${{ (matrix.language == 'swift' && 'macos-latest') || 'ubuntu-latest' }}
|
||||
permissions:
|
||||
# required to fetch internal or private CodeQL packs
|
||||
packages: read
|
||||
|
||||
# only required for workflows in private repositories
|
||||
actions: read
|
||||
contents: read
|
||||
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
include:
|
||||
- language: actions
|
||||
build-mode: none
|
||||
|
||||
# See comment in @./codeql-master.yml about Java / Kotlin
|
||||
# - language: java-kotlin
|
||||
# build-mode: autobuild
|
||||
- language: javascript-typescript
|
||||
build-mode: none
|
||||
- language: rust
|
||||
build-mode: none
|
||||
- language: csharp
|
||||
build-mode: autobuild
|
||||
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift'
|
||||
# Use `c-cpp` to analyze code written in C, C++ or both
|
||||
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
|
||||
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
|
||||
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
|
||||
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
|
||||
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
|
||||
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
|
||||
- name: Setup Language Tooling
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
|
||||
# Add any setup steps before running the `github/codeql-action/init` action.
|
||||
# This includes steps like installing compilers or runtimes (`actions/setup-node`
|
||||
# or others). This is typically only required for manual builds.
|
||||
# - name: Setup runtime (example)
|
||||
# uses: actions/setup-example@v1
|
||||
|
||||
# Initializes the CodeQL tools for scanning.
|
||||
- name: Initialize CodeQL
|
||||
uses: github/codeql-action/init@15403aac29bd91419968e066cded66bde56b0283 # v3
|
||||
with:
|
||||
languages: ${{ matrix.language }}
|
||||
build-mode: ${{ matrix.build-mode }}
|
||||
# If you wish to specify custom queries, you can do so here or in a config file.
|
||||
# By default, queries listed here will override any specified in a config file.
|
||||
# Prefix the list here with "+" to use these queries and those in the config file.
|
||||
|
||||
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
|
||||
# queries: security-extended,security-and-quality
|
||||
|
||||
# If the analyze step fails for one of the languages you are analyzing with
|
||||
# "We were unable to automatically build your code", modify the matrix above
|
||||
# to set the build mode to "manual" for that language. Then modify this step
|
||||
# to build your code.
|
||||
# ℹ️ Command-line programs to run using the OS shell.
|
||||
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
|
||||
- if: matrix.build-mode == 'manual'
|
||||
shell: bash
|
||||
run: |
|
||||
echo 'If you are using a "manual" build mode for one or more of the' \
|
||||
'languages you are analyzing, replace this with the commands to build' \
|
||||
'your code, for example:'
|
||||
echo ' make bootstrap'
|
||||
echo ' make release'
|
||||
exit 1
|
||||
|
||||
- name: Perform CodeQL Analysis
|
||||
uses: github/codeql-action/analyze@15403aac29bd91419968e066cded66bde56b0283 # v3
|
||||
with:
|
||||
category: "/language:${{matrix.language}}"
|
||||
upload: 'never'
|
||||
upload-database: false
|
||||
+402
-276
@@ -2,7 +2,7 @@ name: E2E matrix
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: '0 5 * * *'
|
||||
- cron: "0 5 * * *"
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
debug_enabled:
|
||||
@@ -14,65 +14,46 @@ on:
|
||||
env:
|
||||
CYPRESS_CACHE_FOLDER: ${{ github.workspace }}/.cypress
|
||||
|
||||
permissions: {}
|
||||
permissions: { }
|
||||
jobs:
|
||||
preinstall:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
runs-on: ${{ matrix.os }}
|
||||
timeout-minutes: 20
|
||||
env:
|
||||
NODE_VERSION: ${{ matrix.node_version }}
|
||||
strategy:
|
||||
matrix:
|
||||
os:
|
||||
- ubuntu-latest
|
||||
- macos-latest
|
||||
# - windows-latest Windows fails to build gradle wrapper which always runs when we build nx.
|
||||
## https://staging.nx.app/runs/LgD4vxGn8w?utm_source=pull-request&utm_medium=comment
|
||||
node_version:
|
||||
# TODO(v23): remove node 20 - EOL April 2026
|
||||
- 20
|
||||
- 22
|
||||
- 24
|
||||
- 18
|
||||
exclude:
|
||||
# run just node v24 on macos and windows
|
||||
# run just node v20 on macos
|
||||
- os: macos-latest
|
||||
node_version: 20
|
||||
- os: macos-latest
|
||||
node_version: 22
|
||||
# - os: windows-latest TODO(Jack): Windows fails to build gradle wrapper which always runs when we build nx. Re-enable when we fix this.
|
||||
# node_version: 20
|
||||
# - os: windows-latest TODO (Jack): Windows fails to build gradle wrapper which always runs when we build nx. Re-enable when we fix this.
|
||||
# node_version: 22
|
||||
node_version: 18
|
||||
|
||||
name: Cache install (${{ matrix.os }}, node v${{ matrix.node_version }})
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Setup dev tools with mise
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
- name: Install PNPM
|
||||
run: |
|
||||
npm install -g corepack@latest
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
npm install -g @pnpm/exe@8
|
||||
|
||||
- name: Get pnpm store directory
|
||||
id: pnpm-cache
|
||||
run: echo "path=$(pnpm store path)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Cache pnpm store
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
- name: Set node
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
path: ${{ steps.pnpm-cache.outputs.path }}
|
||||
key: ${{ runner.os }}-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}
|
||||
restore-keys: |
|
||||
${{ runner.os }}-pnpm-store-
|
||||
node-version: ${{ matrix.node_version }}
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Cache node_modules
|
||||
id: cache-modules
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
lookup-only: true
|
||||
path: '**/node_modules'
|
||||
key: ${{ runner.os }}-modules-${{ matrix.node_version }}-${{ github.run_id }}
|
||||
|
||||
- name: Ensure Python setuptools Installed on Macos
|
||||
if: ${{ matrix.os == 'macos-latest' }}
|
||||
@@ -80,9 +61,8 @@ jobs:
|
||||
run: brew install python-setuptools
|
||||
|
||||
- name: Install packages
|
||||
run: |
|
||||
pnpm install --frozen-lockfile
|
||||
pnpm playwright install --with-deps
|
||||
if: steps.cache-modules.outputs.cache-hit != 'true'
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Homebrew cache directory path
|
||||
if: ${{ matrix.os == 'macos-latest' }}
|
||||
@@ -91,7 +71,7 @@ jobs:
|
||||
|
||||
- name: Cache Homebrew
|
||||
if: ${{ matrix.os == 'macos-latest' }}
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
lookup-only: true
|
||||
path: ${{ steps.homebrew-cache-dir-path.outputs.dir }}
|
||||
@@ -101,7 +81,7 @@ jobs:
|
||||
|
||||
- name: Cache Cypress
|
||||
id: cache-cypress
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
lookup-only: true
|
||||
path: '${{ github.workspace }}/.cypress'
|
||||
@@ -111,63 +91,217 @@ jobs:
|
||||
if: steps.cache-cypress.outputs.cache-hit != 'true'
|
||||
run: npx cypress install
|
||||
|
||||
prepare-matrix:
|
||||
name: Prepare matrix combinations
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
timeout-minutes: 5
|
||||
runs-on: ubuntu-latest
|
||||
outputs:
|
||||
matrix: ${{ steps.process-json.outputs.MATRIX }}
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
|
||||
- name: Process matrix data
|
||||
id: process-json
|
||||
run: echo "MATRIX=$(npx tsx .github/workflows/nightly/process-matrix.ts | jq -c .)" >> $GITHUB_OUTPUT
|
||||
|
||||
e2e:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
needs:
|
||||
- preinstall
|
||||
- prepare-matrix
|
||||
needs: preinstall
|
||||
permissions:
|
||||
contents: read
|
||||
runs-on: ${{ matrix.os }}
|
||||
timeout-minutes: 200 # <- cap each job to 200 minutes
|
||||
env:
|
||||
NODE_VERSION: ${{ matrix.node_version }}
|
||||
timeout-minutes: 90
|
||||
strategy:
|
||||
matrix: ${{fromJson(needs.prepare-matrix.outputs.matrix)}} # Load matrix from previous job
|
||||
matrix:
|
||||
os:
|
||||
- ubuntu-latest
|
||||
- macos-latest
|
||||
node_version:
|
||||
- 20
|
||||
- 18
|
||||
package_manager:
|
||||
- npm
|
||||
- yarn
|
||||
- pnpm
|
||||
project:
|
||||
- e2e-angular
|
||||
- e2e-cypress
|
||||
- e2e-detox
|
||||
- e2e-esbuild
|
||||
- e2e-eslint
|
||||
- e2e-expo
|
||||
- e2e-gradle
|
||||
- e2e-jest
|
||||
- e2e-js
|
||||
- e2e-lerna-smoke-tests
|
||||
- e2e-next
|
||||
- e2e-node
|
||||
- e2e-nuxt
|
||||
- e2e-nx-init
|
||||
- e2e-nx
|
||||
- e2e-playwright
|
||||
- e2e-plugin
|
||||
- e2e-react
|
||||
- e2e-react-native
|
||||
- e2e-release
|
||||
- e2e-remix
|
||||
- e2e-rollup
|
||||
- e2e-storybook
|
||||
- e2e-vite
|
||||
- e2e-vue
|
||||
- e2e-web
|
||||
- e2e-webpack
|
||||
- e2e-workspace-create
|
||||
include:
|
||||
# os short names
|
||||
- os: ubuntu-latest
|
||||
os_name: 'Linux'
|
||||
- os: macos-latest
|
||||
os_name: 'MacOS'
|
||||
# test timeouts
|
||||
- os: ubuntu-latest
|
||||
os_timeout: 60
|
||||
- os: macos-latest
|
||||
os_timeout: 90
|
||||
# codeowner groups
|
||||
- project: e2e-angular
|
||||
codeowners: 'S04SS457V38'
|
||||
- project: e2e-cypress
|
||||
codeowners: 'S04T16BTJJY'
|
||||
- project: e2e-detox
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-esbuild
|
||||
codeowners: 'S04SJ6HHP0X'
|
||||
- project: e2e-expo
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-gradle
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-jest
|
||||
codeowners: 'S04T16BTJJY'
|
||||
- project: e2e-js
|
||||
codeowners: 'S04SJ6HHP0X'
|
||||
- project: e2e-lerna-smoke-tests
|
||||
codeowners: 'S04TNCVEETS'
|
||||
- project: e2e-eslint
|
||||
codeowners: 'S04SYJGKSCT'
|
||||
- project: e2e-next
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-node
|
||||
codeowners: 'S04SJ6HHP0X'
|
||||
- project: e2e-nx-init
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-nx
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-plugin
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-release
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-react
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-react-native
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-web
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-rollup
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-storybook
|
||||
codeowners: 'S04SVQ8H0G5'
|
||||
- project: e2e-playwright
|
||||
codeowners: 'S04SVQ8H0G5'
|
||||
- project: e2e-remix
|
||||
codeowners: 'S04SVQ8H0G5'
|
||||
- project: e2e-vite
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-vue
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-nuxt
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-webpack
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-workspace-create
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
exclude:
|
||||
# exclude react-native tests from ubuntu
|
||||
- os: ubuntu-latest
|
||||
project: e2e-react-native
|
||||
- os: ubuntu-latest
|
||||
project: e2e-detox
|
||||
- os: ubuntu-latest
|
||||
project: e2e-expo
|
||||
# exclude non-CNW/Lerna tests from non-LTS node versions
|
||||
- node_version: 18
|
||||
project: e2e-angular
|
||||
- node_version: 18
|
||||
project: e2e-cypress
|
||||
- node_version: 18
|
||||
project: e2e-detox
|
||||
- node_version: 18
|
||||
project: e2e-esbuild
|
||||
- node_version: 18
|
||||
project: e2e-expo
|
||||
- node_version: 18
|
||||
project: e2e-gradle
|
||||
- node_version: 18
|
||||
project: e2e-jest
|
||||
- node_version: 18
|
||||
project: e2e-js
|
||||
- node_version: 18
|
||||
project: e2e-eslint
|
||||
- node_version: 18
|
||||
project: e2e-next
|
||||
- node_version: 18
|
||||
project: e2e-node
|
||||
- node_version: 18
|
||||
project: e2e-nuxt
|
||||
- node_version: 18
|
||||
project: e2e-nx-init
|
||||
- node_version: 18
|
||||
project: e2e-nx
|
||||
- node_version: 18
|
||||
project: e2e-plugin
|
||||
- node_version: 18
|
||||
project: e2e-playwright
|
||||
- node_version: 18
|
||||
project: e2e-react
|
||||
- node_version: 18
|
||||
project: e2e-react-native
|
||||
- node_version: 18
|
||||
project: e2e-web
|
||||
- node_version: 18
|
||||
project: e2e-remix
|
||||
- node_version: 18
|
||||
project: e2e-rollup
|
||||
- node_version: 18
|
||||
project: e2e-storybook
|
||||
- node_version: 18
|
||||
project: e2e-vite
|
||||
- node_version: 18
|
||||
project: e2e-vue
|
||||
- node_version: 18
|
||||
project: e2e-webpack
|
||||
# run just npm v20 on macos
|
||||
- os: macos-latest
|
||||
package_manager: yarn
|
||||
- os: macos-latest
|
||||
package_manager: pnpm
|
||||
- os: macos-latest
|
||||
node_version: 18
|
||||
fail-fast: false
|
||||
|
||||
name: ${{ matrix.os_name }}/${{ matrix.package_manager }}/${{ matrix.node_version }} ${{ join(matrix.project) }}
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Prepare dir for output
|
||||
run: mkdir -p outputs
|
||||
|
||||
- name: Setup dev tools with mise
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
- name: Install PNPM
|
||||
run: |
|
||||
npm install -g corepack@latest
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
npm install -g @pnpm/exe@8
|
||||
|
||||
- name: Use Node.js ${{ matrix.node_version }}
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node_version }}
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Cache node_modules
|
||||
id: cache-modules
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: '**/node_modules'
|
||||
key: ${{ runner.os }}-modules-${{ matrix.node_version }}-${{ github.run_id }}
|
||||
|
||||
- name: Install packages
|
||||
run: |
|
||||
pnpm install --frozen-lockfile
|
||||
pnpm playwright install --with-deps
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Cleanup
|
||||
if: ${{ matrix.os == 'ubuntu-latest' }}
|
||||
@@ -176,7 +310,7 @@ jobs:
|
||||
# https://github.com/actions/virtual-environments/issues/2840
|
||||
sudo rm -rf /usr/share/dotnet
|
||||
sudo rm -rf /opt/ghc
|
||||
sudo rm -rf '/usr/local/share/boost'
|
||||
sudo rm -rf "/usr/local/share/boost"
|
||||
sudo rm -rf "$AGENT_TOOLSDIRECTORY"
|
||||
sudo apt-get install lsof
|
||||
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
|
||||
@@ -188,7 +322,7 @@ jobs:
|
||||
|
||||
- name: Cache Homebrew
|
||||
if: ${{ matrix.os == 'macos-latest' }}
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: ${{ steps.homebrew-cache-dir-path.outputs.dir }}
|
||||
key: brew-${{ matrix.node_version }}
|
||||
@@ -197,7 +331,7 @@ jobs:
|
||||
|
||||
- name: Cache Cypress
|
||||
id: cache-cypress
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: '${{ github.workspace }}/.cypress'
|
||||
key: ${{ runner.os }}-cypress
|
||||
@@ -206,159 +340,44 @@ jobs:
|
||||
if: steps.cache-cypress.outputs.cache-hit != 'true'
|
||||
run: npx cypress install
|
||||
|
||||
- name: Configure Detox Environment, Install applesimutils
|
||||
- name: Install applesimutils, reset ios simulators
|
||||
if: ${{ matrix.os == 'macos-latest' }}
|
||||
run: |
|
||||
# Ensure Xcode command line tools are installed and configured
|
||||
xcode-select --print-path || sudo xcode-select --reset
|
||||
sudo xcode-select -s /Applications/Xcode.app
|
||||
|
||||
# Install or update applesimutils with error handling
|
||||
if ! brew list applesimutils &>/dev/null; then
|
||||
echo 'Installing applesimutils...'
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew tap wix/brew >/dev/null
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew install applesimutils >/dev/null || {
|
||||
echo 'Failed to install applesimutils, retrying with update...'
|
||||
brew update
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew install applesimutils
|
||||
}
|
||||
else
|
||||
echo 'Updating applesimutils...'
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew upgrade applesimutils || true
|
||||
fi
|
||||
|
||||
# Verify applesimutils installation
|
||||
applesimutils --version || (echo 'applesimutils installation failed' && exit 1)
|
||||
|
||||
# Configure environment for M-series Mac
|
||||
echo 'DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer' >> $GITHUB_ENV
|
||||
echo 'PLATFORM_NAME=iOS Simulator' >> $GITHUB_ENV
|
||||
|
||||
# Set additional environment variables for better debugging
|
||||
echo 'DETOX_DISABLE_TELEMETRY=1' >> $GITHUB_ENV
|
||||
echo 'DETOX_LOG_LEVEL=trace' >> $GITHUB_ENV
|
||||
|
||||
# Verify Xcode installation
|
||||
xcodebuild -version
|
||||
|
||||
timeout-minutes: 10
|
||||
continue-on-error: false
|
||||
|
||||
- name: Reset iOS Simulators
|
||||
if: ${{ matrix.os == 'macos-latest' }}
|
||||
id: reset-simulators
|
||||
run: |
|
||||
echo 'Resetting iOS Simulators...'
|
||||
|
||||
# Kill simulator processes
|
||||
sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService 2>/dev/null || true
|
||||
killall 'Simulator' 2>/dev/null || true
|
||||
killall 'iOS Simulator' 2>/dev/null || true
|
||||
|
||||
# Wait for processes to terminate
|
||||
sleep 3
|
||||
|
||||
# Shutdown and erase all simulators (ignore failures)
|
||||
xcrun simctl shutdown all 2>/dev/null || true
|
||||
sleep 5
|
||||
xcrun simctl erase all 2>/dev/null || true
|
||||
|
||||
# If erase failed, try the nuclear option
|
||||
if xcrun simctl list devices | grep -q 'Booted' 2>/dev/null; then
|
||||
echo 'Standard reset failed, using nuclear option...'
|
||||
rm -rf ~/Library/Developer/CoreSimulator/Devices/* 2>/dev/null || true
|
||||
launchctl remove com.apple.CoreSimulator.CoreSimulatorService 2>/dev/null || true
|
||||
sleep 3
|
||||
fi
|
||||
|
||||
# Clean up additional directories
|
||||
rm -rf ~/Library/Developer/CoreSimulator/Caches/* 2>/dev/null || true
|
||||
rm -rf ~/Library/Logs/CoreSimulator/* 2>/dev/null || true
|
||||
rm -rf ~/Library/Developer/Xcode/DerivedData/* 2>/dev/null || true
|
||||
|
||||
echo 'Simulator reset completed'
|
||||
timeout-minutes: 5
|
||||
continue-on-error: true
|
||||
|
||||
- name: Verify Simulator Reset
|
||||
if: ${{ matrix.os == 'macos-latest' && steps.reset-simulators.outcome == 'success' }}
|
||||
run: |
|
||||
# Verify CoreSimulator service restarted
|
||||
pgrep -fl 'CoreSimulator' || (echo 'CoreSimulator service not running' && exit 1)
|
||||
|
||||
# Verify simulator runtime paths exist and are writable
|
||||
test -d ~/Library/Developer/CoreSimulator/Devices || (echo 'Simulator devices directory missing' && exit 1)
|
||||
touch ~/Library/Developer/CoreSimulator/Devices/test || (echo 'Simulator devices directory not writable' && exit 1)
|
||||
rm ~/Library/Developer/CoreSimulator/Devices/test
|
||||
timeout-minutes: 5
|
||||
|
||||
- name: Diagnose Simulator Reset Failure
|
||||
if: ${{ matrix.os == 'macos-latest' && steps.reset-simulators.outcome == 'failure' }}
|
||||
run: |
|
||||
echo 'Simulator reset failed. Collecting diagnostic information...'
|
||||
xcrun simctl list
|
||||
echo 'Checking simulator logs...'
|
||||
ls -la ~/Library/Logs/CoreSimulator/ || echo 'No simulator logs found'
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew tap wix/brew >/dev/null
|
||||
HOMEBREW_NO_AUTO_UPDATE=1 brew install applesimutils >/dev/null
|
||||
xcrun simctl shutdown all && xcrun simctl erase all
|
||||
|
||||
- name: Configure git metadata (needed for lerna smoke tests)
|
||||
if: ${{ (matrix.os != 'macos-latest') || (matrix.os == 'macos-latest' && steps.reset-simulators.outcome == 'success') }}
|
||||
run: |
|
||||
git config --global user.email test@test.com
|
||||
git config --global user.name 'Test Test'
|
||||
git config --global user.name "Test Test"
|
||||
|
||||
- name: Set starting timestamp
|
||||
if: ${{ (matrix.os != 'macos-latest') || (matrix.os == 'macos-latest' && steps.reset-simulators.outcome == 'success') }}
|
||||
id: before-e2e
|
||||
shell: bash
|
||||
run: |
|
||||
echo "timestamp=$(date +%s)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Run e2e tests with pnpm (Linux/Windows)
|
||||
id: e2e-run-pnpm
|
||||
if: ${{ matrix.os != 'macos-latest' }}
|
||||
run: pnpm nx run ${{ matrix.project }}:e2e-local
|
||||
shell: bash
|
||||
- name: Run e2e tests
|
||||
id: e2e-run
|
||||
run: pnpm nx run-many -t e2e-local -p ${{ matrix.project }}
|
||||
timeout-minutes: ${{ matrix.os_timeout }}
|
||||
env:
|
||||
GIT_AUTHOR_EMAIL: test@test.com
|
||||
GIT_AUTHOR_NAME: Test
|
||||
GIT_COMMITTER_EMAIL: test@test.com
|
||||
GIT_COMMITTER_NAME: Test
|
||||
NX_E2E_CI_CACHE_KEY: e2e-gha-${{ matrix.os }}-${{ matrix.node_version }}-${{ matrix.package_manager }}
|
||||
NX_DAEMON: 'true'
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_E2E_VERBOSE_LOGGING: 'true'
|
||||
NX_NATIVE_LOGGING: 'false'
|
||||
NX_E2E_RUN_E2E: 'true'
|
||||
NX_CLOUD_NO_TIMEOUTS: 'true'
|
||||
NX_E2E_SKIP_CLEANUP: 'true'
|
||||
NODE_OPTIONS: --max_old_space_size=8192
|
||||
SELECTED_PM: ${{ matrix.package_manager }}
|
||||
npm_config_registry: http://localhost:4872
|
||||
YARN_REGISTRY: http://localhost:4872
|
||||
CI: true
|
||||
|
||||
- name: Run e2e tests with npm (macOS)
|
||||
id: e2e-run-npm
|
||||
if: ${{ matrix.os == 'macos-latest' && steps.reset-simulators.outcome == 'success' }}
|
||||
run: |
|
||||
# Run the tests
|
||||
if [[ '${{ matrix.project }}' == 'e2e-detox' ]] || [[ '${{ matrix.project }}' == 'e2e-react-native' ]] || [[ '${{ matrix.project }}' == 'e2e-expo' ]]; then
|
||||
NX_E2E_VERBOSE_DEBUG=1 pnpm nx run ${{ matrix.project }}:e2e-macos-local
|
||||
else
|
||||
NX_E2E_VERBOSE_DEBUG=1 pnpm nx run ${{ matrix.project }}:e2e-local
|
||||
fi
|
||||
|
||||
env:
|
||||
NX_E2E_CI_CACHE_KEY: e2e-gha-${{ matrix.os }}-${{ matrix.node_version }}-${{ matrix.package_manager }}
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_CI_EXECUTION_ENV: 'macos'
|
||||
NX_E2E_VERBOSE_LOGGING: 'true'
|
||||
NX_NATIVE_LOGGING: 'false'
|
||||
NX_E2E_RUN_E2E: 'true'
|
||||
NX_CACHE_DIRECTORY: 'tmp'
|
||||
NX_E2E_SKIP_CLEANUP: 'true'
|
||||
NODE_OPTIONS: --max_old_space_size=8192
|
||||
SELECTED_PM: 'npm'
|
||||
npm_config_registry: http://localhost:4872
|
||||
YARN_REGISTRY: http://localhost:4872
|
||||
DEVELOPER_DIR: '/Applications/Xcode.app/Contents/Developer'
|
||||
CI: true
|
||||
NX_E2E_RUN_E2E: 'true'
|
||||
NX_E2E_VERBOSE_LOGGING: 'true'
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_DAEMON: 'true'
|
||||
NX_SKIP_LOG_GROUPING: 'true'
|
||||
|
||||
- name: Save matrix config in file
|
||||
if: ${{ always() }}
|
||||
@@ -368,101 +387,210 @@ jobs:
|
||||
before=${{ steps.before-e2e.outputs.timestamp }}
|
||||
now=$(date +%s)
|
||||
delta=$(($now - $before))
|
||||
|
||||
# Determine the outcome based on which step ran
|
||||
outcome='${{ matrix.os == 'macos-latest' && steps.e2e-run-npm.outcome || steps.e2e-run-pnpm.outcome }}'
|
||||
|
||||
matrix=$((
|
||||
echo '${{ toJSON(matrix) }}'
|
||||
) | jq --argjson delta $delta -c '. + { "status": "'"$outcome"'", "duration": $delta }')
|
||||
echo "$matrix" > 'outputs/matrix.json'
|
||||
) | jq --argjson delta $delta -c '. + { "status": "${{ steps.e2e-run.outcome}}", "duration": $delta }')
|
||||
echo "$matrix" > matrix
|
||||
path=outputs/${{ matrix.os_name}}-${{ matrix.node_version}}-${{ matrix.package_manager}}-${{ matrix.project }}
|
||||
echo "path=$path" >> $GITHUB_OUTPUT
|
||||
echo "$matrix" > $path
|
||||
|
||||
- name: Upload matrix config
|
||||
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
|
||||
uses: actions/upload-artifact@v3
|
||||
if: ${{ always() }}
|
||||
with:
|
||||
name: ${{ matrix.os_name}}-${{ matrix.node_version}}-${{ matrix.package_manager}}-${{ matrix.project }}
|
||||
overwrite: true
|
||||
if-no-files-found: 'ignore'
|
||||
path: 'outputs/matrix.json'
|
||||
name: outputs
|
||||
path: ${{ steps.save-matrix.outputs.path }}
|
||||
|
||||
- name: Setup tmate session
|
||||
if: ${{ github.event_name == 'workflow_dispatch' && inputs.debug_enabled && failure() }}
|
||||
uses: mxschmitt/action-tmate@1fb8b1023602bf1fd0e2994d7f1e93015cb5bbec # v3.22
|
||||
uses: mxschmitt/action-tmate@v3.8
|
||||
timeout-minutes: 15
|
||||
with:
|
||||
sudo: ${{ matrix.os != 'windows-latest' }} # disable sudo for windows debugging
|
||||
|
||||
process-result:
|
||||
if: ${{ always() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
if: ${{ always() && github.repository_owner == 'nrwl' }}
|
||||
runs-on: ubuntu-latest
|
||||
needs: e2e
|
||||
timeout-minutes: 15
|
||||
outputs:
|
||||
message: ${{ steps.process-json.outputs.slack_message }}
|
||||
proj_duration: ${{ steps.process-json.outputs.slack_proj_duration }}
|
||||
pm_duration: ${{ steps.process-json.outputs.slack_pm_duration }}
|
||||
codeowners: ${{ steps.process-json.outputs.codeowners }}
|
||||
has_golden_failures: ${{ steps.process-json.outputs.has_golden_failures }}
|
||||
message: ${{ steps.process-json.outputs.SLACK_MESSAGE }}
|
||||
proj-duration: ${{ steps.process-json.outputs.SLACK_PROJ_DURATION }}
|
||||
pm-duration: ${{ steps.process-json.outputs.SLACK_PM_DURATION }}
|
||||
codeowners: ${{ steps.process-json.outputs.CODEOWNERS }}
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
|
||||
- name: Prepare dir for output
|
||||
run: mkdir -p outputs
|
||||
|
||||
- name: Load outputs
|
||||
uses: actions/download-artifact@634f93cb2916e3fdff6788551b99b062d0335ce0 # v5.0.0
|
||||
uses: actions/download-artifact@v3
|
||||
with:
|
||||
name: outputs
|
||||
path: outputs
|
||||
|
||||
- name: Join and stringify matrix configs
|
||||
id: combine-json
|
||||
run: |
|
||||
combined=$(jq -sc . outputs/*/matrix.json)
|
||||
combined=$((jq -s . outputs/*) | jq tostring)
|
||||
echo "combined=$combined" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Process results and collect failure details
|
||||
- name: Make slack outputs
|
||||
id: process-json
|
||||
uses: actions/github-script@v6
|
||||
env:
|
||||
GH_TOKEN: ${{ github.token }}
|
||||
run: |
|
||||
echo '${{ steps.combine-json.outputs.combined }}' | npx tsx .github/workflows/nightly/process-result.ts
|
||||
GITHUB_TOKEN: ${{ github.token }}
|
||||
with:
|
||||
script: |
|
||||
const combined = JSON.parse(${{ steps.combine-json.outputs.combined }});
|
||||
const failedProjects = combined.filter(c => c.status === 'failure').sort((a, b) => a.project.localeCompare(b.project));
|
||||
|
||||
// codeowners
|
||||
const codeowners = new Set();
|
||||
failedProjects.forEach(c => {
|
||||
codeowners.add(c.codeowners);
|
||||
});
|
||||
core.setOutput('CODEOWNERS', Array.from(codeowners).join(','));
|
||||
|
||||
function trimSpace(res) {
|
||||
return res.split('\n').map((l) => l.trim()).join('\n');
|
||||
}
|
||||
|
||||
// failed message
|
||||
let lastProject;
|
||||
let result = `
|
||||
\`\`\`
|
||||
| Failed project | PM | OS | Node |
|
||||
|--------------------------------|------|-------|------|`;
|
||||
failedProjects.forEach(matrix => {
|
||||
const project = matrix.project !== lastProject ? matrix.project : '...';
|
||||
result += `\n| ${project.padEnd(30)} | ${matrix.package_manager.padEnd(4)} | ${matrix.os_name} | v${matrix.node_version} |`
|
||||
lastProject = matrix.project;
|
||||
});
|
||||
result += `\`\`\``;
|
||||
core.setOutput('SLACK_MESSAGE', trimSpace(result));
|
||||
|
||||
function humanizeDuration(num) {
|
||||
let res = '';
|
||||
const hours = Math.floor(num / 3600);
|
||||
if (hours) {
|
||||
res += `${hours}h `;
|
||||
}
|
||||
const mins = Math.floor((num % 3600) / 60);
|
||||
if (mins) {
|
||||
res += `${mins}m `;
|
||||
}
|
||||
const sec = num % 60;
|
||||
if (sec) {
|
||||
res += `${sec}s`
|
||||
}
|
||||
return res;
|
||||
}
|
||||
|
||||
// duration message
|
||||
const timeReport = {};
|
||||
const pmReport = {
|
||||
npm: 0,
|
||||
yarn: 0,
|
||||
pnpm: 0
|
||||
};
|
||||
const macosProjects = ['e2e-detox', 'e2e-expo', 'e2e-react-native'];
|
||||
combined.forEach((matrix) => {
|
||||
if (matrix.os_name === 'Linux' && matrix.node_version === 18) {
|
||||
pmReport[matrix.package_manager] += matrix.duration;
|
||||
}
|
||||
if (matrix.os_name === 'Linux' || macosProjects.includes(matrix.project)) {
|
||||
if (timeReport[matrix.project]) {
|
||||
if (matrix.duration > timeReport[matrix.project].max) {
|
||||
timeReport[matrix.project].max = matrix.duration;
|
||||
timeReport[
|
||||
matrix.project
|
||||
].maxEnv = `${matrix.os_name}, ${matrix.package_manager}`;
|
||||
}
|
||||
if (matrix.duration < timeReport[matrix.project].min) {
|
||||
timeReport[matrix.project].min = matrix.duration;
|
||||
timeReport[
|
||||
matrix.project
|
||||
].minEnv = `${matrix.os_name}, ${matrix.package_manager}`;
|
||||
}
|
||||
} else {
|
||||
timeReport[matrix.project] = {
|
||||
min: matrix.duration,
|
||||
max: matrix.duration,
|
||||
minEnv: `${matrix.os_name}, ${matrix.package_manager}`,
|
||||
maxEnv: `${matrix.os_name}, ${matrix.package_manager}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
// project time report
|
||||
let resultPkg = `
|
||||
\`\`\`
|
||||
| Project | Time |
|
||||
|--------------------------------|---------------------------|`;
|
||||
function mapProjectTime(proj, section) {
|
||||
let res = '';
|
||||
res += `${humanizeDuration(timeReport[proj][section])}`;
|
||||
res += ` (${timeReport[proj][section + 'Env']})`
|
||||
return res;
|
||||
}
|
||||
function durationIcon(proj, section) {
|
||||
if (timeReport[proj][section] < 12 * 60) {
|
||||
return `${section} ✅`;
|
||||
}
|
||||
if (timeReport[proj][section] < 15 * 60) {
|
||||
return `${section} ❗`;
|
||||
}
|
||||
return `${section} ❌`;
|
||||
}
|
||||
Object.keys(timeReport).forEach(proj => {
|
||||
resultPkg += `\n| ${proj.padEnd(30)} | |`;
|
||||
resultPkg += `\n| ${durationIcon(proj, 'min').padStart(29)} | ${mapProjectTime(proj, 'min').padEnd(25)} |`;
|
||||
resultPkg += `\n| ${durationIcon(proj, 'max').padStart(29)} | ${mapProjectTime(proj, 'max').padEnd(25)} |`;
|
||||
});
|
||||
resultPkg += `\`\`\``;
|
||||
core.setOutput('SLACK_PROJ_DURATION', trimSpace(resultPkg));
|
||||
|
||||
// Print project duration report inline to allow reviewing on manual runs (when no slack message will be sent)
|
||||
console.log(trimSpace(resultPkg));
|
||||
|
||||
let resultPm = `
|
||||
\`\`\`
|
||||
| PM | Total time |
|
||||
|------|-------------|`;
|
||||
Object.keys(pmReport).forEach(pm => {
|
||||
resultPm += `\n| ${pm.padEnd(4)} | ${humanizeDuration(pmReport[pm]).padEnd(11)} |`
|
||||
});
|
||||
resultPm += `\`\`\``;
|
||||
core.setOutput('SLACK_PM_DURATION', trimSpace(resultPm));
|
||||
|
||||
// Print package manager duration report inline to allow reviewing on manual runs (when no slack message will be sent)
|
||||
console.log(trimSpace(resultPm));
|
||||
|
||||
report-failure:
|
||||
if: ${{ always() && needs.process-result.outputs.has_golden_failures == 'true' && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
if: ${{ failure() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: process-result
|
||||
runs-on: ubuntu-latest
|
||||
name: Report failure
|
||||
timeout-minutes: 10
|
||||
steps:
|
||||
- name: Send notification
|
||||
uses: ravsamhq/notify-slack-action@be814b201e233b2dc673608aa46e5447c8ab13f2 # v11
|
||||
uses: ravsamhq/notify-slack-action@v2
|
||||
with:
|
||||
status: 'failure'
|
||||
message_format: '${{ needs.process-result.outputs.message }}'
|
||||
notification_title: 'Golden Test Failure'
|
||||
message_format: '{emoji} Workflow has {status_message} ${{ needs.process-result.outputs.message }}'
|
||||
notification_title: '{workflow}'
|
||||
footer: '<{run_url}|View Run> / Last commit <{commit_url}|{commit_sha}>'
|
||||
mention_groups: ${{ needs.process-result.outputs.codeowners }}
|
||||
env:
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
|
||||
|
||||
report-success:
|
||||
if: ${{ always() && needs.process-result.outputs.has_golden_failures == 'false' && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: process-result
|
||||
if: ${{ success() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: e2e
|
||||
runs-on: ubuntu-latest
|
||||
name: Report status
|
||||
timeout-minutes: 10
|
||||
steps:
|
||||
- name: Send notification
|
||||
uses: ravsamhq/notify-slack-action@be814b201e233b2dc673608aa46e5447c8ab13f2 # v11
|
||||
uses: ravsamhq/notify-slack-action@v2
|
||||
with:
|
||||
status: 'success'
|
||||
message_format: '${{ needs.process-result.outputs.message }}'
|
||||
notification_title: '✅ Golden Tests: All Passed!'
|
||||
status: ${{ needs.e2e.result }}
|
||||
message_format: '{emoji} Workflow has {status_message}'
|
||||
notification_title: '{workflow}'
|
||||
footer: '<{run_url}|View Run> / Last commit <{commit_url}|{commit_sha}>'
|
||||
env:
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
|
||||
@@ -471,15 +599,14 @@ jobs:
|
||||
if: ${{ always() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: process-result
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 10
|
||||
name: Report duration per package manager
|
||||
steps:
|
||||
- name: Send notification
|
||||
uses: ravsamhq/notify-slack-action@be814b201e233b2dc673608aa46e5447c8ab13f2 # v11
|
||||
uses: ravsamhq/notify-slack-action@v2
|
||||
with:
|
||||
status: 'skipped'
|
||||
message_format: '${{ needs.process-result.outputs.pm_duration }}'
|
||||
notification_title: '⌛ Total duration per package manager (ubuntu only)'
|
||||
message_format: '${{ needs.process-result.outputs.pm-duration }}'
|
||||
notification_title: 'Total duration per package manager (ubuntu only)'
|
||||
env:
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
|
||||
|
||||
@@ -487,14 +614,13 @@ jobs:
|
||||
if: ${{ always() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: process-result
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 10
|
||||
name: Report duration per project
|
||||
name: Report duration per package manager
|
||||
steps:
|
||||
- name: Send notification
|
||||
uses: ravsamhq/notify-slack-action@be814b201e233b2dc673608aa46e5447c8ab13f2 # v11
|
||||
uses: ravsamhq/notify-slack-action@v2
|
||||
with:
|
||||
status: 'skipped'
|
||||
message_format: '${{ needs.process-result.outputs.proj_duration }}'
|
||||
notification_title: '⌛ E2E Project duration stats'
|
||||
message_format: '${{ needs.process-result.outputs.proj-duration }}'
|
||||
notification_title: 'E2E Project duration stats'
|
||||
env:
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
|
||||
|
||||
@@ -0,0 +1,388 @@
|
||||
name: E2E matrix (Windows)
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: "0 5 * * *"
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
debug_enabled:
|
||||
type: boolean
|
||||
description: 'Run the build with tmate debugging enabled (https://github.com/marketplace/actions/debugging-with-tmate)'
|
||||
required: false
|
||||
default: false
|
||||
|
||||
env:
|
||||
CYPRESS_CACHE_FOLDER: ${{ github.workspace }}/.cypress
|
||||
|
||||
permissions: { }
|
||||
jobs:
|
||||
preinstall:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
runs-on: windows-latest
|
||||
strategy:
|
||||
matrix:
|
||||
node_version:
|
||||
- 20
|
||||
- 18
|
||||
|
||||
name: Cache install (node v${{ matrix.node_version }})
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- uses: pnpm/action-setup@v2
|
||||
name: Install pnpm
|
||||
with:
|
||||
version: 8
|
||||
run_install: false
|
||||
|
||||
- name: Set node
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node_version }}
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Cache node_modules
|
||||
id: cache-modules
|
||||
uses: actions/cache@v4
|
||||
with:
|
||||
lookup-only: true
|
||||
path: '**/node_modules'
|
||||
key: ${{ runner.os }}-modules-${{ matrix.node_version }}-${{ github.run_id }}
|
||||
|
||||
- name: Install packages
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Cache Cypress
|
||||
id: cache-cypress
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
lookup-only: true
|
||||
path: '${{ github.workspace }}/.cypress'
|
||||
key: windows-cypress
|
||||
|
||||
- name: Install Cypress
|
||||
if: steps.cache-cypress.outputs.cache-hit != 'true'
|
||||
run: pnpm cypress install
|
||||
|
||||
e2e:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
needs: preinstall
|
||||
permissions:
|
||||
contents: read
|
||||
runs-on: windows-latest
|
||||
strategy:
|
||||
matrix:
|
||||
node_version:
|
||||
- 20
|
||||
- 18
|
||||
package_manager:
|
||||
- npm
|
||||
project:
|
||||
- e2e-angular
|
||||
- e2e-cypress
|
||||
- e2e-esbuild
|
||||
- e2e-eslint
|
||||
- e2e-jest
|
||||
- e2e-js
|
||||
- e2e-lerna-smoke-tests
|
||||
- e2e-next
|
||||
- e2e-node
|
||||
- e2e-nuxt
|
||||
- e2e-nx-init
|
||||
- e2e-nx
|
||||
- e2e-playwright
|
||||
- e2e-plugin
|
||||
- e2e-react
|
||||
- e2e-release
|
||||
- e2e-remix
|
||||
- e2e-rollup
|
||||
- e2e-storybook
|
||||
- e2e-vite
|
||||
- e2e-vue
|
||||
- e2e-web
|
||||
- e2e-webpack
|
||||
- e2e-workspace-create
|
||||
include:
|
||||
# codeowner groups
|
||||
- project: e2e-angular
|
||||
codeowners: 'S04SS457V38'
|
||||
- project: e2e-cypress
|
||||
codeowners: 'S04T16BTJJY'
|
||||
- project: e2e-detox
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-esbuild
|
||||
codeowners: 'S04SJ6HHP0X'
|
||||
- project: e2e-expo
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-gradle
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-jest
|
||||
codeowners: 'S04T16BTJJY'
|
||||
- project: e2e-js
|
||||
codeowners: 'S04SJ6HHP0X'
|
||||
- project: e2e-lerna-smoke-tests
|
||||
codeowners: 'S04TNCVEETS'
|
||||
- project: e2e-eslint
|
||||
codeowners: 'S04SYJGKSCT'
|
||||
- project: e2e-next
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-node
|
||||
codeowners: 'S04SJ6HHP0X'
|
||||
- project: e2e-nx-init
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-nx
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-plugin
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-release
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
- project: e2e-react
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-react-native
|
||||
codeowners: 'S04TNCNJG5N'
|
||||
- project: e2e-web
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-rollup
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-storybook
|
||||
codeowners: 'S04SVQ8H0G5'
|
||||
- project: e2e-playwright
|
||||
codeowners: 'S04SVQ8H0G5'
|
||||
- project: e2e-remix
|
||||
codeowners: 'S04SVQ8H0G5'
|
||||
- project: e2e-vite
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-vue
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-nuxt
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-webpack
|
||||
codeowners: 'S04SJ6PL98X'
|
||||
- project: e2e-workspace-create
|
||||
codeowners: 'S04SYHYKGNP'
|
||||
exclude:
|
||||
# exclude non-CNW/Lerna tests from non-LTS node versions
|
||||
- node_version: 18
|
||||
project: e2e-angular
|
||||
- node_version: 18
|
||||
project: e2e-cypress
|
||||
- node_version: 18
|
||||
project: e2e-esbuild
|
||||
- node_version: 18
|
||||
project: e2e-jest
|
||||
- node_version: 18
|
||||
project: e2e-js
|
||||
- node_version: 18
|
||||
project: e2e-eslint
|
||||
- node_version: 18
|
||||
project: e2e-next
|
||||
- node_version: 18
|
||||
project: e2e-node
|
||||
- node_version: 18
|
||||
project: e2e-nuxt
|
||||
- node_version: 18
|
||||
project: e2e-nx-init
|
||||
- node_version: 18
|
||||
project: e2e-nx
|
||||
- node_version: 18
|
||||
project: e2e-plugin
|
||||
- node_version: 18
|
||||
project: e2e-playwright
|
||||
- node_version: 18
|
||||
project: e2e-react
|
||||
- node_version: 18
|
||||
project: e2e-web
|
||||
- node_version: 18
|
||||
project: e2e-remix
|
||||
- node_version: 18
|
||||
project: e2e-rollup
|
||||
- node_version: 18
|
||||
project: e2e-storybook
|
||||
- node_version: 18
|
||||
project: e2e-vite
|
||||
- node_version: 18
|
||||
project: e2e-vue
|
||||
- node_version: 18
|
||||
project: e2e-webpack
|
||||
fail-fast: false
|
||||
|
||||
name: ${{ matrix.project }} (v${{ matrix.node_version }})
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Prepare dir for output
|
||||
run: mkdir -p outputs
|
||||
|
||||
- uses: pnpm/action-setup@v2
|
||||
name: Install pnpm
|
||||
with:
|
||||
version: 8.7.4
|
||||
run_install: false
|
||||
|
||||
- name: Use Node.js ${{ matrix.node_version }}
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node_version }}
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Cache node_modules
|
||||
id: cache-modules
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: '**/node_modules'
|
||||
key: ${{ runner.os }}-modules-${{ matrix.node_version }}-${{ github.run_id }}
|
||||
|
||||
- name: Install packages
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Cache Cypress
|
||||
id: cache-cypress
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: '${{ github.workspace }}/.cypress'
|
||||
key: ${{ runner.os }}-cypress
|
||||
|
||||
- name: Install Cypress
|
||||
if: steps.cache-cypress.outputs.cache-hit != 'true'
|
||||
run: npx cypress install
|
||||
|
||||
- name: Configure git metadata (needed for lerna smoke tests)
|
||||
run: |
|
||||
git config --global user.email test@test.com
|
||||
git config --global user.name "Test Test"
|
||||
|
||||
- name: Run e2e tests
|
||||
id: e2e-run
|
||||
run: pnpm nx run ${{ matrix.project }}:e2e-local
|
||||
shell: bash
|
||||
timeout-minutes: 180
|
||||
env:
|
||||
GIT_AUTHOR_EMAIL: test@test.com
|
||||
GIT_AUTHOR_NAME: Test
|
||||
GIT_COMMITTER_EMAIL: test@test.com
|
||||
GIT_COMMITTER_NAME: Test
|
||||
NX_E2E_CI_CACHE_KEY: e2e-gha-windows-${{ matrix.node_version }}-${{ matrix.package_manager }}
|
||||
NODE_OPTIONS: --max_old_space_size=8192
|
||||
SELECTED_PM: ${{ matrix.package_manager }}
|
||||
npm_config_registry: http://localhost:4872
|
||||
NX_CACHE_DIRECTORY: 'tmp'
|
||||
NX_E2E_SKIP_CLEANUP: 'true'
|
||||
NX_E2E_RUN_E2E: 'true'
|
||||
NX_E2E_VERBOSE_LOGGING: 'true'
|
||||
NX_PERF_LOGGING: 'false'
|
||||
NX_DAEMON: 'true'
|
||||
NX_SKIP_LOG_GROUPING: 'true'
|
||||
|
||||
- name: Save matrix config in file
|
||||
if: ${{ always() }}
|
||||
id: save-matrix
|
||||
shell: bash
|
||||
run: |
|
||||
matrix=$((
|
||||
echo '${{ toJSON(matrix) }}'
|
||||
) | jq -c '. + { "status": "${{ steps.e2e-run.outcome}}" }')
|
||||
echo "$matrix" > matrix
|
||||
path=outputs/windows-${{ matrix.node_version}}-${{ matrix.package_manager}}-${{ matrix.project }}
|
||||
echo "path=$path" >> $GITHUB_OUTPUT
|
||||
echo "$matrix" > $path
|
||||
|
||||
- name: Upload matrix config
|
||||
uses: actions/upload-artifact@v3
|
||||
if: ${{ always() }}
|
||||
with:
|
||||
name: outputs
|
||||
path: ${{ steps.save-matrix.outputs.path }}
|
||||
|
||||
- name: Setup tmate session
|
||||
if: ${{ github.event_name == 'workflow_dispatch' && inputs.debug_enabled && failure() }}
|
||||
uses: mxschmitt/action-tmate@v3.8
|
||||
timeout-minutes: 15
|
||||
with:
|
||||
sudo: false # disable sudo for windows debugging
|
||||
|
||||
process-result:
|
||||
if: ${{ always() && github.repository_owner == 'nrwl' }}
|
||||
runs-on: ubuntu-latest
|
||||
needs: e2e
|
||||
outputs:
|
||||
message: ${{ steps.process-json.outputs.SLACK_MESSAGE }}
|
||||
codeowners: ${{ steps.process-json.outputs.CODEOWNERS }}
|
||||
steps:
|
||||
- name: Load outputs
|
||||
uses: actions/download-artifact@v3
|
||||
with:
|
||||
name: outputs
|
||||
path: outputs
|
||||
|
||||
- name: Join and stringify matrix configs
|
||||
id: combine-json
|
||||
shell: bash
|
||||
run: |
|
||||
combined=$((jq -s . outputs/*) | jq tostring)
|
||||
echo "combined=$combined" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Make slack outputs
|
||||
id: process-json
|
||||
uses: actions/github-script@v6
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ github.token }}
|
||||
with:
|
||||
script: |
|
||||
const combined = JSON.parse(${{ steps.combine-json.outputs.combined }});
|
||||
const failedProjects = combined.filter(c => c.status === 'failure').sort((a, b) => a.project.localeCompare(b.project));
|
||||
|
||||
// codeowners
|
||||
const codeowners = new Set();
|
||||
failedProjects.forEach(c => {
|
||||
codeowners.add(c.codeowners);
|
||||
});
|
||||
core.setOutput('CODEOWNERS', Array.from(codeowners).join(','));
|
||||
|
||||
// message
|
||||
let result = `
|
||||
*OS* Windows
|
||||
*Package manager* npm
|
||||
\`\`\`
|
||||
| Failed project | Node |
|
||||
|--------------------------------|------|`;
|
||||
failedProjects.forEach(matrix => {
|
||||
result += `\n| ${matrix.project.padEnd(30)} | v${matrix.node_version} |`
|
||||
});
|
||||
result += `\`\`\``;
|
||||
const message = result.split('\n').map(l => l.trim()).join('\n');
|
||||
core.setOutput('SLACK_MESSAGE', message);
|
||||
|
||||
report-failure:
|
||||
if: ${{ failure() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: process-result
|
||||
runs-on: ubuntu-latest
|
||||
name: Report failure
|
||||
steps:
|
||||
- name: Send notification
|
||||
uses: ravsamhq/notify-slack-action@v2
|
||||
with:
|
||||
status: 'failure'
|
||||
message_format: '{emoji} Workflow has {status_message} ${{ needs.process-result.outputs.message }}'
|
||||
notification_title: '{workflow}'
|
||||
footer: '<{run_url}|View Run> / Last commit <{commit_url}|{commit_sha}>'
|
||||
mention_groups: ${{ needs.process-result.outputs.codeowners }}
|
||||
env:
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
|
||||
|
||||
report-success:
|
||||
if: ${{ success() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: e2e
|
||||
runs-on: ubuntu-latest
|
||||
name: Report success
|
||||
steps:
|
||||
- name: Send notification
|
||||
uses: ravsamhq/notify-slack-action@v2
|
||||
with:
|
||||
status: ${{ needs.e2e.result }}
|
||||
message_format: '{emoji} Workflow has {status_message}'
|
||||
notification_title: '{workflow}'
|
||||
footer: '<{run_url}|View Run> / Last commit <{commit_url}|{commit_sha}>'
|
||||
env:
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
|
||||
@@ -3,30 +3,29 @@ name: Generate embeddings
|
||||
on:
|
||||
schedule:
|
||||
- cron: "0 5 * * 0,4" # sunday, thursday 5AM
|
||||
|
||||
workflow_dispatch:
|
||||
jobs:
|
||||
cache-and-install:
|
||||
if: github.repository == 'nrwl/nx'
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: ['24']
|
||||
node-version: [18]
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- name: Install Node.js
|
||||
uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: '24'
|
||||
package-manager-cache: false
|
||||
node-version: 18
|
||||
|
||||
- name: Install pnpm
|
||||
uses: pnpm/action-setup@7088e561eb65bb68695d245aa206f005ef30921d # v4.1.0
|
||||
uses: pnpm/action-setup@v2
|
||||
id: pnpm-install
|
||||
with:
|
||||
version: 10.28.2
|
||||
version: 8
|
||||
run_install: false
|
||||
|
||||
- name: Get pnpm store directory
|
||||
@@ -36,7 +35,7 @@ jobs:
|
||||
echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Setup pnpm cache
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
|
||||
key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
|
||||
@@ -46,11 +45,8 @@ jobs:
|
||||
- name: Install dependencies
|
||||
run: pnpm install --no-frozen-lockfile
|
||||
|
||||
- name: Build docs
|
||||
run: npx nx build astro-docs
|
||||
|
||||
- name: Run embeddings script
|
||||
run: node --import tsx tools/documentation/create-embeddings/src/main.mts --mode=astro
|
||||
run: pnpm exec nx run tools-documentation-create-embeddings:run-node
|
||||
env:
|
||||
NX_NEXT_PUBLIC_SUPABASE_URL: ${{ secrets.NX_NEXT_PUBLIC_SUPABASE_URL }}
|
||||
NX_SUPABASE_SERVICE_ROLE_KEY: ${{ secrets.NX_SUPABASE_SERVICE_ROLE_KEY }}
|
||||
|
||||
@@ -16,21 +16,21 @@ jobs:
|
||||
name: Report status
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- uses: pnpm/action-setup@7088e561eb65bb68695d245aa206f005ef30921d # v4.1.0
|
||||
- uses: pnpm/action-setup@v2
|
||||
with:
|
||||
version: 10.28.2
|
||||
version: 8
|
||||
|
||||
- name: Use Node.js ${{ matrix.node_version }}
|
||||
uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: '24'
|
||||
node-version: '18'
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Cache node_modules
|
||||
id: cache-modules
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
lookup-only: true
|
||||
path: '**/node_modules'
|
||||
@@ -41,28 +41,27 @@ jobs:
|
||||
|
||||
- name: Download artifact
|
||||
id: download-artifact
|
||||
uses: dawidd6/action-download-artifact@268677152d06ba59fcec7a7f0b5d961b6ccd7e1e # v2 # Needed since we are downloading artifact from a different workflow run, official actions/download-artifact doesn't support this.
|
||||
uses: dawidd6/action-download-artifact@v2 # Needed since we are downloading artifact from a different workflow run, official actions/download-artifact doesn't support this.
|
||||
with:
|
||||
name: cached-issue-data
|
||||
path: ${{ github.workspace }}/scripts/issues-scraper/cached
|
||||
search_artifacts: true
|
||||
allow_forks: false
|
||||
continue-on-error: true
|
||||
|
||||
- name: Collect Issue Data
|
||||
id: collect
|
||||
run: npx tsx ./scripts/issues-scraper/index.ts
|
||||
run: npx ts-node ./scripts/issues-scraper/index.ts
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ github.token }}
|
||||
|
||||
- uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
|
||||
- uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: cached-issue-data
|
||||
path: ./scripts/issues-scraper/cached/data.json
|
||||
|
||||
- name: Send GitHub Action trigger data to Slack workflow
|
||||
id: slack
|
||||
uses: slackapi/slack-github-action@91efab103c0de0a537f72a35f6b8cda0ee76bf0a # v2.1.1
|
||||
uses: slackapi/slack-github-action@v1.23.0
|
||||
with:
|
||||
payload: ${{ steps.collect.outputs.SLACK_MESSAGE }}
|
||||
env:
|
||||
|
||||
@@ -17,7 +17,7 @@ jobs:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: dessant/lock-threads@7de207be1d3ce97a9abe6ff1306222982d1ca9f9 # v5.0.1
|
||||
- uses: dessant/lock-threads@v4
|
||||
id: lockthreads
|
||||
with:
|
||||
github-token: ${{ github.token }}
|
||||
|
||||
@@ -1,510 +0,0 @@
|
||||
import { exec } from 'child_process';
|
||||
import { execSync } from 'child_process';
|
||||
|
||||
const MAX_CONCURRENCY = 8;
|
||||
|
||||
interface MatrixResult {
|
||||
project: string;
|
||||
codeowners: string;
|
||||
node_version: number | string;
|
||||
package_manager: string;
|
||||
os: string;
|
||||
os_name: string;
|
||||
os_timeout: number;
|
||||
is_golden?: boolean;
|
||||
status: 'success' | 'failure' | 'cancelled';
|
||||
duration: number;
|
||||
}
|
||||
|
||||
interface Streak {
|
||||
consecutive_failures: number;
|
||||
failing_since: string | null;
|
||||
last_passing: string | null;
|
||||
}
|
||||
|
||||
interface HistoryEntry {
|
||||
date: string;
|
||||
failed: string[];
|
||||
}
|
||||
|
||||
interface ErrorDate {
|
||||
testFile: string;
|
||||
startDate: string;
|
||||
days: number;
|
||||
}
|
||||
|
||||
const REPO = process.env.GITHUB_REPOSITORY || 'nrwl/nx';
|
||||
const RUN_ID = process.env.GITHUB_RUN_ID || '0';
|
||||
|
||||
function gh(args: string): string {
|
||||
try {
|
||||
return execSync(`gh ${args}`, {
|
||||
encoding: 'utf-8',
|
||||
timeout: 60_000,
|
||||
maxBuffer: 10 * 1024 * 1024,
|
||||
stdio: ['pipe', 'pipe', 'pipe'],
|
||||
}).trim();
|
||||
} catch {
|
||||
return '';
|
||||
}
|
||||
}
|
||||
|
||||
function ghAsync(args: string): Promise<string> {
|
||||
return new Promise((resolve) => {
|
||||
exec(
|
||||
`gh ${args}`,
|
||||
{ encoding: 'utf-8', timeout: 60_000, maxBuffer: 10 * 1024 * 1024 },
|
||||
(err, stdout) => resolve(err ? '' : (stdout || '').trim())
|
||||
);
|
||||
});
|
||||
}
|
||||
|
||||
async function ghParallel<T>(
|
||||
items: T[],
|
||||
fn: (item: T) => string,
|
||||
concurrency = MAX_CONCURRENCY
|
||||
): Promise<Map<T, string>> {
|
||||
const results = new Map<T, string>();
|
||||
const queue = [...items];
|
||||
|
||||
async function worker() {
|
||||
while (queue.length > 0) {
|
||||
const item = queue.shift()!;
|
||||
results.set(item, await ghAsync(fn(item)));
|
||||
}
|
||||
}
|
||||
|
||||
await Promise.all(
|
||||
Array.from({ length: Math.min(concurrency, items.length) }, () => worker())
|
||||
);
|
||||
return results;
|
||||
}
|
||||
|
||||
function extractJestBlocks(raw: string): string {
|
||||
const lines = raw
|
||||
.replace(/^\d{4}-\d{2}-\d{2}T[\d:.]+Z /gm, '')
|
||||
.replace(/\x1b\[[0-9;]*[a-zA-Z]/g, '')
|
||||
.split('\n');
|
||||
|
||||
const blocks: string[] = [];
|
||||
let capturing = false;
|
||||
for (const line of lines) {
|
||||
if (line.startsWith(' FAIL ')) capturing = true;
|
||||
if (capturing) blocks.push(line);
|
||||
if (line.startsWith('Ran all test suites')) capturing = false;
|
||||
}
|
||||
return blocks.slice(0, 50).join('\n');
|
||||
}
|
||||
|
||||
function extractTestFiles(block: string): string[] {
|
||||
const matches = block.match(/FAIL\s+\S+\s+(src\/[^\s]+\.test\.ts)/g) || [];
|
||||
return [...new Set(matches.map((m) => m.replace(/FAIL\s+\S+\s+/, '')))];
|
||||
}
|
||||
|
||||
function extractBlockForFile(fullBlock: string, testFile: string): string {
|
||||
const lines = fullBlock.split('\n');
|
||||
const result: string[] = [];
|
||||
let capturing = false;
|
||||
for (const line of lines) {
|
||||
if (line.includes('FAIL') && line.includes(testFile)) capturing = true;
|
||||
else if (capturing && line.match(/^ FAIL /)) capturing = false;
|
||||
if (capturing) result.push(line);
|
||||
}
|
||||
return result.slice(0, 20).join('\n');
|
||||
}
|
||||
|
||||
/**
|
||||
* Collects detailed failure information for golden projects.
|
||||
* Called by process-result.ts when golden failures exist.
|
||||
* Returns Slack mrkdwn formatted failure details.
|
||||
*/
|
||||
export async function collectFailureDetails(
|
||||
combined: MatrixResult[],
|
||||
failedGoldenProjectNames: string[]
|
||||
): Promise<string> {
|
||||
const projectNames = failedGoldenProjectNames;
|
||||
if (projectNames.length === 0) return '';
|
||||
|
||||
// Group failures by project for combo info
|
||||
const failuresByProject = new Map<string, MatrixResult[]>();
|
||||
for (const r of combined) {
|
||||
if (r.is_golden && (r.status === 'failure' || r.status === 'cancelled')) {
|
||||
if (!failuresByProject.has(r.project))
|
||||
failuresByProject.set(r.project, []);
|
||||
failuresByProject.get(r.project)!.push(r);
|
||||
}
|
||||
}
|
||||
|
||||
// Step 1: 30-day failure history
|
||||
const histRunsRaw = gh(
|
||||
`run list --workflow=e2e-matrix.yml --repo ${REPO} --limit 40 --json databaseId,createdAt,event --jq '[.[] | select(.event == "schedule" and .databaseId != ${RUN_ID})] | .[0:30]'`
|
||||
);
|
||||
const histRuns: Array<{ databaseId: number; createdAt: string }> =
|
||||
histRunsRaw ? JSON.parse(histRunsRaw) : [];
|
||||
|
||||
const histResults = await ghParallel(
|
||||
histRuns.map((r) => r.databaseId),
|
||||
(rid) =>
|
||||
`run view ${rid} --repo ${REPO} --json jobs --jq '[.jobs[] | select(.conclusion == "failure") | .name | split(" ") | last] | unique'`
|
||||
);
|
||||
|
||||
const history: HistoryEntry[] = histRuns.map((run) => {
|
||||
const raw = histResults.get(run.databaseId) || '[]';
|
||||
try {
|
||||
return { date: run.createdAt, failed: JSON.parse(raw) };
|
||||
} catch {
|
||||
return { date: run.createdAt, failed: [] };
|
||||
}
|
||||
});
|
||||
|
||||
// Compute streaks
|
||||
const streaks = new Map<string, Streak>();
|
||||
for (const project of projectNames) {
|
||||
let streak = 0,
|
||||
firstSeen: string | null = null,
|
||||
lastPassing: string | null = null,
|
||||
broken = false;
|
||||
for (const entry of history) {
|
||||
if (broken) break;
|
||||
if (entry.failed.includes(project)) {
|
||||
streak++;
|
||||
firstSeen = entry.date;
|
||||
} else {
|
||||
broken = true;
|
||||
lastPassing = entry.date;
|
||||
}
|
||||
}
|
||||
streaks.set(project, {
|
||||
consecutive_failures: streak,
|
||||
failing_since: firstSeen ? firstSeen.split('T')[0] : null,
|
||||
last_passing: lastPassing ? lastPassing.split('T')[0] : null,
|
||||
});
|
||||
}
|
||||
|
||||
// Step 2: Fetch failure logs (one per OS/PM combo per project)
|
||||
const failedJobsRaw = gh(
|
||||
`run view ${RUN_ID} --repo ${REPO} --json jobs --jq '[.jobs[] | select(.conclusion == "failure") | {id: .databaseId, name: .name, project: (.name | split(" ") | last), combo: (.name | split(" ")[0])}]'`
|
||||
);
|
||||
const failedJobs: Array<{
|
||||
id: number;
|
||||
name: string;
|
||||
project: string;
|
||||
combo: string;
|
||||
}> = failedJobsRaw ? JSON.parse(failedJobsRaw) : [];
|
||||
|
||||
const jobsToFetch: Array<{ id: number; project: string }> = [];
|
||||
for (const project of projectNames) {
|
||||
const seen = new Set<string>();
|
||||
for (const job of failedJobs.filter((j) => j.project === project)) {
|
||||
const key = job.combo.split('/').slice(0, 2).join('/');
|
||||
if (!seen.has(key)) {
|
||||
seen.add(key);
|
||||
jobsToFetch.push({ id: job.id, project: job.project });
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
const logResults = await ghParallel(
|
||||
jobsToFetch,
|
||||
(job) => `api repos/${REPO}/actions/jobs/${job.id}/logs`
|
||||
);
|
||||
|
||||
const projectLogs = new Map<string, string>();
|
||||
for (const [job, raw] of logResults) {
|
||||
if (!raw) continue;
|
||||
const block = extractJestBlocks(raw);
|
||||
projectLogs.set(
|
||||
job.project,
|
||||
(projectLogs.get(job.project) || '') + '\n' + block
|
||||
);
|
||||
}
|
||||
|
||||
// Step 3: Per-project error validation
|
||||
const validations = new Map<
|
||||
string,
|
||||
{
|
||||
status: 'new' | 'confirmed' | 'different' | 'unknown';
|
||||
firstTestFiles: string[];
|
||||
currentTestFiles: string[];
|
||||
}
|
||||
>();
|
||||
|
||||
for (const project of projectNames) {
|
||||
const streak = streaks.get(project)!;
|
||||
const currentFiles = extractTestFiles(projectLogs.get(project) || '');
|
||||
|
||||
if (streak.consecutive_failures <= 1 || !streak.failing_since) {
|
||||
validations.set(project, {
|
||||
status: streak.consecutive_failures <= 1 ? 'new' : 'unknown',
|
||||
firstTestFiles: [],
|
||||
currentTestFiles: currentFiles,
|
||||
});
|
||||
continue;
|
||||
}
|
||||
|
||||
const firstRun = histRuns.find(
|
||||
(r) => r.createdAt.split('T')[0] === streak.failing_since
|
||||
);
|
||||
if (!firstRun) {
|
||||
validations.set(project, {
|
||||
status: 'unknown',
|
||||
firstTestFiles: [],
|
||||
currentTestFiles: currentFiles,
|
||||
});
|
||||
continue;
|
||||
}
|
||||
|
||||
const firstJobId = gh(
|
||||
`run view ${firstRun.databaseId} --repo ${REPO} --json jobs --jq '[.jobs[] | select(.conclusion == "failure" and (.name | split(" ") | last) == "${project}")][0].databaseId'`
|
||||
);
|
||||
if (!firstJobId || firstJobId === 'null') {
|
||||
validations.set(project, {
|
||||
status: 'unknown',
|
||||
firstTestFiles: [],
|
||||
currentTestFiles: currentFiles,
|
||||
});
|
||||
continue;
|
||||
}
|
||||
|
||||
const firstLog = gh(`api repos/${REPO}/actions/jobs/${firstJobId}/logs`);
|
||||
const firstFiles = extractTestFiles(firstLog ? extractJestBlocks(firstLog) : '');
|
||||
|
||||
validations.set(project, {
|
||||
status:
|
||||
[...currentFiles].sort().join(',') === [...firstFiles].sort().join(',')
|
||||
? 'confirmed'
|
||||
: 'different',
|
||||
firstTestFiles: firstFiles,
|
||||
currentTestFiles: currentFiles,
|
||||
});
|
||||
}
|
||||
|
||||
// Step 4: Per-error binary search for "different" projects
|
||||
const errorDates = new Map<string, ErrorDate[]>();
|
||||
|
||||
for (const [project, val] of validations) {
|
||||
if (val.status !== 'different') continue;
|
||||
const streak = streaks.get(project)!;
|
||||
const firstSet = new Set(val.firstTestFiles);
|
||||
const unreliable = val.currentTestFiles.filter((f) => !firstSet.has(f));
|
||||
if (!unreliable.length) continue;
|
||||
|
||||
const projRunIds = histRuns
|
||||
.slice(0, streak.consecutive_failures)
|
||||
.map((r) => r.databaseId);
|
||||
if (projRunIds.length <= 1) continue;
|
||||
|
||||
const dates: ErrorDate[] = [];
|
||||
for (const tf of unreliable) {
|
||||
let low = 0,
|
||||
high = projRunIds.length - 1;
|
||||
|
||||
const oldestJobId = gh(
|
||||
`run view ${projRunIds[high]} --repo ${REPO} --json jobs --jq '[.jobs[] | select(.conclusion == "failure" and (.name | split(" ") | last) == "${project}")][0].databaseId'`
|
||||
);
|
||||
let oldestHas = false;
|
||||
if (oldestJobId && oldestJobId !== 'null') {
|
||||
const log = gh(`api repos/${REPO}/actions/jobs/${oldestJobId}/logs`);
|
||||
oldestHas = new RegExp(`FAIL.*${tf.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}`).test(log);
|
||||
}
|
||||
|
||||
if (oldestHas) {
|
||||
const run = histRuns.find((r) => r.databaseId === projRunIds[high]);
|
||||
dates.push({
|
||||
testFile: tf,
|
||||
startDate: run?.createdAt.split('T')[0] || 'unknown',
|
||||
days: projRunIds.length,
|
||||
});
|
||||
continue;
|
||||
}
|
||||
|
||||
while (high - low > 1) {
|
||||
const mid = Math.floor((low + high) / 2);
|
||||
const midJobId = gh(
|
||||
`run view ${projRunIds[mid]} --repo ${REPO} --json jobs --jq '[.jobs[] | select(.conclusion == "failure" and (.name | split(" ") | last) == "${project}")][0].databaseId'`
|
||||
);
|
||||
let midHas = false;
|
||||
if (midJobId && midJobId !== 'null') {
|
||||
const log = gh(`api repos/${REPO}/actions/jobs/${midJobId}/logs`);
|
||||
midHas = new RegExp(`FAIL.*${tf.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}`).test(log);
|
||||
}
|
||||
if (midHas) low = mid;
|
||||
else high = mid;
|
||||
}
|
||||
|
||||
const foundRun = histRuns.find((r) => r.databaseId === projRunIds[low]);
|
||||
dates.push({
|
||||
testFile: tf,
|
||||
startDate: foundRun?.createdAt.split('T')[0] || 'unknown',
|
||||
days: low + 1,
|
||||
});
|
||||
}
|
||||
errorDates.set(project, dates);
|
||||
}
|
||||
|
||||
// Step 5: Recent commits
|
||||
let commitCount = 0;
|
||||
if (histRuns[0]?.createdAt) {
|
||||
try {
|
||||
const commits = execSync(
|
||||
`git log origin/master --after="${histRuns[0].createdAt}" --format="%h" --no-merges 2>/dev/null | head -30`,
|
||||
{ encoding: 'utf-8', timeout: 10_000 }
|
||||
).trim();
|
||||
commitCount = commits ? commits.split('\n').length : 0;
|
||||
} catch {
|
||||
/* git not available */
|
||||
}
|
||||
}
|
||||
|
||||
// Step 6: Format report
|
||||
const lines: string[] = ['', '🔍 *Failure Details*', ''];
|
||||
|
||||
const sorted = [...projectNames].sort((a, b) => {
|
||||
const sa = streaks.get(a)?.consecutive_failures || 0;
|
||||
const sb = streaks.get(b)?.consecutive_failures || 0;
|
||||
return (
|
||||
sa - sb ||
|
||||
(failuresByProject.get(b)?.length || 0) -
|
||||
(failuresByProject.get(a)?.length || 0)
|
||||
);
|
||||
});
|
||||
|
||||
for (const project of sorted) {
|
||||
const streak = streaks.get(project)!;
|
||||
const val = validations.get(project);
|
||||
const block = projectLogs.get(project) || '';
|
||||
const testFiles = extractTestFiles(block);
|
||||
const projResults = failuresByProject.get(project) || [];
|
||||
|
||||
const pms = [...new Set(projResults.map((r) => r.package_manager))];
|
||||
const pattern =
|
||||
pms.length === 1
|
||||
? `${pms[0]}-only`
|
||||
: pms.length >= 3
|
||||
? 'all PMs'
|
||||
: pms.join('+');
|
||||
|
||||
const since = streak.failing_since || 'today (new)';
|
||||
const lastPass = streak.last_passing || '—';
|
||||
const uniqueCombos = [
|
||||
...new Set(
|
||||
failedJobs.filter((j) => j.project === project).map((j) => j.combo)
|
||||
),
|
||||
];
|
||||
|
||||
lines.push('———————————————————————————');
|
||||
lines.push(`*${project}* — ${projResults.length} combos (${pattern})`);
|
||||
lines.push(`Project failing since ${since} | Last fully passing: ${lastPass}`);
|
||||
lines.push('');
|
||||
|
||||
if (testFiles.length > 0) {
|
||||
for (const tf of testFiles) {
|
||||
let errorDate = since;
|
||||
let errorDays: number | string = streak.consecutive_failures || 1;
|
||||
let label = '';
|
||||
|
||||
const fileDates = errorDates.get(project);
|
||||
const fd = fileDates?.find((d) => d.testFile === tf);
|
||||
if (fd) {
|
||||
errorDate = fd.startDate;
|
||||
errorDays = fd.days;
|
||||
}
|
||||
|
||||
if (val?.status === 'different' && !val.firstTestFiles.includes(tf)) {
|
||||
label = ' ⚠️ error changed mid-streak';
|
||||
}
|
||||
if (errorDays === 1 || errorDays === '1') {
|
||||
label = ' 🆕 NEW';
|
||||
}
|
||||
|
||||
lines.push(
|
||||
`📋 \`${tf}\` — failing since ${errorDate} (${errorDays} ${errorDays === 1 || errorDays === '1' ? 'day' : 'days'})${label}`
|
||||
);
|
||||
|
||||
const fileBlock = extractBlockForFile(block, tf);
|
||||
if (fileBlock) {
|
||||
lines.push('```');
|
||||
lines.push(fileBlock);
|
||||
lines.push('```');
|
||||
}
|
||||
}
|
||||
|
||||
const summaryMatch = block.match(/^Test Suites:.*$/m);
|
||||
if (summaryMatch) lines.push(`_${summaryMatch[0]}_`);
|
||||
lines.push(`Failing combos: ${uniqueCombos.join(', ')}`);
|
||||
} else {
|
||||
// No Jest blocks — find which step failed and extract its error output
|
||||
const firstJob = failedJobs.find((j) => j.project === project);
|
||||
if (firstJob) {
|
||||
// Get the failed step name from the jobs API
|
||||
const stepsRaw = gh(
|
||||
`run view ${RUN_ID} --repo ${REPO} --json jobs --jq '[.jobs[] | select(.databaseId == ${firstJob.id})][0].steps[] | select(.conclusion == "failure") | .name'`
|
||||
);
|
||||
const failedStep = stepsRaw || 'unknown step';
|
||||
|
||||
// Get the log and extract error lines
|
||||
const raw = gh(`api repos/${REPO}/actions/jobs/${firstJob.id}/logs`);
|
||||
const cleaned = raw
|
||||
.split('\n')
|
||||
.map((l) => l.replace(/^\d{4}-\d{2}-\d{2}T[\d:.]+Z /, ''))
|
||||
.map((l) => l.replace(/\x1b\[[0-9;]*[a-zA-Z]/g, ''));
|
||||
|
||||
// Extract the Nx failure summary block ("Running target...failed" + "Failed tasks:" + task list)
|
||||
const nxFailureBlock: string[] = [];
|
||||
let capturingNx = false;
|
||||
for (const l of cleaned) {
|
||||
if (/NX.*Running target.*failed/i.test(l)) capturingNx = true;
|
||||
if (capturingNx) {
|
||||
nxFailureBlock.push(l);
|
||||
// Stop after "Hint:" line or after 10 lines
|
||||
if (/^Hint:/i.test(l.trim()) || nxFailureBlock.length >= 10) {
|
||||
capturingNx = false;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Also extract individual error lines (build errors, module errors, etc.)
|
||||
const errorLines = cleaned.filter((l) => {
|
||||
const trimmed = l.trim();
|
||||
if (trimmed.length < 10) return false;
|
||||
if (/warning|warn\b|deprecated|orphan|Node\.js 20|FORCE_JAVASCRIPT|\* \[new branch\]|\* \[new tag\]/i.test(trimmed)) return false;
|
||||
return (
|
||||
/^error TS\d+:|^Error:|^\s*error\b[:\s]|ERR!|ERESOLVE|##\[error\]/i.test(trimmed) ||
|
||||
/Cannot find module|ENOENT|EACCES|permission denied/i.test(trimmed) ||
|
||||
/Segmentation fault|killed|OOM|out of memory/i.test(trimmed) ||
|
||||
/command not found|No such file or directory/i.test(trimmed) ||
|
||||
/Process completed with exit code [^0]/i.test(trimmed)
|
||||
);
|
||||
});
|
||||
|
||||
// Combine: Nx failure block first (most useful), then individual errors not already included
|
||||
const nxBlockText = nxFailureBlock.join('\n');
|
||||
const additionalErrors = errorLines
|
||||
.filter((l) => !nxBlockText.includes(l))
|
||||
.slice(0, 3);
|
||||
|
||||
const relevantErrors = [
|
||||
...nxFailureBlock,
|
||||
...(additionalErrors.length > 0 ? ['', ...additionalErrors] : []),
|
||||
];
|
||||
|
||||
lines.push(`⚠️ Tests did not run — failed at step: *${failedStep}*`);
|
||||
if (relevantErrors.length > 0) {
|
||||
lines.push('```');
|
||||
lines.push(relevantErrors.join('\n'));
|
||||
lines.push('```');
|
||||
}
|
||||
lines.push(`Failing combos: ${uniqueCombos.join(', ')}`);
|
||||
} else {
|
||||
lines.push('⏱️ No job data available');
|
||||
}
|
||||
}
|
||||
lines.push('');
|
||||
}
|
||||
|
||||
if (commitCount > 0) {
|
||||
lines.push(`_${commitCount} commits since last nightly_`);
|
||||
}
|
||||
|
||||
return lines.join('\n');
|
||||
}
|
||||
@@ -1,135 +0,0 @@
|
||||
type MatrixDataProject = {
|
||||
name: string,
|
||||
codeowners: string,
|
||||
is_golden?: boolean, // true if this is a golden project, false otherwise
|
||||
};
|
||||
|
||||
type MatrixDataOS = {
|
||||
os: string, // GH runner machine name: e.g. ubuntu-latest
|
||||
os_name: string, // short name that will be printed in the report and on the action
|
||||
os_timeout: number, // 60
|
||||
package_managers: string[], // package managers to run on this OS
|
||||
node_versions: Array<number | string>, // node versions to run on this OS
|
||||
excluded?: string[], // projects to exclude from running on this OS
|
||||
};
|
||||
|
||||
type MatrixData = {
|
||||
coreProjects: MatrixDataProject[],
|
||||
projects: MatrixDataProject[],
|
||||
nodeTLS: number,
|
||||
setup: MatrixDataOS[],
|
||||
}
|
||||
|
||||
export type MatrixItem = {
|
||||
project: string,
|
||||
codeowners: string,
|
||||
node_version: number | string,
|
||||
package_manager: string,
|
||||
os: string,
|
||||
os_name: string,
|
||||
os_timeout: number,
|
||||
is_golden?: boolean,
|
||||
};
|
||||
|
||||
// TODO: Extract Slack groups into named groups for easier maintenance
|
||||
const matrixData: MatrixData = {
|
||||
coreProjects: [
|
||||
{ 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' },
|
||||
{ name: 'e2e-release', codeowners: 'S04SYHYKGNP' },
|
||||
{ name: 'e2e-workspace-create', codeowners: 'S04SYHYKGNP' }
|
||||
],
|
||||
projects: [
|
||||
{ name: 'e2e-cypress', codeowners: 'S04T16BTJJY', is_golden: true },
|
||||
{ name: 'e2e-docker', codeowners: 'S04SJ6HHP0X', 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-expo', codeowners: 'S04TNCNJG5N', is_golden: true },
|
||||
{ name: 'e2e-react-native', codeowners: 'S04TNCNJG5N', is_golden: true },
|
||||
{ name: 'e2e-angular', codeowners: 'S04SS457V38' },
|
||||
{ name: 'e2e-next', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-plugin', codeowners: 'S04SYHYKGNP' },
|
||||
{ name: 'e2e-react', codeowners: 'S04TNCNJG5N' },
|
||||
{ name: 'e2e-rollup', codeowners: 'S04SJ6PL98X' },
|
||||
{ name: 'e2e-storybook', codeowners: 'S04SVQ8H0G5' },
|
||||
{ name: 'e2e-nuxt', codeowners: 'S04SJ6PL98X' }
|
||||
],
|
||||
// TODO(v23): remove node 20 - EOL April 2026
|
||||
nodeTLS: 20,
|
||||
setup: [
|
||||
{
|
||||
os: 'ubuntu-latest',
|
||||
os_name: 'Linux',
|
||||
os_timeout: 60,
|
||||
package_managers: ['npm', 'pnpm', 'yarn'],
|
||||
node_versions: ['20.19.0', '22.13.0', '24.0.0'],
|
||||
excluded: ['e2e-detox', 'e2e-react-native', 'e2e-expo']
|
||||
},
|
||||
// Docker is not supported on ARM-based macOS runners (no nested virtualization)
|
||||
// See: https://github.com/docker/setup-docker-action and https://github.com/douglascamata/setup-docker-macos-action
|
||||
// We may want to look into adding intel only for this docker case, at least until vm-in-vm works on latest macos
|
||||
{ os: 'macos-latest', os_name: 'MacOS', os_timeout: 90, package_managers: ['npm'], node_versions: ['24.0.0'], excluded: ['e2e-docker'] }
|
||||
// TODO (Jack): Fix Windows support as gradle fails when running nx build https://staging.nx.app/runs/LgD4vxGn8w?utm_source=pull-request&utm_medium=comment
|
||||
// { os: 'windows-latest', os_name: 'WinOS', os_timeout: 180, package_managers: ['npm'], node_versions: ['24.0.0'], excluded: ['e2e-detox', 'e2e-react-native', 'e2e-expo'] }
|
||||
]
|
||||
};
|
||||
|
||||
const matrix: Array<MatrixItem> = [];
|
||||
|
||||
function addMatrixCombo(project: MatrixDataProject, nodeVersion: number | string, pm: number, os: number) {
|
||||
matrix.push({
|
||||
project: project.name,
|
||||
codeowners: project.codeowners,
|
||||
node_version: nodeVersion,
|
||||
package_manager: matrixData.setup[os].package_managers[pm],
|
||||
os: matrixData.setup[os].os,
|
||||
os_name: matrixData.setup[os].os_name,
|
||||
os_timeout: matrixData.setup[os].os_timeout,
|
||||
is_golden: !!project.is_golden // Mark golden projects as true, others as false
|
||||
});
|
||||
}
|
||||
|
||||
function processProject(project: MatrixDataProject, nodeVersion?: number) {
|
||||
for (let os = 0; os < matrixData.setup.length; os++) {
|
||||
for (let pm = 0; pm < matrixData.setup[os].package_managers.length; pm++) {
|
||||
if (!matrixData.setup[os].excluded || !matrixData.setup[os].excluded?.includes(project.name)) {
|
||||
if (nodeVersion) {
|
||||
addMatrixCombo(project, nodeVersion, pm, os);
|
||||
} else {
|
||||
for (let n = 0; n < matrixData.setup[os].node_versions.length; n++) {
|
||||
addMatrixCombo(project, matrixData.setup[os].node_versions[n], pm, os);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// process core projects
|
||||
for (let p = 0; p < matrixData.coreProjects.length; p++) {
|
||||
processProject(matrixData.coreProjects[p]);
|
||||
}
|
||||
// process other projects
|
||||
for (let p = 0; p < matrixData.projects.length; p++) {
|
||||
processProject(matrixData.projects[p], matrixData.nodeTLS);
|
||||
}
|
||||
|
||||
if (matrix.length > 256) {
|
||||
throw new Error('You have exceeded the size of the matrix. GitHub allows only 256 jobs in a matrix. Found ${matrix.length} jobs.');
|
||||
}
|
||||
|
||||
// print result to stdout for pipeline to consume
|
||||
process.stdout.write(JSON.stringify({ include: matrix }, null, 0));
|
||||
@@ -1,220 +0,0 @@
|
||||
import * as fs from 'fs';
|
||||
import { MatrixItem } from './process-matrix';
|
||||
import { collectFailureDetails } from './analyze-failures';
|
||||
|
||||
interface MatrixResult extends MatrixItem {
|
||||
status: 'success' | 'failure' | 'cancelled';
|
||||
duration: number;
|
||||
}
|
||||
|
||||
interface ProcessedResults {
|
||||
codeowners: string;
|
||||
slack_message: string;
|
||||
slack_proj_duration: string;
|
||||
slack_pm_duration: string;
|
||||
has_golden_failures: string;
|
||||
}
|
||||
|
||||
function trimSpace(res: string): string {
|
||||
return res.split('\n').map((l) => l.trim()).join('\n');
|
||||
}
|
||||
|
||||
function humanizeDuration(num: number): string {
|
||||
let res = '';
|
||||
const hours = Math.floor(num / 3600);
|
||||
if (hours) res += `${hours}h `;
|
||||
const mins = Math.floor((num % 3600) / 60);
|
||||
if (mins) res += `${mins}m `;
|
||||
const sec = num % 60;
|
||||
if (sec) res += `${sec}s`;
|
||||
return res;
|
||||
}
|
||||
|
||||
function processResults(combined: MatrixResult[]): ProcessedResults {
|
||||
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 = '';
|
||||
|
||||
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 += `\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 : '';
|
||||
if (project) {
|
||||
result += `\n| ${project.padEnd(30)} |`;
|
||||
lastProject = matrix.project;
|
||||
}
|
||||
});
|
||||
result += `\n\`\`\``;
|
||||
}
|
||||
|
||||
result += `\n\n🔧 *Other Projects*`;
|
||||
result += `\n✅ Passing: ${otherPassingCount}`;
|
||||
result += `\n❌ Failing: ${otherFailingCount}`;
|
||||
|
||||
// Failed Other Projects Table (if any)
|
||||
if (failedRegularProjects.length > 0) {
|
||||
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 : '';
|
||||
if (project) {
|
||||
result += `\n| ${project.padEnd(30)} |`;
|
||||
lastProject = matrix.project;
|
||||
}
|
||||
});
|
||||
result += `\n\`\`\``;
|
||||
}
|
||||
|
||||
if (failedProjects.length === 0) {
|
||||
result = '🎉 *No test failures detected!* All systems green! 🟢';
|
||||
}
|
||||
|
||||
const timeReport: Record<string, { min: number; max: number; minEnv: string; maxEnv: string }> = {};
|
||||
const pmReport = { npm: 0, yarn: 0, pnpm: 0 };
|
||||
const macosProjects = ['e2e-detox', 'e2e-expo', 'e2e-react-native'];
|
||||
|
||||
combined.forEach(matrix => {
|
||||
const nodeVersion = parseInt(matrix.node_version.toString());
|
||||
if (matrix.os_name === 'Linux' && nodeVersion === 20 && matrix.package_manager in pmReport) {
|
||||
pmReport[matrix.package_manager as keyof typeof pmReport] += matrix.duration;
|
||||
}
|
||||
if (matrix.os_name === 'Linux' || macosProjects.includes(matrix.project)) {
|
||||
if (timeReport[matrix.project]) {
|
||||
if (matrix.duration > timeReport[matrix.project].max) {
|
||||
timeReport[matrix.project].max = matrix.duration;
|
||||
timeReport[matrix.project].maxEnv = `${matrix.os_name}, ${matrix.package_manager}`;
|
||||
}
|
||||
if (matrix.duration < timeReport[matrix.project].min) {
|
||||
timeReport[matrix.project].min = matrix.duration;
|
||||
timeReport[matrix.project].minEnv = `${matrix.os_name}, ${matrix.package_manager}`;
|
||||
}
|
||||
} else {
|
||||
timeReport[matrix.project] = {
|
||||
min: matrix.duration,
|
||||
max: matrix.duration,
|
||||
minEnv: `${matrix.os_name}, ${matrix.package_manager}`,
|
||||
maxEnv: `${matrix.os_name}, ${matrix.package_manager}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
let resultPkg = `
|
||||
\`\`\`
|
||||
| Project | Time |
|
||||
|--------------------------------|---------------------------|`;
|
||||
|
||||
function mapProjectTime(proj: string, section: 'min' | 'max'): string {
|
||||
return `${humanizeDuration(timeReport[proj][section])} (${timeReport[proj][`${section}Env`]})`;
|
||||
}
|
||||
|
||||
function durationIcon(proj: string, section: 'min' | 'max'): string {
|
||||
const duration = timeReport[proj][section];
|
||||
if (duration < 12 * 60) return `${section} ✅`;
|
||||
if (duration < 15 * 60) return `${section} ❗`;
|
||||
return `${section} ❌`;
|
||||
}
|
||||
|
||||
Object.keys(timeReport).forEach(proj => {
|
||||
resultPkg += `\n| ${proj.padEnd(30)} | |`;
|
||||
resultPkg += `\n| ${durationIcon(proj, 'min').padStart(29)} | ${mapProjectTime(proj, 'min').padEnd(25)} |`;
|
||||
resultPkg += `\n| ${durationIcon(proj, 'max').padStart(29)} | ${mapProjectTime(proj, 'max').padEnd(25)} |`;
|
||||
});
|
||||
resultPkg += `\`\`\``;
|
||||
|
||||
let resultPm = `
|
||||
\`\`\`
|
||||
| PM | Total time |
|
||||
|------|-------------|`;
|
||||
Object.keys(pmReport).forEach(pm => {
|
||||
resultPm += `\n| ${pm.padEnd(4)} | ${humanizeDuration(pmReport[pm as keyof typeof pmReport]).padEnd(11)} |`;
|
||||
});
|
||||
resultPm += `\`\`\``;
|
||||
|
||||
return {
|
||||
codeowners: Array.from(codeowners).join(','),
|
||||
slack_message: trimSpace(result),
|
||||
slack_proj_duration: trimSpace(resultPkg),
|
||||
slack_pm_duration: trimSpace(resultPm),
|
||||
has_golden_failures: hasGoldenFailures.toString(),
|
||||
};
|
||||
}
|
||||
|
||||
function setOutput(key: string, value: string) {
|
||||
const outputPath = process.env.GITHUB_OUTPUT;
|
||||
if (!outputPath) {
|
||||
console.warn(`GITHUB_OUTPUT not set. Skipping output for "${key}".`);
|
||||
return;
|
||||
}
|
||||
|
||||
if (value.includes('\n')) {
|
||||
const delimiter = `EOF_${key}_${Date.now()}`;
|
||||
fs.appendFileSync(outputPath, `${key}<<${delimiter}\n${value}\n${delimiter}\n`);
|
||||
} else {
|
||||
fs.appendFileSync(outputPath, `${key}=${value}\n`);
|
||||
}
|
||||
}
|
||||
|
||||
async function main() {
|
||||
const combinedInput = process.argv[2]
|
||||
? process.argv[2]
|
||||
: fs.readFileSync(0, 'utf-8').trim();
|
||||
|
||||
const combined: MatrixResult[] = JSON.parse(combinedInput);
|
||||
const results = processResults(combined);
|
||||
|
||||
// Collect detailed failure info if golden failures exist
|
||||
if (results.has_golden_failures === 'true') {
|
||||
try {
|
||||
const failedProjects = [
|
||||
...new Set(
|
||||
combined
|
||||
.filter((c) => c.is_golden && (c.status === 'failure' || c.status === 'cancelled'))
|
||||
.map((c) => c.project)
|
||||
),
|
||||
];
|
||||
const details = await collectFailureDetails(combined, failedProjects);
|
||||
if (details) {
|
||||
results.slack_message += '\n\n' + details;
|
||||
}
|
||||
} catch (e) {
|
||||
console.error('Failed to collect failure details (brief report will still be posted):', e);
|
||||
results.slack_message += '\n\n⚠️ _Failed to collect detailed failure information_';
|
||||
}
|
||||
}
|
||||
|
||||
Object.entries(results).forEach(([key, value]) => {
|
||||
setOutput(key, value);
|
||||
});
|
||||
}
|
||||
|
||||
main().catch((error) => {
|
||||
console.error('Error processing results:', error);
|
||||
process.exit(1);
|
||||
});
|
||||
@@ -8,21 +8,25 @@ on:
|
||||
permissions: {}
|
||||
jobs:
|
||||
audit:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
permissions:
|
||||
contents: read # to fetch code (actions/checkout)
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- uses: pnpm/action-setup@7088e561eb65bb68695d245aa206f005ef30921d # v4.1.0
|
||||
with:
|
||||
version: 10.28.2 # Aligned with root package.json (pnpm/action-setup will helpfully error if out of sync)
|
||||
- name: Install PNPM
|
||||
run: |
|
||||
npm install -g @pnpm/exe@8
|
||||
|
||||
- name: Run a security audit
|
||||
run: pnpm dlx audit-ci --critical --report-type summary
|
||||
|
||||
# - name: Run Dependency confusion supply chain check
|
||||
# run: npx snync -d .
|
||||
|
||||
report:
|
||||
if: ${{ always() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
|
||||
needs: audit
|
||||
@@ -30,7 +34,7 @@ jobs:
|
||||
name: Report status
|
||||
steps:
|
||||
- name: Send notification
|
||||
uses: ravsamhq/notify-slack-action@be814b201e233b2dc673608aa46e5447c8ab13f2 # v11
|
||||
uses: ravsamhq/notify-slack-action@v2
|
||||
with:
|
||||
status: ${{ needs.audit.result }}
|
||||
message_format: '{emoji} Audit has {status_message}'
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
name: PR Title Validation
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
types: [opened, edited, synchronize, reopened]
|
||||
|
||||
permissions: read-all
|
||||
|
||||
jobs:
|
||||
validate-pr-title:
|
||||
name: Validate PR Title
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
with:
|
||||
# Ensure's validate-pr-title.js is the copy from master
|
||||
ref: master
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
|
||||
with:
|
||||
node-version: 24
|
||||
package-manager-cache: false
|
||||
|
||||
- name: Validate PR title
|
||||
env:
|
||||
PR_TITLE: ${{ github.event.pull_request.title }}
|
||||
PR_BODY: ${{ github.event.pull_request.body }}
|
||||
run: node ./scripts/validate-pr-title.js
|
||||
+129
-349
@@ -3,7 +3,7 @@ name: publish
|
||||
on:
|
||||
# Automated schedule - canary releases from master
|
||||
schedule:
|
||||
- cron: "0 19 * * 1-5" # Monday - Friday, at 19:00 UTC (7pm UTC)
|
||||
- cron: "0 3 * * 2-6" # Tuesdays - Saturdays, at 3am UTC
|
||||
# Manual trigger - PR releases or dry-runs (based on workflow inputs)
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
@@ -21,8 +21,8 @@ env:
|
||||
DEBUG: napi:*
|
||||
NX_RUN_GROUP: ${{ github.run_id }}-${{ github.run_attempt }}
|
||||
CYPRESS_INSTALL_BINARY: 0
|
||||
NODE_VERSION: 22.16.0
|
||||
PNPM_VERSION: 10.28.2 # Aligned with root package.json (pnpm/action-setup will helpfully error if out of sync)
|
||||
NODE_VERSION: 18
|
||||
PNPM_VERSION: 8.15.7 # Aligned with root package.json (pnpm/action-setup will helpfully error if out of sync)
|
||||
|
||||
jobs:
|
||||
# We first need to determine the version we are releasing, and if we need a custom repo or ref to use for the git checkout in subsequent steps.
|
||||
@@ -37,7 +37,7 @@ jobs:
|
||||
# ref resolution in actions/checkout. The exact version will be generated within scripts/nx-release.ts.
|
||||
#
|
||||
# - workflow_dispatch:
|
||||
# - We are either running a dry-run on the current branch, in which case the version will be static and we can use
|
||||
# - We are either running a dry-run on the current branch, in which case the version will be statica and we can use
|
||||
# default ref resolution in actions/checkout, or we are creating a PR release for the given PR number, in which case
|
||||
# we should generate an applicable version number within publish-resolve-data.js and use a custom ref of the PR branch name.
|
||||
resolve-required-data:
|
||||
@@ -51,23 +51,31 @@ jobs:
|
||||
publish_branch: ${{ steps.script.outputs.publish_branch }}
|
||||
ref: ${{ steps.script.outputs.ref }}
|
||||
repo: ${{ steps.script.outputs.repo }}
|
||||
pr_number: ${{ steps.script.outputs.pr_number }}
|
||||
pr_author: ${{ steps.script.outputs.pr_author }}
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
steps:
|
||||
# Default checkout on the triggering branch so that the latest publish-resolve-data.js script is available
|
||||
- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
# Set up pnpm and node so that we can verify our setup and that the NPM_TOKEN secret will work later
|
||||
- uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: ${{ env.PNPM_VERSION }}
|
||||
|
||||
- name: Setup node
|
||||
uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: ${{ env.NODE_VERSION }}
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
check-latest: true
|
||||
package-manager-cache: false
|
||||
|
||||
# Ensure that the NPM_TOKEN secret is still valid before wasting any time deriving data or building projects
|
||||
- name: Check NPM Credentials
|
||||
run: npm whoami && echo "NPM credentials are valid" || (echo "NPM credentials are invalid or have expired." && exit 1)
|
||||
|
||||
- name: Resolve and set checkout and version data to use for release
|
||||
id: script
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
|
||||
uses: actions/github-script@v7
|
||||
env:
|
||||
PR_NUMBER: ${{ github.event.inputs.pr }}
|
||||
with:
|
||||
@@ -78,7 +86,7 @@ jobs:
|
||||
|
||||
- name: (PR Release Only) Check out latest master
|
||||
if: ${{ steps.script.outputs.ref != '' }}
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
# Check out the latest master branch to get its copy of nx-release.ts
|
||||
repository: nrwl/nx
|
||||
@@ -87,54 +95,38 @@ jobs:
|
||||
|
||||
- name: (PR Release Only) Check out PR branch
|
||||
if: ${{ steps.script.outputs.ref != '' }}
|
||||
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
# Check out the PR branch to get its copy of nx-release.ts
|
||||
repository: ${{ steps.script.outputs.repo }}
|
||||
ref: ${{ steps.script.outputs.ref }}
|
||||
path: pr-branch-checkout
|
||||
|
||||
- name: (PR Release Only) Ensure that release scripts have not changed in the PR being released
|
||||
- name: (PR Release Only) Ensure that nx-release.ts has not changed in the PR being released
|
||||
if: ${{ steps.script.outputs.ref != '' }}
|
||||
env:
|
||||
FILE_TO_COMPARE: "scripts/nx-release.ts"
|
||||
run: |
|
||||
# List of files that must not change in PR releases
|
||||
FILES_TO_CHECK=(
|
||||
"scripts/nx-release.ts"
|
||||
"scripts/publish-resolve-data.js"
|
||||
)
|
||||
|
||||
for FILE in "${FILES_TO_CHECK[@]}"; do
|
||||
if ! cmp -s "latest-master-checkout/$FILE" "pr-branch-checkout/$FILE"; then
|
||||
echo "🛑 Error: The file $FILE is different on the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} vs latest master on nrwl/nx, cancelling workflow."
|
||||
echo "If you did not modify the file, then you likely just need to rebase/merge latest master."
|
||||
exit 1
|
||||
else
|
||||
echo "✅ The file $FILE is identical between the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} and latest master on nrwl/nx."
|
||||
fi
|
||||
done
|
||||
if ! cmp -s "latest-master-checkout/${{ env.FILE_TO_COMPARE }}" "pr-branch-checkout/${{ env.FILE_TO_COMPARE }}"; then
|
||||
echo "🛑 Error: The file ${{ env.FILE_TO_COMPARE }} is different on the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} vs latest master on nrwl/nx, cancelling workflow. If you did not modify the file, then you likely just need to rebase/merge latest master."
|
||||
exit 1
|
||||
else
|
||||
echo "✅ The file ${{ env.FILE_TO_COMPARE }} is identical between the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} and latest master on nrwl/nx."
|
||||
fi
|
||||
|
||||
build:
|
||||
needs: [ resolve-required-data ]
|
||||
needs: [resolve-required-data]
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
settings:
|
||||
- host: macos-latest
|
||||
- host: macos-13
|
||||
target: x86_64-apple-darwin
|
||||
setup: |-
|
||||
rustup target add x86_64-apple-darwin
|
||||
build: |
|
||||
pnpm nx run-many --target=build-native -- --target=x86_64-apple-darwin
|
||||
- host: windows-latest
|
||||
setup: |-
|
||||
choco install openjdk --version=21.0.0 -y
|
||||
rustup target add aarch64-pc-windows-msvc
|
||||
build: |
|
||||
export JAVA_HOME="C:\Program Files\OpenJDK\jdk-21"
|
||||
export PATH="$JAVA_HOME\bin:$PATH"
|
||||
java -version
|
||||
pnpm nx run-many --target=build-native -- --target=x86_64-pc-windows-msvc
|
||||
build: pnpm nx run-many --target=build-native -- --target=x86_64-pc-windows-msvc
|
||||
target: x86_64-pc-windows-msvc
|
||||
# Windows 32bit (not needed)
|
||||
# - host: windows-latest
|
||||
@@ -144,69 +136,23 @@ jobs:
|
||||
- host: ubuntu-latest
|
||||
target: x86_64-unknown-linux-gnu
|
||||
docker: ghcr.io/napi-rs/napi-rs/nodejs-rust:lts-debian
|
||||
build: |
|
||||
set -e
|
||||
apt-get update
|
||||
|
||||
# Install Java 21
|
||||
apt-get install -y openjdk-21-jdk
|
||||
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
|
||||
export PATH="$JAVA_HOME/bin:$PATH"
|
||||
java --version
|
||||
|
||||
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
|
||||
apt-get install -y nodejs=22.16.0-1nodesource1
|
||||
|
||||
export PATH="/usr/local/bin:$PATH"
|
||||
node --version
|
||||
npm --version
|
||||
|
||||
npm i -g pnpm@${PNPM_VERSION} --force
|
||||
pnpm --version
|
||||
|
||||
pnpm install --frozen-lockfile
|
||||
rustup target add x86_64-unknown-linux-gnu
|
||||
build: |-
|
||||
set -e &&
|
||||
npm i -g pnpm@8.15.7 --force &&
|
||||
pnpm --version &&
|
||||
pnpm install --frozen-lockfile &&
|
||||
pnpm nx run-many --verbose --target=build-native -- --target=x86_64-unknown-linux-gnu
|
||||
- host: ubuntu-latest
|
||||
target: x86_64-unknown-linux-musl
|
||||
docker: ghcr.io/napi-rs/napi-rs/nodejs-rust:lts-alpine
|
||||
build: |
|
||||
bash -c "
|
||||
set -e
|
||||
echo 'https://dl-cdn.alpinelinux.org/alpine/edge/community' >> /etc/apk/repositories
|
||||
apk add --no-cache curl xz openjdk21 build-base lld
|
||||
|
||||
# Set up Java 21
|
||||
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk
|
||||
export PATH=\"\$JAVA_HOME/bin:\$PATH\"
|
||||
java --version
|
||||
|
||||
curl -fsSL https://unofficial-builds.nodejs.org/download/release/v22.16.0/node-v22.16.0-linux-x64-musl.tar.xz -o node.tar.xz
|
||||
tar -xJf node.tar.xz
|
||||
mv node-v22.16.0-linux-x64-musl /usr/local/node
|
||||
|
||||
export PATH=\"/usr/local/node/bin:\$PATH\"
|
||||
|
||||
echo Node: \$(node -v)
|
||||
echo NPM: \$(npm -v)
|
||||
|
||||
# Install PNPM
|
||||
npm i -g pnpm@${PNPM_VERSION} --force
|
||||
pnpm --version
|
||||
|
||||
# Help clang find GCC runtime (crtbeginS.o, libgcc) and use lld for jemalloc build
|
||||
GCC_DIR=\$(dirname \$(find /usr/lib/gcc -name crtbeginS.o | head -1))
|
||||
export CFLAGS=\"\${CFLAGS} -fuse-ld=lld --gcc-install-dir=\${GCC_DIR}\"
|
||||
|
||||
# Install deps and run native build
|
||||
pnpm install --frozen-lockfile
|
||||
rustup target add x86_64-unknown-linux-musl
|
||||
pnpm nx run-many --verbose --target=build-native -- --target=x86_64-unknown-linux-musl
|
||||
"
|
||||
- host: macos-latest
|
||||
build: |-
|
||||
set -e &&
|
||||
npm i -g pnpm@8.15.7 --force &&
|
||||
pnpm --version &&
|
||||
pnpm install --frozen-lockfile &&
|
||||
pnpm nx run-many --verbose --target=build-native -- --target=x86_64-unknown-linux-musl
|
||||
- host: macos-13
|
||||
target: aarch64-apple-darwin
|
||||
setup: |-
|
||||
rustup target add aarch64-apple-darwin
|
||||
build: |
|
||||
sudo rm -Rf /Library/Developer/CommandLineTools/SDKs/*;
|
||||
export CC=$(xcrun -f clang);
|
||||
@@ -217,40 +163,19 @@ jobs:
|
||||
- host: ubuntu-latest
|
||||
target: aarch64-unknown-linux-gnu
|
||||
docker: ghcr.io/napi-rs/napi-rs/nodejs-rust:lts-debian-aarch64
|
||||
build: |
|
||||
set -e
|
||||
apt-get update
|
||||
|
||||
# Install Java 21
|
||||
apt-get install -y openjdk-21-jdk
|
||||
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
|
||||
export PATH="$JAVA_HOME/bin:$PATH"
|
||||
java --version
|
||||
|
||||
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
|
||||
apt-get install -y nodejs=22.16.0-1nodesource1
|
||||
|
||||
export PATH="/usr/local/bin:$PATH"
|
||||
node --version
|
||||
npm --version
|
||||
|
||||
# Help clang find GCC runtime (crtbeginS.o, libgcc) and use lld for jemalloc build
|
||||
export CFLAGS="${CFLAGS} -fuse-ld=lld --gcc-toolchain=/usr/aarch64-unknown-linux-gnu"
|
||||
|
||||
npm i -g pnpm@${PNPM_VERSION} --force
|
||||
pnpm --version
|
||||
|
||||
pnpm install --frozen-lockfile
|
||||
rustup target add aarch64-unknown-linux-gnu
|
||||
build: |-
|
||||
set -e &&
|
||||
npm i -g pnpm@8.15.7 --force &&
|
||||
pnpm --version &&
|
||||
pnpm install --frozen-lockfile &&
|
||||
pnpm nx run-many --verbose --target=build-native -- --target=aarch64-unknown-linux-gnu
|
||||
- host: ubuntu-latest
|
||||
target: armv7-unknown-linux-gnueabihf
|
||||
setup: |
|
||||
sudo apt-get update
|
||||
sudo apt-get install gcc-arm-linux-gnueabihf -y
|
||||
rustup target add armv7-unknown-linux-gnueabihf
|
||||
build: |
|
||||
CARGO_TARGET_ARMV7_UNKNOWN_LINUX_GNUEABIHF_LINKER=/usr/bin/arm-linux-gnueabihf-gcc pnpm nx run-many --target=build-native -- --target=armv7-unknown-linux-gnueabihf
|
||||
pnpm nx run-many --target=build-native -- --target=armv7-unknown-linux-gnueabihf
|
||||
# Android (not needed)
|
||||
# - host: ubuntu-latest
|
||||
# target: aarch64-linux-android
|
||||
@@ -263,69 +188,44 @@ jobs:
|
||||
- host: ubuntu-latest
|
||||
target: aarch64-unknown-linux-musl
|
||||
docker: ghcr.io/napi-rs/napi-rs/nodejs-rust:lts-alpine
|
||||
build: |
|
||||
bash -c "
|
||||
set -e
|
||||
echo 'https://dl-cdn.alpinelinux.org/alpine/edge/community' >> /etc/apk/repositories
|
||||
apk add --no-cache curl xz openjdk21 build-base lld
|
||||
|
||||
# Set up Java 21
|
||||
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk
|
||||
export PATH=\"\$JAVA_HOME/bin:\$PATH\"
|
||||
java --version
|
||||
|
||||
curl -fsSL https://unofficial-builds.nodejs.org/download/release/v22.16.0/node-v22.16.0-linux-x64-musl.tar.xz -o node.tar.xz
|
||||
tar -xJf node.tar.xz
|
||||
mv node-v22.16.0-linux-x64-musl /usr/local/node
|
||||
|
||||
export PATH=\"/usr/local/node/bin:\$PATH\"
|
||||
|
||||
echo Node: \$(node -v)
|
||||
echo NPM: \$(npm -v)
|
||||
|
||||
# Install PNPM
|
||||
npm i -g pnpm@${PNPM_VERSION} --force
|
||||
pnpm --version
|
||||
|
||||
# Help clang find GCC runtime (crtbeginS.o, libgcc) and use lld for jemalloc build
|
||||
GCC_DIR=\$(dirname \$(find /aarch64-linux-musl-cross/lib/gcc -name crtbeginS.o | head -1))
|
||||
export CFLAGS=\"\${CFLAGS} -fuse-ld=lld --gcc-install-dir=\${GCC_DIR}\"
|
||||
|
||||
# Install deps and run native build
|
||||
pnpm install --frozen-lockfile
|
||||
rustup target add aarch64-unknown-linux-musl
|
||||
pnpm nx run-many --verbose --target=build-native -- --target=aarch64-unknown-linux-musl
|
||||
"
|
||||
build: |-
|
||||
set -e &&
|
||||
rustup target add aarch64-unknown-linux-musl &&
|
||||
npm i -g pnpm@8.15.7 --force &&
|
||||
pnpm --version &&
|
||||
pnpm install --frozen-lockfile &&
|
||||
pnpm nx run-many --verbose --target=build-native -- --target=aarch64-unknown-linux-musl
|
||||
- host: windows-latest
|
||||
target: aarch64-pc-windows-msvc
|
||||
setup: |-
|
||||
choco install openjdk --version=21.0.0 -y
|
||||
rustup target add aarch64-pc-windows-msvc
|
||||
build: |
|
||||
export JAVA_HOME="C:\Program Files\OpenJDK\jdk-21"
|
||||
export PATH="$JAVA_HOME\bin:$PATH"
|
||||
java -version
|
||||
pnpm nx run-many --target=build-native -- --target=aarch64-pc-windows-msvc
|
||||
name: stable - ${{ matrix.settings.target }} - node@22.16.0
|
||||
build: pnpm nx run-many --target=build-native -- --target=aarch64-pc-windows-msvc
|
||||
name: stable - ${{ matrix.settings.target }} - node@18
|
||||
runs-on: ${{ matrix.settings.host }}
|
||||
steps:
|
||||
- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
repository: ${{ needs.resolve-required-data.outputs.repo || github.repository }}
|
||||
ref: ${{ needs.resolve-required-data.outputs.ref || github.ref }}
|
||||
repository: ${{ needs.resolve-required-data.outputs.repo }}
|
||||
ref: ${{ needs.resolve-required-data.outputs.ref }}
|
||||
|
||||
- name: Setup dev tools with mise
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
if: ${{ !matrix.settings.docker }}
|
||||
- uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: ${{ env.PNPM_VERSION }}
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
- name: Setup node
|
||||
uses: actions/setup-node@v4
|
||||
if: ${{ !matrix.settings.docker }}
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
with:
|
||||
node-version: ${{ env.NODE_VERSION }}
|
||||
check-latest: true
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Install
|
||||
uses: dtolnay/rust-toolchain@stable
|
||||
if: ${{ !matrix.settings.docker }}
|
||||
with:
|
||||
targets: ${{ matrix.settings.target }}
|
||||
|
||||
- name: Cache cargo
|
||||
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4.2.4
|
||||
uses: actions/cache@v4
|
||||
with:
|
||||
path: |
|
||||
~/.cargo/registry/index/
|
||||
@@ -335,7 +235,7 @@ jobs:
|
||||
target/
|
||||
key: ${{ matrix.settings.target }}-cargo-registry
|
||||
|
||||
- uses: goto-bus-stop/setup-zig@abea47f85e598557f500fa1fd2ab7464fcb39406 # v2.2.1
|
||||
- uses: goto-bus-stop/setup-zig@v2
|
||||
if: ${{ matrix.settings.target == 'armv7-unknown-linux-gnueabihf' }}
|
||||
with:
|
||||
version: 0.10.0
|
||||
@@ -356,7 +256,7 @@ jobs:
|
||||
timeout-minutes: 30
|
||||
|
||||
- name: Setup node x86
|
||||
uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
|
||||
uses: actions/setup-node@v4
|
||||
if: matrix.settings.target == 'i686-pc-windows-msvc'
|
||||
with:
|
||||
node-version: ${{ env.NODE_VERSION }}
|
||||
@@ -365,24 +265,12 @@ jobs:
|
||||
architecture: x86
|
||||
|
||||
- name: Build in docker
|
||||
uses: addnab/docker-run-action@v3
|
||||
if: ${{ matrix.settings.docker }}
|
||||
shell: bash
|
||||
env:
|
||||
BUILD_SCRIPT: ${{ matrix.settings.build }}
|
||||
run: |
|
||||
SCRIPT_FILE=$(mktemp)
|
||||
echo "$BUILD_SCRIPT" > "$SCRIPT_FILE"
|
||||
docker run --rm \
|
||||
--user 0:0 \
|
||||
-e PNPM_VERSION \
|
||||
-v ${{ github.workspace }}/.cargo-cache/git/db:/usr/local/cargo/git/db \
|
||||
-v ${{ github.workspace }}/.cargo/registry/cache:/usr/local/cargo/registry/cache \
|
||||
-v ${{ github.workspace }}/.cargo/registry/index:/usr/local/cargo/registry/index \
|
||||
-v ${{ github.workspace }}:/build \
|
||||
-v "$SCRIPT_FILE:/build-script.sh" \
|
||||
-w /build \
|
||||
${{ matrix.settings.docker }} \
|
||||
bash /build-script.sh
|
||||
with:
|
||||
image: ${{ matrix.settings.docker }}
|
||||
options: --user 0:0 -v ${{ github.workspace }}/.cargo-cache/git/db:/usr/local/cargo/git/db -v ${{ github.workspace }}/.cargo/registry/cache:/usr/local/cargo/registry/cache -v ${{ github.workspace }}/.cargo/registry/index:/usr/local/cargo/registry/index -v ${{ github.workspace }}:/build -w /build
|
||||
run: ${{ matrix.settings.build }}
|
||||
|
||||
- name: Build
|
||||
run: ${{ matrix.settings.build }}
|
||||
@@ -390,50 +278,45 @@ jobs:
|
||||
shell: bash
|
||||
|
||||
- name: Upload artifact
|
||||
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: bindings-${{ matrix.settings.target }}
|
||||
path: |
|
||||
packages/nx/src/native/*.node
|
||||
packages/nx/src/native/*.wasm
|
||||
path: packages/**/*.node
|
||||
if-no-files-found: error
|
||||
|
||||
build-freebsd:
|
||||
needs: [ resolve-required-data ]
|
||||
needs: [resolve-required-data]
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
runs-on: ubuntu-latest
|
||||
runs-on: macos-13-large
|
||||
name: Build FreeBSD
|
||||
timeout-minutes: 45
|
||||
steps:
|
||||
- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
- uses: actions/checkout@v4
|
||||
if: ${{ github.event_name != 'schedule' && !github.event.inputs.pr }}
|
||||
with:
|
||||
repository: ${{ needs.resolve-required-data.outputs.repo || github.repository }}
|
||||
ref: ${{ needs.resolve-required-data.outputs.ref || github.ref }}
|
||||
repository: ${{ needs.resolve-required-data.outputs.repo }}
|
||||
ref: ${{ needs.resolve-required-data.outputs.ref }}
|
||||
|
||||
- name: Build
|
||||
id: build
|
||||
uses: cross-platform-actions/action@462ed697694d2ac9aa49e1225f395f7bb6dd49fe # v0.29.0
|
||||
if: ${{ github.event_name != 'schedule' && !github.event.inputs.pr }}
|
||||
uses: cross-platform-actions/action@v0.22.0
|
||||
env:
|
||||
DEBUG: napi:*
|
||||
RUSTUP_IO_THREADS: 1
|
||||
NX_PREFER_TS_NODE: true
|
||||
PLAYWRIGHT_BROWSERS_PATH: 0
|
||||
NODE_VERSION: 22.16.0
|
||||
with:
|
||||
operating_system: freebsd
|
||||
version: '14.0'
|
||||
version: '13.2'
|
||||
architecture: x86-64
|
||||
environment_variables: DEBUG RUSTUP_IO_THREADS CI NX_PREFER_TS_NODE PLAYWRIGHT_BROWSERS_PATH NODE_VERSION
|
||||
environment_variables: DEBUG RUSTUP_IO_THREADS CI NX_PREFER_TS_NODE PLAYWRIGHT_BROWSERS_PATH
|
||||
shell: bash
|
||||
run: |
|
||||
env
|
||||
whoami
|
||||
sudo pkg install -y -f node libnghttp2 www/npm git openjdk17
|
||||
sudo npm install --location=global --ignore-scripts pnpm@10.28.2
|
||||
# Set up Java 17
|
||||
export JAVA_HOME=/usr/local/openjdk17
|
||||
export PATH="$JAVA_HOME/bin:$PATH"
|
||||
java --version
|
||||
sudo pkg install -y -f node libnghttp2 npm git
|
||||
sudo npm install --location=global --ignore-scripts pnpm@8.15.7
|
||||
curl https://sh.rustup.rs -sSf --output rustup.sh
|
||||
sh rustup.sh -y --profile minimal --default-toolchain stable
|
||||
source "$HOME/.cargo/env"
|
||||
@@ -448,75 +331,10 @@ jobs:
|
||||
whoami
|
||||
env
|
||||
freebsd-version
|
||||
echo "Installing dependencies"
|
||||
mkdir -p /Users/runner/work/_temp/_github_workflow
|
||||
echo "{}" > /Users/runner/work/_temp/_github_workflow/event.json
|
||||
pnpm install --frozen-lockfile --ignore-scripts
|
||||
|
||||
echo "Checking disk space before cleanup"
|
||||
df -h
|
||||
echo "Removing unnecessary preinstalled packages"
|
||||
# List all packages first to see what's installed
|
||||
sudo pkg info -a
|
||||
echo "Cleaning up to free disk space"
|
||||
# Clean package caches
|
||||
sudo pkg clean -a -y
|
||||
sudo pkg autoremove -y
|
||||
# Remove unnecessary system files
|
||||
sudo rm -rf /usr/local/lib/*.a
|
||||
sudo rm -rf /usr/local/share/doc/*
|
||||
sudo rm -rf /usr/local/share/man/*
|
||||
sudo rm -rf /usr/local/share/examples/*
|
||||
sudo rm -rf /usr/local/share/locale/*
|
||||
sudo rm -rf /usr/local/share/gtk-doc/*
|
||||
sudo rm -rf /usr/local/share/info/*
|
||||
sudo rm -rf /usr/src/*
|
||||
sudo rm -rf /usr/obj/*
|
||||
sudo rm -rf /usr/tests/*
|
||||
sudo rm -rf /usr/lib/debug/*
|
||||
# Clean var directories
|
||||
sudo rm -rf /var/cache/pkg/*
|
||||
sudo rm -rf /var/db/pkg/*.tbz
|
||||
sudo rm -rf /var/log/*.log
|
||||
sudo rm -rf /var/log/*.old
|
||||
# Clean temporary files
|
||||
sudo rm -rf /tmp/*
|
||||
sudo rm -rf /var/tmp/*
|
||||
# Remove Python cache if present
|
||||
sudo find /usr/local -type d -name "__pycache__" -exec rm -rf {} + 2>/dev/null || true
|
||||
sudo find /usr/local -name "*.pyc" -delete 2>/dev/null || true
|
||||
sudo find /usr/local -name "*.pyo" -delete 2>/dev/null || true
|
||||
# Clean npm/pnpm caches
|
||||
npm cache clean --force || true
|
||||
pnpm store prune || true
|
||||
rm -rf ~/.npm || true
|
||||
rm -rf ~/.pnpm-store || true
|
||||
# Remove Rust build artifacts if any
|
||||
rm -rf ~/.cargo/registry || true
|
||||
rm -rf ~/.cargo/git || true
|
||||
rm -rf ~/.rustup/toolchains/*/share || true
|
||||
# Remove other development tool caches
|
||||
rm -rf ~/.cache/* || true
|
||||
|
||||
# Remove unnecessary workspace directories
|
||||
rm -rf docs astro-docs nx-dev || true
|
||||
|
||||
echo "Checking disk space after cleanup"
|
||||
df -h
|
||||
|
||||
echo "Building FreeBSD bindings"
|
||||
BUILD_EXIT=0
|
||||
pnpm nx run-many --verbose --outputStyle stream --target=build-native -- --target=x86_64-unknown-freebsd || BUILD_EXIT=$?
|
||||
|
||||
echo "=== Disk usage after build ==="
|
||||
df -h
|
||||
|
||||
if [ "$BUILD_EXIT" -ne 0 ]; then
|
||||
echo "Build failed with exit code $BUILD_EXIT"
|
||||
exit $BUILD_EXIT
|
||||
fi
|
||||
|
||||
echo "Build succeeded"
|
||||
|
||||
echo "Cleaning up"
|
||||
pnpm nx run-many --verbose --outputStyle stream --target=build-native -- --target=x86_64-unknown-freebsd
|
||||
pnpm nx reset
|
||||
rm -rf node_modules
|
||||
rm -rf dist
|
||||
@@ -525,18 +343,17 @@ jobs:
|
||||
echo "COMPLETE"
|
||||
|
||||
- name: Upload artifact
|
||||
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
|
||||
if: ${{ github.event_name != 'schedule' && !github.event.inputs.pr }}
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: bindings-freebsd
|
||||
path: |
|
||||
packages/nx/src/native/*.node
|
||||
path: packages/**/*.node
|
||||
if-no-files-found: error
|
||||
|
||||
publish:
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
name: Publish
|
||||
runs-on: ubuntu-latest
|
||||
environment: npm-registry
|
||||
permissions:
|
||||
id-token: write
|
||||
contents: write
|
||||
@@ -547,28 +364,31 @@ jobs:
|
||||
- build
|
||||
env:
|
||||
GH_TOKEN: ${{ github.token }}
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
NPM_CONFIG_PROVENANCE: true
|
||||
steps:
|
||||
- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
repository: ${{ needs.resolve-required-data.outputs.repo || github.repository }}
|
||||
ref: ${{ needs.resolve-required-data.outputs.ref || github.ref }}
|
||||
repository: ${{ needs.resolve-required-data.outputs.repo }}
|
||||
ref: ${{ needs.resolve-required-data.outputs.ref }}
|
||||
|
||||
- name: Setup dev tools with mise
|
||||
uses: jdx/mise-action@146a28175021df8ca24f8ee1828cc2a60f980bd5 # v3
|
||||
- uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: ${{ env.PNPM_VERSION }}
|
||||
|
||||
- name: Enable corepack and install pnpm
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare --activate
|
||||
|
||||
- name: Use npm 11.5.2
|
||||
run: npm install -g npm@11.5.2
|
||||
- name: Setup node
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: ${{ env.NODE_VERSION }}
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
check-latest: true
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Install dependencies
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Download all artifacts
|
||||
uses: actions/download-artifact@634f93cb2916e3fdff6788551b99b062d0335ce0 # v5.0.0
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
path: artifacts
|
||||
|
||||
@@ -576,18 +396,12 @@ jobs:
|
||||
- name: List artifacts
|
||||
run: ls -R artifacts
|
||||
shell: bash
|
||||
- name: Build Wasm
|
||||
run: |
|
||||
wget https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-23/wasi-sdk-23.0-x86_64-linux.tar.gz
|
||||
tar -xvf wasi-sdk-23.0-x86_64-linux.tar.gz
|
||||
rustup toolchain install nightly-2025-05-09
|
||||
pnpm build:wasm
|
||||
|
||||
- name: Publish
|
||||
env:
|
||||
VERSION: ${{ needs.resolve-required-data.outputs.version }}
|
||||
DRY_RUN: ${{ needs.resolve-required-data.outputs.dry_run_flag }}
|
||||
PUBLISH_BRANCH: ${{ needs.resolve-required-data.outputs.publish_branch }}
|
||||
NX_VERBOSE_LOGGING: true
|
||||
run: |
|
||||
echo ""
|
||||
# Create and check out the publish branch
|
||||
@@ -601,15 +415,15 @@ jobs:
|
||||
- name: (Stable Release Only) Trigger Docs Release
|
||||
# Publish docs only on a full release
|
||||
if: ${{ !github.event.release.prerelease && github.event_name == 'release' }}
|
||||
run: npx ts-node -P ./scripts/tsconfig.scripts.json ./scripts/release-docs.ts
|
||||
run: npx ts-node ./scripts/release-docs.ts
|
||||
|
||||
- name: (PR Release Only) Create comment for successful PR release
|
||||
if: success() && github.event.inputs.pr
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
|
||||
uses: actions/github-script@v7
|
||||
env:
|
||||
SUCCESS_COMMENT: ${{ needs.resolve-required-data.outputs.success_comment }}
|
||||
with:
|
||||
# github-token defaults to ${{ github.token }} so we don't need to specify it
|
||||
github-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
script: |
|
||||
const successComment = JSON.parse(process.env.SUCCESS_COMMENT);
|
||||
await github.rest.issues.createComment({
|
||||
@@ -619,55 +433,22 @@ jobs:
|
||||
body: successComment
|
||||
});
|
||||
|
||||
report-pending-publish:
|
||||
name: Report Pending Publish to Slack
|
||||
if: ${{ github.repository_owner == 'nrwl' }}
|
||||
needs:
|
||||
- resolve-required-data
|
||||
- build-freebsd
|
||||
- build
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 10
|
||||
continue-on-error: true # Don't fail the workflow if notification fails
|
||||
steps:
|
||||
- name: Send Slack notification
|
||||
uses: ravsamhq/notify-slack-action@be814b201e233b2dc673608aa46e5447c8ab13f2 # v11
|
||||
with:
|
||||
status: ${{ job.status }}
|
||||
notification_title: >-
|
||||
${{ needs.resolve-required-data.outputs.pr_number &&
|
||||
format('📦 PR #{0} Publish Pending Review', needs.resolve-required-data.outputs.pr_number) ||
|
||||
'📦 Publish Pending Review' }}
|
||||
message_format: >-
|
||||
${{ needs.resolve-required-data.outputs.pr_number &&
|
||||
format('Version {0} from PR #{1} by @{2} is being published to NPM - manual review is required',
|
||||
needs.resolve-required-data.outputs.version,
|
||||
needs.resolve-required-data.outputs.pr_number,
|
||||
needs.resolve-required-data.outputs.pr_author) ||
|
||||
format('Version {0} is being published to NPM - manual review is required',
|
||||
needs.resolve-required-data.outputs.version) }}
|
||||
footer: '<{run_url}|View Workflow Run>'
|
||||
mention_users: 'U9NPA6C90' # Jason
|
||||
env:
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
|
||||
|
||||
pr_failure_comment:
|
||||
# Run this job if it is a PR release, running on the nrwl origin, and any of the required jobs failed
|
||||
if: ${{ github.repository_owner == 'nrwl' && github.event.inputs.pr && always() && contains(needs.*.result, 'failure') }}
|
||||
needs: [ resolve-required-data, build, build-freebsd, publish ]
|
||||
needs: [resolve-required-data, build, build-freebsd, publish]
|
||||
name: (PR Release Failure Only) Create comment for failed PR release
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
pull-requests: write
|
||||
steps:
|
||||
- name: Create comment for failed PR release
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
|
||||
uses: actions/github-script@v7
|
||||
with:
|
||||
github-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
# This script is intentionally kept inline (and e.g. not generated in publish-resolve-data.js)
|
||||
# to ensure that an error within the data generation itself is not missed.
|
||||
script: |
|
||||
const message = `
|
||||
Failed to publish a PR release of this pull request, triggered by @${{ github.triggering_actor }}.
|
||||
Failed to publish a PR release of this pull request, triggered by @${{ github.triggering_actor }}.
|
||||
See the failed workflow run at: https://github.com/nrwl/nx/actions/runs/${{ github.run_id }}
|
||||
`;
|
||||
await github.rest.issues.createComment({
|
||||
@@ -676,4 +457,3 @@ jobs:
|
||||
issue_number: ${{ github.event.inputs.pr }},
|
||||
body: message
|
||||
});
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ jobs:
|
||||
# This handles issues that need more info
|
||||
- name: stale-more-info-needed
|
||||
id: stale-more-info-needed
|
||||
uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0
|
||||
uses: actions/stale@v9.0.0
|
||||
with:
|
||||
repo-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
days-before-stale: 7
|
||||
@@ -37,7 +37,7 @@ jobs:
|
||||
# This handles PRs that need to be rebased
|
||||
- name: stale-needs-rebase
|
||||
id: stale-needs-rebase
|
||||
uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0
|
||||
uses: actions/stale@v9.0.0
|
||||
with:
|
||||
repo-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
days-before-stale: 7
|
||||
@@ -56,7 +56,7 @@ jobs:
|
||||
# This handles issues that do not have a repro
|
||||
- name: stale-repro-needed
|
||||
id: stale-repro-needed
|
||||
uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0
|
||||
uses: actions/stale@v9.0.0
|
||||
with:
|
||||
repo-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
days-before-stale: 7
|
||||
@@ -75,7 +75,7 @@ jobs:
|
||||
|
||||
- name: stale-retry-with-latest
|
||||
id: stale-retry-with-latest
|
||||
uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0
|
||||
uses: actions/stale@v9.0.0
|
||||
with:
|
||||
repo-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
days-before-stale: 7
|
||||
@@ -95,7 +95,7 @@ jobs:
|
||||
# This handles issues are really old and were made with a previous major
|
||||
- name: stale-bug
|
||||
id: stale-bug
|
||||
uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0
|
||||
uses: actions/stale@v9.0.0
|
||||
with:
|
||||
repo-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
days-before-stale: 180
|
||||
|
||||
+4
-102
@@ -3,7 +3,6 @@ node_modules
|
||||
/.fleet
|
||||
/.vscode
|
||||
dist
|
||||
out-tsc
|
||||
/build
|
||||
/coverage
|
||||
./test
|
||||
@@ -13,8 +12,7 @@ tmp
|
||||
jest.debug.config.js
|
||||
.tool-versions
|
||||
/.nx-cache
|
||||
/.nx/cache
|
||||
/.nx/workspace-data
|
||||
/.nx
|
||||
/.verdaccio/build/local-registry
|
||||
/graph/client/src/assets/environment.js
|
||||
/graph/client/src/assets/dev/environment.js
|
||||
@@ -23,16 +21,7 @@ jest.debug.config.js
|
||||
/graph/client/src/assets/generated-task-inputs
|
||||
/graph/client/src/assets/generated-source-maps
|
||||
/nx-dev/nx-dev/public/documentation
|
||||
/nx-dev/nx-dev/public/tutorials
|
||||
/nx-dev/nx-dev/public/images/open-graph
|
||||
/nx-dev/nx-dev/public/robots.txt
|
||||
/nx-dev/nx-dev/public/sitemap-0.xml
|
||||
/nx-dev/nx-dev/public/sitemap.xml
|
||||
|
||||
# Banner JSON files are generated during static builds
|
||||
/nx-dev/nx-dev/lib/banner.json
|
||||
/astro-docs/src/content/banner.json
|
||||
**/tests/temp-db*
|
||||
|
||||
# Issues scraper creates these files, stored by github's cache
|
||||
/scripts/issues-scraper/cached
|
||||
@@ -44,21 +33,20 @@ CHANGELOG.md
|
||||
.next
|
||||
out
|
||||
|
||||
|
||||
# Angular Cache
|
||||
.angular
|
||||
|
||||
# Astro Cache
|
||||
.astro
|
||||
|
||||
# Local dev files
|
||||
.env.local
|
||||
.bashrc
|
||||
.nx
|
||||
|
||||
*.node
|
||||
|
||||
# Fix for issue when working on the repo in a dev container
|
||||
.pnpm-store
|
||||
.nx/cache
|
||||
.nx/workspace-data
|
||||
|
||||
.cargo/.package-cache
|
||||
.cargo/bin/
|
||||
@@ -68,89 +56,3 @@ out
|
||||
.npm/
|
||||
.profile
|
||||
.rustup/
|
||||
target
|
||||
.flattened-pom.xml
|
||||
dependency-reduced-pom.xml
|
||||
*.wasm
|
||||
/wasi-sdk*
|
||||
|
||||
*.config.timestamp*
|
||||
|
||||
storybook-static
|
||||
|
||||
# Ignore Gradle project-specific cache directory
|
||||
.gradle
|
||||
.kotlin
|
||||
|
||||
.claude/settings.local.json
|
||||
CLAUDE.local.md
|
||||
|
||||
.cursor/mcp.json
|
||||
|
||||
# Added by Claude Task Master
|
||||
# Logs
|
||||
logs
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
dev-debug.log
|
||||
# Dependency directories
|
||||
node_modules/
|
||||
# Environment variables
|
||||
.env
|
||||
!e2e/dotnet/.env
|
||||
# Editor directories and files
|
||||
.idea
|
||||
.vscode
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
.specstory/**
|
||||
.cursorindexingignore
|
||||
# OS specific
|
||||
# Task files
|
||||
/tasks.json
|
||||
/tasks
|
||||
|
||||
# Upstream docs local configuration (machine-specific)
|
||||
.upstreamdocs.local.json
|
||||
|
||||
# Netlify build artifacts
|
||||
.netlify
|
||||
|
||||
coverage
|
||||
|
||||
# Angular Rspack Specific Options
|
||||
packages/angular-rspack/coverage
|
||||
packages/angular-rspack-compiler/coverage
|
||||
|
||||
# Some Packages use a template to generate the correct README
|
||||
packages/angular-rspack/README.md
|
||||
packages/angular-rspack-compiler/README.md
|
||||
packages/dotnet/README.md
|
||||
packages/maven/README.md
|
||||
packages/nx/README.md
|
||||
|
||||
test-output
|
||||
test-results
|
||||
|
||||
# TypeScript build info files
|
||||
*.tsbuildinfo
|
||||
|
||||
# .NET build output
|
||||
/packages/dotnet/analyzer/bin
|
||||
/packages/dotnet/analyzer/obj
|
||||
/*.deb
|
||||
.nx/polygraph
|
||||
.claude/worktrees
|
||||
|
||||
.nx/self-healing
|
||||
# Nx Typings Output
|
||||
packages/nx/**/*.d.ts
|
||||
!packages/nx/src/utils/perf-hooks.d.ts
|
||||
!packages/nx/src/ai/set-up-ai-agents/schema.d.ts
|
||||
!packages/nx/src/native/index.d.ts
|
||||
e2e/**/*.d.ts
|
||||
e2e/**/*.d.ts.map
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
node ./scripts/commit-lint.js "$1"
|
||||
+1
-10
@@ -1,12 +1,3 @@
|
||||
# Skip if this is a worktree creation (previous ref is null)
|
||||
if [ "$1" = "0000000000000000000000000000000000000000" ]; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Skip if this is a file checkout (not branch switch) - $3 would be 0
|
||||
if [ "$3" = "0" ]; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
#!/bin/sh
|
||||
changedFiles="$(git diff-tree -r --name-only --no-commit-id $1 $2)"
|
||||
node ./scripts/notify-lockfile-changes.js $changedFiles
|
||||
+2
-1
@@ -1,2 +1,3 @@
|
||||
#!/bin/sh
|
||||
changedFiles="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
|
||||
node ./scripts/notify-lockfile-changes.js $changedFiles
|
||||
node ./scripts/notify-lockfile-changes.js $changedFiles
|
||||
+6
-1
@@ -1 +1,6 @@
|
||||
pnpm nx prepush --parallel 8 --tuiAutoExit 0
|
||||
#!/usr/bin/env sh
|
||||
|
||||
pnpm check-lock-files &&
|
||||
pnpm check-commit &&
|
||||
pnpm documentation &&
|
||||
pnpm pretty-quick --check
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
NX_USE_V8_SERIALIZER=false
|
||||
-3
@@ -1,3 +0,0 @@
|
||||
wrapperVersion=3.3.4
|
||||
distributionType=only-script
|
||||
distributionUrl=https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-rc-5/apache-maven-4.0.0-rc-5-bin.zip
|
||||
@@ -1,3 +0,0 @@
|
||||
{
|
||||
"experimentalPolygraph": true
|
||||
}
|
||||
+55
-74
@@ -1,76 +1,57 @@
|
||||
common-env-vars: &common-env-vars
|
||||
GIT_AUTHOR_EMAIL: test@test.com
|
||||
GIT_AUTHOR_NAME: Test
|
||||
GIT_COMMITTER_EMAIL: test@test.com
|
||||
GIT_COMMITTER_NAME: Test
|
||||
SELECTED_PM: 'pnpm'
|
||||
NX_NATIVE_LOGGING: 'nx::native::db'
|
||||
# These are need for build and link validation for next.js and astro apps
|
||||
NEXT_PUBLIC_ASTRO_URL: 'https://master--nx-docs.netlify.app'
|
||||
NX_DEV_URL: 'https://canary.nx.dev'
|
||||
|
||||
common-init-steps: &common-init-steps
|
||||
- name: Checkout
|
||||
uses: 'nrwl/nx-cloud-workflows/v5/workflow-steps/checkout/main.yaml'
|
||||
|
||||
- name: Cache restore
|
||||
uses: 'nrwl/nx-cloud-workflows/v5/workflow-steps/cache/main.yaml'
|
||||
inputs:
|
||||
key: 'pnpm-lock.yaml'
|
||||
paths: ~/.local/share/pnpm/store
|
||||
base-branch: 'master'
|
||||
|
||||
# reads mise.toml and installs toolchains needed for repo
|
||||
- name: Setup toolchains
|
||||
uses: 'nrwl/nx-cloud-workflows/v5/workflow-steps/install-mise/main.yaml'
|
||||
|
||||
- name: Verify toolchain versions
|
||||
script: |
|
||||
echo "mise: $(mise --version)"
|
||||
echo "node: $(node --version)"
|
||||
echo "pnpm: $(pnpm --version)"
|
||||
echo "bun: $(bun --version)"
|
||||
echo "rust: $(rustc --version) - $(cargo --version)"
|
||||
echo "dotnet: $(dotnet --version)"
|
||||
echo "java: $(javac --version)"
|
||||
|
||||
- name: Install system deps
|
||||
script: |
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y ca-certificates lsof libvips-dev libglib2.0-dev libgirepository1.0-dev zip unzip
|
||||
|
||||
- name: Pnpm Install from lockfile
|
||||
script: |
|
||||
pnpm install --frozen-lockfile
|
||||
|
||||
- name: Install browsers
|
||||
script: |
|
||||
pnpm exec cypress install
|
||||
pnpm exec playwright install --with-deps
|
||||
|
||||
- name: Install rust deps
|
||||
script: |
|
||||
cargo fetch
|
||||
|
||||
- name: Setup gradle
|
||||
script: |
|
||||
./gradlew wrapper
|
||||
./gradlew --version
|
||||
|
||||
- name: Configure git metadata (needed for lerna smoke tests)
|
||||
script: |
|
||||
git config --global user.email test@test.com
|
||||
git config --global user.name "Test Test"
|
||||
|
||||
launch-templates:
|
||||
linux-large:
|
||||
resource-class: 'docker_linux_amd64/large'
|
||||
image: 'us-east1-docker.pkg.dev/nxcloudoperations/nx-cloud/nx-agents-base-images:ubuntu22.04-node20.19-v1'
|
||||
env: *common-env-vars
|
||||
init-steps: *common-init-steps
|
||||
linux-medium:
|
||||
resource-class: 'docker_linux_amd64/medium+'
|
||||
image: 'ubuntu22.04-node20.11-v3'
|
||||
env:
|
||||
GIT_AUTHOR_EMAIL: test@test.com
|
||||
GIT_AUTHOR_NAME: Test
|
||||
GIT_COMMITTER_EMAIL: test@test.com
|
||||
GIT_COMMITTER_NAME: Test
|
||||
SELECTED_PM: 'pnpm'
|
||||
NPM_CONFIG_PREFIX: '/home/workflows/.npm-global'
|
||||
init-steps:
|
||||
- name: Checkout
|
||||
uses: 'nrwl/nx-cloud-workflows/v3.6/workflow-steps/checkout/main.yaml'
|
||||
- name: Cache restore
|
||||
uses: 'nrwl/nx-cloud-workflows/v3.6/workflow-steps/cache/main.yaml'
|
||||
env:
|
||||
KEY: 'pnpm-lock.yaml'
|
||||
PATHS: |
|
||||
node_modules
|
||||
~/.cache/Cypress
|
||||
~/.cache/ms-playwright
|
||||
~/.pnpm-store
|
||||
BASE_BRANCH: 'master'
|
||||
- name: Install e2e deps
|
||||
script: |
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y ca-certificates lsof libvips-dev libglib2.0-dev libgirepository1.0-dev
|
||||
- name: Install Pnpm
|
||||
script: |
|
||||
npm install -g pnpm@8
|
||||
|
||||
linux-extra-large:
|
||||
resource-class: 'docker_linux_amd64/extra_large'
|
||||
image: 'us-east1-docker.pkg.dev/nxcloudoperations/nx-cloud/nx-agents-base-images:ubuntu22.04-node20.19-v1'
|
||||
env: *common-env-vars
|
||||
init-steps: *common-init-steps
|
||||
- name: Pnpm Install
|
||||
script: |
|
||||
pnpm install --frozen-lockfile
|
||||
|
||||
- name: Install Browsers
|
||||
script: |
|
||||
pnpm exec cypress install
|
||||
pnpm exec playwright install
|
||||
|
||||
- name: Install Rust
|
||||
script: |
|
||||
curl --proto '=https' --tlsv1.3 https://sh.rustup.rs -sSf | sh -s -- -y
|
||||
source "$HOME/.cargo/env"
|
||||
rustup toolchain install 1.70.0
|
||||
|
||||
- name: Configure git metadata (needed for lerna smoke tests)
|
||||
script: |
|
||||
git config --global user.email test@test.com
|
||||
git config --global user.name "Test Test"
|
||||
|
||||
- name: Load Cargo Env
|
||||
script: echo "PATH=$HOME/.cargo/bin:$PATH" >> $NX_CLOUD_ENV
|
||||
|
||||
- name: Install zip and unzip
|
||||
script: sudo apt-get -yqq install zip unzip
|
||||
|
||||
@@ -1,118 +1,4 @@
|
||||
distribute-on:
|
||||
extra-small-changeset: 6 linux-large, 3 linux-extra-large
|
||||
small-changeset: 6 linux-large, 4 linux-extra-large
|
||||
medium-changeset: 6 linux-large, 5 linux-extra-large
|
||||
large-changeset: 6 linux-large, 6 linux-extra-large
|
||||
extra-large-changeset: 8 linux-large, 8 linux-extra-large
|
||||
assignment-rules:
|
||||
- projects:
|
||||
- e2e-gradle
|
||||
targets:
|
||||
- e2e-ci**
|
||||
run-on:
|
||||
- agent: linux-extra-large
|
||||
parallelism: 1
|
||||
- projects:
|
||||
- e2e-next
|
||||
- e2e-plugin
|
||||
targets:
|
||||
- e2e-ci**
|
||||
run-on:
|
||||
- agent: linux-extra-large
|
||||
parallelism: 2
|
||||
- projects:
|
||||
- e2e-angular
|
||||
- e2e-node
|
||||
- e2e-react
|
||||
targets:
|
||||
- e2e-ci**
|
||||
run-on:
|
||||
- agent: linux-extra-large
|
||||
parallelism: 1
|
||||
|
||||
- projects:
|
||||
- nx
|
||||
- workspace
|
||||
- remix
|
||||
- nx-maven-plugin
|
||||
targets:
|
||||
- install
|
||||
- test
|
||||
run-on:
|
||||
- agent: linux-large
|
||||
parallelism: 1
|
||||
- agent: linux-extra-large
|
||||
parallelism: 1
|
||||
|
||||
- projects:
|
||||
- e2e-release
|
||||
- e2e-nuxt
|
||||
- e2e-web
|
||||
- e2e-eslint
|
||||
- e2e-remix
|
||||
- e2e-cypress
|
||||
- e2e-docker
|
||||
- e2e-js
|
||||
- e2e-nx
|
||||
- e2e-nx-init
|
||||
- e2e-dotnet
|
||||
- e2e-workspace-create
|
||||
- e2e-rollup
|
||||
targets:
|
||||
- e2e-ci**
|
||||
run-on:
|
||||
- agent: linux-large
|
||||
parallelism: 1
|
||||
- agent: linux-extra-large
|
||||
parallelism: 2
|
||||
|
||||
# All other e2e tests can run in parallel
|
||||
- targets:
|
||||
- e2e-ci**
|
||||
run-on:
|
||||
- agent: linux-large
|
||||
parallelism: 2
|
||||
- agent: linux-extra-large
|
||||
parallelism: 3
|
||||
|
||||
# These projects should not need to be isolated.
|
||||
- projects:
|
||||
- nx-dev
|
||||
targets:
|
||||
- build*
|
||||
run-on:
|
||||
- agent: linux-extra-large
|
||||
parallelism: 1
|
||||
- projects:
|
||||
- angular
|
||||
- react
|
||||
targets:
|
||||
- test
|
||||
run-on:
|
||||
- agent: linux-extra-large
|
||||
parallelism: 1
|
||||
|
||||
- targets:
|
||||
- lint
|
||||
run-on:
|
||||
- agent: linux-large
|
||||
parallelism: 6
|
||||
- agent: linux-extra-large
|
||||
parallelism: 6
|
||||
|
||||
# TODO(altan): remove when scheduling issue resolved
|
||||
- projects:
|
||||
- nx-dev
|
||||
targets:
|
||||
- prebuild-banner
|
||||
run-on:
|
||||
- agent: linux-extra-large
|
||||
parallelism: 6
|
||||
|
||||
- targets:
|
||||
- "*"
|
||||
run-on:
|
||||
- agent: linux-large
|
||||
parallelism: 3
|
||||
- agent: linux-extra-large
|
||||
parallelism: 3
|
||||
small-changeset: 8 linux-medium
|
||||
medium-changeset: 10 linux-medium
|
||||
large-changeset: 12 linux-medium
|
||||
|
||||
@@ -1,5 +1,2 @@
|
||||
nx-dev/**/jest.config.js
|
||||
.next
|
||||
_files
|
||||
_solution
|
||||
nx-dev/tutorial/**/templates
|
||||
|
||||
@@ -1,479 +0,0 @@
|
||||
---
|
||||
description: Polls Nx Cloud CI pipeline and self-healing status. Returns structured state when actionable. Spawned by /nx-cloud-ci-monitor command to monitor CI Attempt status.
|
||||
mode: subagent
|
||||
---
|
||||
|
||||
# CI Watcher Subagent
|
||||
|
||||
You are a CI monitoring subagent responsible for polling Nx Cloud CI Attempt status and self-healing state. You report status back to the main agent - you do NOT make apply/reject decisions.
|
||||
|
||||
## Your Responsibilities
|
||||
|
||||
1. Poll CI status using the `ci_information` MCP tool
|
||||
2. Implement exponential backoff between polls
|
||||
3. Return structured state when an actionable condition is reached
|
||||
4. Track iteration count and elapsed time
|
||||
5. Output status updates based on verbosity level
|
||||
|
||||
## Input Parameters (from Main Agent)
|
||||
|
||||
The main agent may provide these optional parameters in the prompt:
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------- | -------------------------------------------------------- |
|
||||
| `branch` | Branch to monitor (auto-detected if not provided) |
|
||||
| `expectedCommitSha` | Commit SHA that should trigger a new CI Attempt |
|
||||
| `previousCipeUrl` | CI Attempt URL before the action (to detect change) |
|
||||
| `subagentTimeout` | Polling timeout in minutes (default: 60) |
|
||||
| `verbosity` | Output level: minimal, medium, verbose (default: medium) |
|
||||
|
||||
When `expectedCommitSha` or `previousCipeUrl` is provided, you must detect whether a new CI Attempt has spawned.
|
||||
|
||||
## MCP Tool Reference
|
||||
|
||||
### `ci_information`
|
||||
|
||||
**Input:**
|
||||
|
||||
```json
|
||||
{
|
||||
"branch": "string (optional, defaults to current git branch)",
|
||||
"select": "string (optional, comma-separated field names)",
|
||||
"pageToken": "number (optional, 0-based pagination for long strings)"
|
||||
}
|
||||
```
|
||||
|
||||
**Output:**
|
||||
|
||||
```json
|
||||
{
|
||||
"cipeStatus": "NOT_STARTED | IN_PROGRESS | SUCCEEDED | FAILED | CANCELED | TIMED_OUT",
|
||||
"cipeUrl": "string",
|
||||
"branch": "string",
|
||||
"commitSha": "string | null",
|
||||
"failedTaskIds": "string[]",
|
||||
"verifiedTaskIds": "string[]",
|
||||
"selfHealingEnabled": "boolean",
|
||||
"selfHealingStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
|
||||
"verificationStatus": "NOT_STARTED | IN_PROGRESS | COMPLETED | FAILED | NOT_EXECUTABLE | null",
|
||||
"userAction": "NONE | APPLIED | REJECTED | APPLIED_LOCALLY | APPLIED_AUTOMATICALLY | null",
|
||||
"failureClassification": "string | null",
|
||||
"taskOutputSummary": "string | null",
|
||||
"suggestedFixReasoning": "string | null",
|
||||
"suggestedFixDescription": "string | null",
|
||||
"suggestedFix": "string | null",
|
||||
"shortLink": "string | null",
|
||||
"couldAutoApplyTasks": "boolean | null",
|
||||
"confidence": "number | null",
|
||||
"confidenceReasoning": "string | null"
|
||||
}
|
||||
```
|
||||
|
||||
**Select Parameter:**
|
||||
|
||||
| Usage | Returns |
|
||||
| --------------- | ----------------------------------------------------------- |
|
||||
| No `select` | Formatted overview (truncated, not recommended for polling) |
|
||||
| Single field | Raw value with pagination for long strings |
|
||||
| Multiple fields | Object with requested field values |
|
||||
|
||||
**Field Sets for Efficient Polling:**
|
||||
|
||||
```yaml
|
||||
WAIT_FIELDS:
|
||||
'cipeUrl,commitSha,cipeStatus'
|
||||
# Minimal fields for detecting new CI Attempt
|
||||
|
||||
LIGHT_FIELDS:
|
||||
'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning'
|
||||
# Status fields for determining actionable state
|
||||
|
||||
HEAVY_FIELDS:
|
||||
'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'
|
||||
# Large content fields - fetch only when returning to main agent
|
||||
```
|
||||
|
||||
## Initial Wait
|
||||
|
||||
Before first poll, wait based on context:
|
||||
|
||||
- **Fresh start (no expected CIPE):** Wait 60 seconds to allow CI to start
|
||||
- **Expecting new CIPE:** Wait 30 seconds (action already triggered)
|
||||
|
||||
**IMPORTANT:** Always run sleep in foreground, NOT as background command.
|
||||
|
||||
```bash
|
||||
sleep 60 # or 30 if expecting new CIPE (FOREGROUND, not background)
|
||||
```
|
||||
|
||||
## Two-Phase Operation
|
||||
|
||||
The subagent operates in one of two modes depending on input:
|
||||
|
||||
### Mode 1: Fresh Start (no `expectedCommitSha` or `previousCipeUrl`)
|
||||
|
||||
Normal polling - process whatever CIPE is returned by `ci_information`.
|
||||
|
||||
### Mode 2: Wait-for-New-CIPE (when `expectedCommitSha` or `previousCipeUrl` provided)
|
||||
|
||||
**CRITICAL**: When expecting a new CIPE, the subagent must **completely ignore** the old/stale CIPE. Do NOT process its status, do NOT return actionable states based on it.
|
||||
|
||||
#### Phase A: Wait Mode
|
||||
|
||||
1. Start a **new-CIPE timeout** timer (default: 30 minutes)
|
||||
2. On each poll of `ci_information`:
|
||||
- Check if CIPE is NEW:
|
||||
- `cipeUrl` differs from `previousCipeUrl` → **new CIPE detected**
|
||||
- `commitSha` matches `expectedCommitSha` → **correct CIPE detected**
|
||||
- If still OLD CIPE: **ignore all status fields**, just wait and poll again
|
||||
- Do NOT return `fix_available`, `ci_success`, etc. based on old CIPE!
|
||||
3. Output wait status (see below)
|
||||
4. If timeout (30 min) reached → return `no_new_cipe`
|
||||
|
||||
#### Phase B: Normal Polling (after new CIPE detected)
|
||||
|
||||
Once new CIPE is detected:
|
||||
|
||||
1. Clear the new-CIPE timeout
|
||||
2. Switch to normal polling mode
|
||||
3. Process the NEW CIPE's status normally
|
||||
4. Return when actionable state reached
|
||||
|
||||
### Wait Mode Output
|
||||
|
||||
While in wait mode, output clearly that you're waiting (not processing):
|
||||
|
||||
```
|
||||
[CI Monitor] ═══════════════════════════════════════════════════════
|
||||
[CI Monitor] WAIT MODE - Expecting new CI Attempt
|
||||
[CI Monitor] Expected SHA: <expectedCommitSha>
|
||||
[CI Monitor] Previous CI Attempt: <previousCipeUrl>
|
||||
[CI Monitor] ═══════════════════════════════════════════════════════
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 0m 30s)
|
||||
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 1m 30s)
|
||||
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
|
||||
|
||||
[CI Monitor] Polling... (elapsed: 2m 30s)
|
||||
[CI Monitor] ✓ New CI Attempt detected! URL: <newCipeUrl>, SHA: <newCommitSha>
|
||||
[CI Monitor] Switching to normal polling mode...
|
||||
```
|
||||
|
||||
### Why This Matters (Context Preservation)
|
||||
|
||||
**The problem**: Stale CIPE data can be very large:
|
||||
|
||||
- `taskOutputSummary`: potentially thousands of characters of build/test output
|
||||
- `suggestedFix`: entire patch files
|
||||
- `suggestedFixReasoning`: detailed explanation
|
||||
|
||||
If subagent returns stale CIPE data to main agent, it **pollutes main agent's context** with useless information (we already processed that CIPE). This wastes valuable context window.
|
||||
|
||||
**Without wait mode:**
|
||||
|
||||
1. Poll `ci_information` → get old CIPE with huge data
|
||||
2. Return to main agent with all that stale data
|
||||
3. Main agent's context gets polluted with useless info
|
||||
4. Main agent has to process/ignore it anyway
|
||||
|
||||
**With wait mode:**
|
||||
|
||||
1. Poll `ci_information` → get old CIPE → **ignore it, don't return**
|
||||
2. Keep waiting internally (stale data stays in subagent)
|
||||
3. New CIPE appears → switch to normal mode
|
||||
4. Return to main agent with only the NEW, relevant CIPE data
|
||||
|
||||
## Polling Loop
|
||||
|
||||
### Subagent State Management
|
||||
|
||||
Maintain internal accumulated state across polls:
|
||||
|
||||
```
|
||||
accumulated_state = {}
|
||||
```
|
||||
|
||||
### Call `ci_information` MCP Tool
|
||||
|
||||
**Wait Mode (expecting new CI Attempt):**
|
||||
|
||||
```
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "cipeUrl,commitSha,cipeStatus"
|
||||
})
|
||||
```
|
||||
|
||||
Only fetch minimal fields needed to detect CI Attempt change. Do NOT fetch heavy fields - stale data wastes context.
|
||||
|
||||
**Normal Mode (processing CI Attempt):**
|
||||
|
||||
```
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,shortLink,confidence,confidenceReasoning"
|
||||
})
|
||||
```
|
||||
|
||||
Merge response into `accumulated_state` after each poll.
|
||||
|
||||
### Analyze Response
|
||||
|
||||
**If in Wait Mode** (expecting new CIPE):
|
||||
|
||||
1. Check if CIPE is new (see Two-Phase Operation above)
|
||||
2. If old CIPE → **ignore status**, output wait message, poll again
|
||||
3. If new CIPE → switch to normal mode, continue below
|
||||
|
||||
**If in Normal Mode**:
|
||||
Based on the response, decide whether to **keep polling** or **return to main agent**.
|
||||
|
||||
### Keep Polling When
|
||||
|
||||
Continue polling (with backoff) if ANY of these conditions are true:
|
||||
|
||||
| Condition | Reason |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| `cipeStatus == 'IN_PROGRESS'` | CI still running |
|
||||
| `cipeStatus == 'NOT_STARTED'` | CI hasn't started yet |
|
||||
| `selfHealingStatus == 'IN_PROGRESS'` | Self-healing agent working |
|
||||
| `selfHealingStatus == 'NOT_STARTED'` | Self-healing not started yet |
|
||||
| `failureClassification == 'FLAKY_TASK'` | Auto-rerun in progress |
|
||||
| `userAction == 'APPLIED_AUTOMATICALLY'` | New CI Attempt spawning after auto-apply |
|
||||
|
||||
When `couldAutoApplyTasks == true`:
|
||||
|
||||
- `verificationStatus` = `NOT_STARTED`, `IN_PROGRESS` → keep polling (verification still in progress)
|
||||
- `verificationStatus` = `COMPLETED` → return `fix_auto_applying` (auto-apply will happen, main agent spawns wait mode subagent)
|
||||
- `verificationStatus` = `FAILED`, `NOT_EXECUTABLE` → return `fix_available` (auto-apply won't happen, needs manual action)
|
||||
|
||||
### Exponential Backoff
|
||||
|
||||
Between polls, wait with exponential backoff:
|
||||
|
||||
| Poll Attempt | Wait Time |
|
||||
| ------------ | ----------------- |
|
||||
| 1st | 60 seconds |
|
||||
| 2nd | 90 seconds |
|
||||
| 3rd+ | 120 seconds (cap) |
|
||||
|
||||
Reset to 60 seconds when state changes significantly.
|
||||
|
||||
**IMPORTANT:** Run sleep in foreground (NOT as background command). Background sleep causes "What should Claude do?" prompts when completed.
|
||||
|
||||
```bash
|
||||
# Example backoff - run in FOREGROUND
|
||||
sleep 60 # First wait
|
||||
sleep 90 # Second wait
|
||||
sleep 120 # Third and subsequent waits (capped)
|
||||
```
|
||||
|
||||
### Fetch Heavy Fields on Actionable State
|
||||
|
||||
Before returning to main agent, fetch heavy fields if the status requires them:
|
||||
|
||||
| Status | Heavy Fields Needed |
|
||||
| ------------------- | ------------------------------------------------------------------------------ |
|
||||
| `ci_success` | None |
|
||||
| `fix_auto_applying` | None |
|
||||
| `fix_available` | `taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription` |
|
||||
| `fix_failed` | `taskOutputSummary` |
|
||||
| `no_fix` | `taskOutputSummary` |
|
||||
| `environment_issue` | None |
|
||||
| `no_new_cipe` | None |
|
||||
| `polling_timeout` | None |
|
||||
| `cipe_canceled` | None |
|
||||
| `cipe_timed_out` | None |
|
||||
|
||||
```
|
||||
# Example: fetching heavy fields for fix_available
|
||||
ci_information({
|
||||
branch: "<branch_name>",
|
||||
select: "taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription"
|
||||
})
|
||||
```
|
||||
|
||||
Merge response into `accumulated_state`, then return merged state to main agent.
|
||||
|
||||
**Pagination:** Heavy string fields return first page only. If `hasMore` indicated, include in return format so main agent knows more content available.
|
||||
|
||||
### Return to Main Agent When
|
||||
|
||||
Return immediately with structured state if ANY of these conditions are true:
|
||||
|
||||
| Status | Condition |
|
||||
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | `cipeStatus == 'SUCCEEDED'` |
|
||||
| `fix_auto_applying` | `selfHealingStatus == 'COMPLETED'` AND `couldAutoApplyTasks == true` AND `verificationStatus == 'COMPLETED'` |
|
||||
| `fix_available` | `selfHealingStatus == 'COMPLETED'` AND `suggestedFix != null` AND (`couldAutoApplyTasks != true` OR `verificationStatus` in (`FAILED`, `NOT_EXECUTABLE`)) |
|
||||
| `fix_failed` | `selfHealingStatus == 'FAILED'` |
|
||||
| `environment_issue` | `failureClassification == 'ENVIRONMENT_STATE'` |
|
||||
| `no_fix` | `cipeStatus == 'FAILED'` AND (`selfHealingEnabled == false` OR `selfHealingStatus == 'NOT_EXECUTABLE'`) |
|
||||
| `no_new_cipe` | `expectedCommitSha` or `previousCipeUrl` provided, but no new CI Attempt detected after 30 min |
|
||||
| `polling_timeout` | Subagent has been polling for > configured timeout (default 60 min) |
|
||||
| `cipe_canceled` | `cipeStatus == 'CANCELED'` |
|
||||
| `cipe_timed_out` | `cipeStatus == 'TIMED_OUT'` |
|
||||
|
||||
## Subagent Timeout
|
||||
|
||||
Track elapsed time. If you have been polling for more than **60 minutes** (configurable via main agent), return with `status: polling_timeout`.
|
||||
|
||||
## Return Format
|
||||
|
||||
When returning to the main agent, provide a structured response with accumulated state:
|
||||
|
||||
```
|
||||
## CI Monitor Result
|
||||
|
||||
**Status:** <status>
|
||||
**Iterations:** <count>
|
||||
**Elapsed:** <minutes>m <seconds>s
|
||||
|
||||
### CI Attempt Details
|
||||
- **Status:** <cipeStatus>
|
||||
- **URL:** <cipeUrl>
|
||||
- **Branch:** <branch>
|
||||
- **Commit:** <commitSha>
|
||||
- **Failed Tasks:** <failedTaskIds>
|
||||
- **Verified Tasks:** <verifiedTaskIds>
|
||||
|
||||
### Self-Healing Details
|
||||
- **Enabled:** <selfHealingEnabled>
|
||||
- **Status:** <selfHealingStatus>
|
||||
- **Verification:** <verificationStatus>
|
||||
- **User Action:** <userAction>
|
||||
- **Classification:** <failureClassification>
|
||||
- **Confidence:** <confidence>
|
||||
- **Confidence Reasoning:** <confidenceReasoning>
|
||||
|
||||
### Fix Information (if available)
|
||||
- **Short Link:** <shortLink>
|
||||
- **Description:** <suggestedFixDescription>
|
||||
- **Reasoning:** <suggestedFixReasoning>
|
||||
|
||||
### Task Output Summary (first page)
|
||||
<taskOutputSummary>
|
||||
[MORE_CONTENT_AVAILABLE: taskOutputSummary, pageToken: 1]
|
||||
|
||||
### Suggested Fix (first page)
|
||||
<suggestedFix>
|
||||
[MORE_CONTENT_AVAILABLE: suggestedFix, pageToken: 1]
|
||||
```
|
||||
|
||||
### Pagination Indicators
|
||||
|
||||
When a heavy field has more content available, append indicator:
|
||||
|
||||
```
|
||||
[MORE_CONTENT_AVAILABLE: <fieldName>, pageToken: <nextPage>]
|
||||
```
|
||||
|
||||
Main agent can fetch additional pages if needed using:
|
||||
|
||||
```
|
||||
ci_information({ select: "<fieldName>", pageToken: <nextPage> })
|
||||
```
|
||||
|
||||
Fields that may have pagination:
|
||||
|
||||
- `taskOutputSummary` (reverse pagination - page 0 = most recent)
|
||||
- `suggestedFix` (forward pagination - page 0 = start)
|
||||
- `suggestedFixReasoning`
|
||||
|
||||
### Return Format for `no_new_cipe`
|
||||
|
||||
When returning with `status: no_new_cipe`, include additional context:
|
||||
|
||||
```
|
||||
## CI Monitor Result
|
||||
|
||||
**Status:** no_new_cipe
|
||||
**Iterations:** <count>
|
||||
**Elapsed:** <minutes>m <seconds>s
|
||||
|
||||
### Expected CI Attempt Not Found
|
||||
- **Expected Commit SHA:** <expectedCommitSha>
|
||||
- **Previous CI Attempt URL:** <previousCipeUrl>
|
||||
- **Last Seen CI Attempt URL:** <cipeUrl>
|
||||
- **Last Seen Commit SHA:** <commitSha>
|
||||
- **New CI Attempt Timeout:** 30 minutes (exceeded)
|
||||
|
||||
### Likely Cause
|
||||
CI workflow failed before Nx tasks could run (e.g., install step, checkout, auth).
|
||||
Check your CI provider logs for the commit <expectedCommitSha>.
|
||||
|
||||
### Last Known CI Attempt State
|
||||
- **Status:** <cipeStatus>
|
||||
- **Branch:** <branch>
|
||||
```
|
||||
|
||||
## Status Reporting (Verbosity-Controlled)
|
||||
|
||||
Output is controlled by the `verbosity` parameter from the main agent:
|
||||
|
||||
| Level | What to Output |
|
||||
| --------- | ----------------------------------------------------------------- |
|
||||
| `minimal` | No intermediate output. Only return final result when actionable. |
|
||||
| `medium` | Output only on significant state changes (not every poll). |
|
||||
| `verbose` | Output detailed phase information after every poll. |
|
||||
|
||||
### Minimal Verbosity
|
||||
|
||||
No output during polling. Poll silently and return when done.
|
||||
|
||||
### Medium Verbosity (Default)
|
||||
|
||||
Output **only when state changes significantly** to save context tokens:
|
||||
|
||||
- `cipeStatus` changes (e.g., IN_PROGRESS → FAILED)
|
||||
- `selfHealingStatus` changes (e.g., IN_PROGRESS → COMPLETED)
|
||||
- New CI Attempt detected (in wait mode)
|
||||
|
||||
Format: single line, no decorators:
|
||||
|
||||
```
|
||||
[CI Monitor] CI: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 4m
|
||||
```
|
||||
|
||||
### Verbose Verbosity
|
||||
|
||||
Output detailed phase box after every poll:
|
||||
|
||||
```
|
||||
[CI Monitor] ─────────────────────────────────────────────────────
|
||||
[CI Monitor] Iteration <N> | Elapsed: <X>m <Y>s
|
||||
[CI Monitor]
|
||||
[CI Monitor] CI Status: <cipeStatus>
|
||||
[CI Monitor] Self-Healing: <selfHealingStatus>
|
||||
[CI Monitor] Verification: <verificationStatus>
|
||||
[CI Monitor] Classification: <failureClassification>
|
||||
[CI Monitor]
|
||||
[CI Monitor] → <human-readable phase description>
|
||||
[CI Monitor] ─────────────────────────────────────────────────────
|
||||
```
|
||||
|
||||
### Phase Descriptions (for verbose output)
|
||||
|
||||
| Status Combo | Description |
|
||||
| ----------------------------------------------------------------------------------------- | ------------------------------------------- |
|
||||
| `cipeStatus: IN_PROGRESS` | "CI running..." |
|
||||
| `cipeStatus: NOT_STARTED` | "Waiting for CI to start..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: NOT_STARTED` | "CI failed. Self-healing starting..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: IN_PROGRESS` | "CI failed. Self-healing generating fix..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: IN_PROGRESS` | "Fix generated! Verification running..." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: COMPLETED` | "Fix ready! Verified successfully." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: COMPLETED` + `verificationStatus: FAILED` | "Fix generated but verification failed." |
|
||||
| `cipeStatus: FAILED` + `selfHealingStatus: FAILED` | "Self-healing could not generate a fix." |
|
||||
| `cipeStatus: SUCCEEDED` | "CI passed!" |
|
||||
|
||||
## Important Notes
|
||||
|
||||
- You do NOT make apply/reject decisions - that's the main agent's job
|
||||
- You do NOT perform git operations
|
||||
- You only poll and report state
|
||||
- Respect the `verbosity` parameter for output (default: medium)
|
||||
- If `ci_information` returns an error, wait and retry (count as failed poll)
|
||||
- Track consecutive failures - if 5 consecutive failures, return with `status: error`
|
||||
- When expecting new CI Attempt, track the 30-minute new-CI-Attempt timeout separately from the main polling timeout
|
||||
@@ -1,437 +0,0 @@
|
||||
---
|
||||
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
|
||||
argument-hint: '[instructions] [--max-cycles N] [--timeout MINUTES] [--verbosity minimal|medium|verbose] [--branch BRANCH] [--fresh] [--auto-fix-workflow] [--new-cipe-timeout MINUTES]'
|
||||
---
|
||||
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
Parse any overrides from `$ARGUMENTS` and merge with defaults.
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \| Elapsed: Xm \| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```
|
||||
@@ -1,437 +0,0 @@
|
||||
---
|
||||
name: ci-monitor
|
||||
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
|
||||
---
|
||||
|
||||
# CI Monitor Command
|
||||
|
||||
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
|
||||
|
||||
## Context
|
||||
|
||||
- **Current Branch:** !`git branch --show-current`
|
||||
- **Current Commit:** !`git rev-parse --short HEAD`
|
||||
- **Remote Status:** !`git status -sb | head -1`
|
||||
|
||||
## User Instructions
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
**Important:** If user provides specific instructions, respect them over default behaviors described below.
|
||||
|
||||
## Configuration Defaults
|
||||
|
||||
| Setting | Default | Description |
|
||||
| ------------------------- | ------------- | ------------------------------------------------------------------- |
|
||||
| `--max-cycles` | 10 | Maximum CIPE cycles before timeout |
|
||||
| `--timeout` | 120 | Maximum duration in minutes |
|
||||
| `--verbosity` | medium | Output level: minimal, medium, verbose |
|
||||
| `--branch` | (auto-detect) | Branch to monitor |
|
||||
| `--subagent-timeout` | 60 | Subagent polling timeout in minutes |
|
||||
| `--fresh` | false | Ignore previous context, start fresh |
|
||||
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
|
||||
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
|
||||
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
|
||||
|
||||
Parse any overrides from `$ARGUMENTS` and merge with defaults.
|
||||
|
||||
## Nx Cloud Connection Check
|
||||
|
||||
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
|
||||
|
||||
### Step 0: Verify Nx Cloud Connection
|
||||
|
||||
1. **Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
|
||||
2. **If `nx.json` missing OR neither property exists** → exit with:
|
||||
```
|
||||
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
|
||||
```
|
||||
3. **If connected** → continue to main loop
|
||||
|
||||
## Session Context Behavior
|
||||
|
||||
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
|
||||
|
||||
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
|
||||
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
|
||||
- **For a completely clean slate:** Exit Claude Code and restart `claude`
|
||||
|
||||
## Default Behaviors by Status
|
||||
|
||||
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
|
||||
|
||||
| Status | Default Behavior |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ci_success` | Exit with success. Log "CI passed successfully!" |
|
||||
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
|
||||
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
|
||||
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
|
||||
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
|
||||
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
|
||||
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
|
||||
| `polling_timeout` | Subagent polling timeout reached. Exit with timeout. |
|
||||
| `cipe_canceled` | CIPE was canceled. Exit with canceled status. |
|
||||
| `cipe_timed_out` | CIPE timed out. Exit with timeout status. |
|
||||
| `error` | Increment `no_progress_count`. If >= 3 → exit with circuit breaker. Otherwise wait 60s and loop. |
|
||||
|
||||
### Fix Available Decision Logic
|
||||
|
||||
When subagent returns `fix_available`, main agent compares `failedTaskIds` vs `verifiedTaskIds`:
|
||||
|
||||
#### Step 1: Categorize Tasks
|
||||
|
||||
1. **Verified tasks** = tasks in both `failedTaskIds` AND `verifiedTaskIds`
|
||||
2. **Unverified tasks** = tasks in `failedTaskIds` but NOT in `verifiedTaskIds`
|
||||
3. **E2E tasks** = unverified tasks where target contains "e2e" (task format: `<project>:<target>` or `<project>:<target>:<config>`)
|
||||
4. **Verifiable tasks** = unverified tasks that are NOT e2e
|
||||
|
||||
#### Step 2: Determine Path
|
||||
|
||||
| Condition | Path |
|
||||
| --------------------------------------- | ---------------------------------------- |
|
||||
| No unverified tasks (all verified) | Apply via MCP |
|
||||
| Unverified tasks exist, but ALL are e2e | Apply via MCP (treat as verified enough) |
|
||||
| Verifiable tasks exist | Local verification flow |
|
||||
|
||||
#### Step 3a: Apply via MCP (fully/e2e-only verified)
|
||||
|
||||
- Call `update_self_healing_fix({ shortLink, action: "APPLY" })`
|
||||
- Record `last_cipe_url`, spawn subagent in wait mode
|
||||
|
||||
#### Step 3b: Local Verification Flow
|
||||
|
||||
When verifiable (non-e2e) unverified tasks exist:
|
||||
|
||||
1. **Detect package manager:**
|
||||
- `pnpm-lock.yaml` exists → `pnpm nx`
|
||||
- `yarn.lock` exists → `yarn nx`
|
||||
- Otherwise → `npx nx`
|
||||
|
||||
2. **Run verifiable tasks in parallel:**
|
||||
- Spawn `general` subagents to run each task concurrently
|
||||
- Each subagent runs: `<pm> nx run <taskId>`
|
||||
- Collect pass/fail results from all subagents
|
||||
|
||||
3. **Evaluate results:**
|
||||
|
||||
| Result | Action |
|
||||
| ------------------------- | ---------------------------- |
|
||||
| ALL verifiable tasks pass | Apply via MCP |
|
||||
| ANY verifiable task fails | Apply-locally + enhance flow |
|
||||
|
||||
4. **Apply-locally + enhance flow:**
|
||||
- Run `nx apply-locally <shortLink>`
|
||||
- Enhance the code to fix failing tasks
|
||||
- Run failing tasks again to verify fix
|
||||
- If still failing → increment `local_verify_count`, loop back to enhance
|
||||
- If passing → commit and push, record `expected_commit_sha`, spawn subagent in wait mode
|
||||
|
||||
5. **Track attempts** (wraps step 4):
|
||||
- Increment `local_verify_count` after each enhance cycle
|
||||
- If `local_verify_count >= local_verify_attempts` (default: 3):
|
||||
- Get code in commit-able state
|
||||
- Commit and push with message indicating local verification failed
|
||||
- Report to user:
|
||||
```
|
||||
[ci-monitor] Local verification failed after <N> attempts. Pushed to CI for final validation. Failed: <taskIds>
|
||||
```
|
||||
- Record `expected_commit_sha`, spawn subagent in wait mode (let CI be final judge)
|
||||
|
||||
#### Commit Message Format
|
||||
|
||||
```bash
|
||||
git commit -m "fix(<projects>): <brief description>
|
||||
|
||||
Failed tasks: <taskId1>, <taskId2>
|
||||
Local verification: passed|enhanced|failed-pushing-to-ci"
|
||||
```
|
||||
|
||||
### Unverified Fix Flow (No Verification Attempted)
|
||||
|
||||
When `verificationStatus` is `FAILED`, `NOT_EXECUTABLE`, or fix has `couldAutoApplyTasks != true` with no verification:
|
||||
|
||||
- Analyze fix content (`suggestedFix`, `suggestedFixReasoning`, `taskOutputSummary`)
|
||||
- If fix looks correct → apply via MCP
|
||||
- If fix needs enhancement → use Apply Locally + Enhance Flow above
|
||||
- If fix is wrong → reject via MCP, fix from scratch, commit, push
|
||||
|
||||
### Auto-Apply Eligibility
|
||||
|
||||
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
|
||||
|
||||
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
|
||||
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
|
||||
|
||||
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
|
||||
|
||||
### Apply vs Reject vs Apply Locally
|
||||
|
||||
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
|
||||
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
|
||||
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
|
||||
|
||||
### Apply Locally + Enhance Flow
|
||||
|
||||
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
|
||||
|
||||
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
|
||||
2. Make additional changes as needed
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Reject + Fix From Scratch Flow
|
||||
|
||||
When the fix is completely wrong:
|
||||
|
||||
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
|
||||
2. Fix the issue from scratch locally
|
||||
3. Commit and push:
|
||||
```bash
|
||||
git add -A
|
||||
git commit -m "fix: resolve <failedTaskIds>"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
4. Loop to poll for new CIPE
|
||||
|
||||
### Environment Issue Handling
|
||||
|
||||
When `failureClassification == 'ENVIRONMENT_STATE'`:
|
||||
|
||||
1. Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`
|
||||
2. New CIPE spawns automatically (no local git operations needed)
|
||||
3. Loop to poll for new CIPE with `previousCipeUrl` set
|
||||
|
||||
### No-New-CIPE Handling
|
||||
|
||||
When `status == 'no_new_cipe'`:
|
||||
|
||||
This means the expected CIPE was never created - CI likely failed before Nx tasks could run.
|
||||
|
||||
1. **Report to user:**
|
||||
|
||||
```
|
||||
[ci-monitor] No CI attempt for <sha> after 10 min. Check CI provider for pre-Nx failures (install, checkout, auth). Last CI attempt: <previousCipeUrl>
|
||||
```
|
||||
|
||||
2. **If user configured auto-fix attempts** (e.g., `--auto-fix-workflow`):
|
||||
- Detect package manager: check for `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`
|
||||
- Run install to update lockfile:
|
||||
```bash
|
||||
pnpm install # or npm install / yarn install
|
||||
```
|
||||
- If lockfile changed:
|
||||
```bash
|
||||
git add pnpm-lock.yaml # or appropriate lockfile
|
||||
git commit -m "chore: update lockfile"
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
- Record new commit SHA, loop to poll with `expectedCommitSha`
|
||||
|
||||
3. **Otherwise:** Exit with `no_new_cipe` status, providing guidance for user to investigate
|
||||
|
||||
## Exit Conditions
|
||||
|
||||
Exit the monitoring loop when ANY of these conditions are met:
|
||||
|
||||
| Condition | Exit Type |
|
||||
| ------------------------------------------- | ---------------- |
|
||||
| CI passes (`cipeStatus == 'SUCCEEDED'`) | Success |
|
||||
| Max CIPE cycles reached | Timeout |
|
||||
| Max duration reached | Timeout |
|
||||
| 3 consecutive no-progress iterations | Circuit breaker |
|
||||
| No fix available and local fix not possible | Failure |
|
||||
| No new CIPE and auto-fix not configured | Pre-CIPE failure |
|
||||
| User cancels | Cancelled |
|
||||
|
||||
## Main Loop
|
||||
|
||||
### Step 1: Initialize Tracking
|
||||
|
||||
```
|
||||
cycle_count = 0
|
||||
start_time = now()
|
||||
no_progress_count = 0
|
||||
local_verify_count = 0
|
||||
last_state = null
|
||||
last_cipe_url = null
|
||||
expected_commit_sha = null
|
||||
```
|
||||
|
||||
### Step 2: Spawn Subagent
|
||||
|
||||
Spawn the `ci-watcher` subagent to poll CI status:
|
||||
|
||||
**Fresh start (first spawn, no expected CIPE):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>."
|
||||
)
|
||||
```
|
||||
|
||||
**After action that triggers new CIPE (wait mode):**
|
||||
|
||||
```
|
||||
Task(
|
||||
agent: "ci-watcher",
|
||||
prompt: "Monitor CI for branch '<branch>'.
|
||||
Subagent timeout: <subagent-timeout> minutes.
|
||||
New-CIPE timeout: <new-cipe-timeout> minutes.
|
||||
Verbosity: <verbosity>.
|
||||
|
||||
WAIT MODE: A new CIPE should spawn. Ignore old CIPE until new one appears.
|
||||
Expected commit SHA: <expected_commit_sha>
|
||||
Previous CIPE URL: <last_cipe_url>"
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Handle Subagent Response
|
||||
|
||||
When subagent returns:
|
||||
|
||||
1. Check the returned status
|
||||
2. Look up default behavior in the table above
|
||||
3. Check if user instructions override the default
|
||||
4. Execute the appropriate action
|
||||
5. **If action expects new CIPE**, update tracking (see Step 3a)
|
||||
6. If action results in looping, go to Step 2
|
||||
|
||||
### Step 3a: Track State for New-CIPE Detection
|
||||
|
||||
After actions that should trigger a new CIPE, record state before looping:
|
||||
|
||||
| Action | What to Track | Subagent Mode |
|
||||
| ----------------------------- | --------------------------------------------- | ------------- |
|
||||
| Fix auto-applying | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply via MCP | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| Apply locally + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Reject + fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Fix failed + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| No fix + local fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
| Environment rerun | `last_cipe_url = current cipeUrl` | Wait mode |
|
||||
| No-new-CIPE + auto-fix + push | `expected_commit_sha = $(git rev-parse HEAD)` | Wait mode |
|
||||
|
||||
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
|
||||
|
||||
- Subagent will **completely ignore** the old/stale CIPE
|
||||
- Subagent will only wait for new CIPE to appear
|
||||
- Subagent will NOT return to main agent with stale CIPE data
|
||||
- Once new CIPE detected, subagent switches to normal polling
|
||||
|
||||
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
|
||||
|
||||
### Step 4: Progress Tracking
|
||||
|
||||
After each action:
|
||||
|
||||
- If state changed significantly → reset `no_progress_count = 0`
|
||||
- If state unchanged → `no_progress_count++`
|
||||
- On new CI attempt detected → reset `local_verify_count = 0`
|
||||
|
||||
## Status Reporting
|
||||
|
||||
Based on verbosity level:
|
||||
|
||||
| Level | What to Report |
|
||||
| --------- | -------------------------------------------------------------------------- |
|
||||
| `minimal` | Only final result (success/failure/timeout) |
|
||||
| `medium` | State changes + periodic updates ("Cycle N \| Elapsed: Xm \| Status: ...") |
|
||||
| `verbose` | All of medium + full subagent responses, git outputs, MCP responses |
|
||||
|
||||
## User Instruction Examples
|
||||
|
||||
Users can override default behaviors:
|
||||
|
||||
| Instruction | Effect |
|
||||
| ------------------------------------------------ | --------------------------------------------- |
|
||||
| "never auto-apply" | Always prompt before applying any fix |
|
||||
| "always ask before git push" | Prompt before each push |
|
||||
| "reject any fix for e2e tasks" | Auto-reject if `failedTaskIds` contains e2e |
|
||||
| "apply all fixes regardless of verification" | Skip verification check, apply everything |
|
||||
| "if confidence < 70, reject" | Check confidence field before applying |
|
||||
| "run 'nx affected -t typecheck' before applying" | Add local verification step |
|
||||
| "auto-fix workflow failures" | Attempt lockfile updates on pre-CIPE failures |
|
||||
| "wait 45 min for new CIPE" | Override new-CIPE timeout (default: 10 min) |
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------- |
|
||||
| Git rebase conflict | Report to user, exit |
|
||||
| `nx apply-locally` fails | Report to user, attempt manual patch or exit |
|
||||
| MCP tool error | Retry once, if fails report to user |
|
||||
| Subagent spawn failure | Retry once, if fails exit with error |
|
||||
| No new CIPE detected | If `--auto-fix-workflow`, try lockfile update; otherwise report to user with guidance |
|
||||
| Lockfile auto-fix fails | Report to user, exit with guidance to check CI logs |
|
||||
|
||||
## Example Session
|
||||
|
||||
### Example 1: Normal Flow with Self-Healing (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-auth'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, verbosity=medium
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: IN_PROGRESS | Self-Healing: NOT_STARTED | Elapsed: 1m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: IN_PROGRESS | Elapsed: 3m
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 5m
|
||||
|
||||
[ci-monitor] Fix available! Verification: COMPLETED
|
||||
[ci-monitor] Applying fix via MCP...
|
||||
[ci-monitor] Fix applied in CI. Waiting for new CI attempt...
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 8m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 2
|
||||
- Total time: 12m 34s
|
||||
- Fixes applied: 1
|
||||
- Result: SUCCESS
|
||||
```
|
||||
|
||||
### Example 2: Pre-CI Failure (medium verbosity)
|
||||
|
||||
```
|
||||
[ci-monitor] Starting CI monitor for branch 'feature/add-products'
|
||||
[ci-monitor] Config: max-cycles=5, timeout=120m, auto-fix-workflow=true
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] CI attempt: FAILED | Self-Healing: COMPLETED | Elapsed: 2m
|
||||
|
||||
[ci-monitor] Applying fix locally, enhancing, and pushing...
|
||||
[ci-monitor] Committed: abc1234
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] Waiting for new CI attempt... (expected SHA: abc1234)
|
||||
[CI Monitor] ⚠️ CI attempt timeout (10 min). Returning no_new_cipe.
|
||||
|
||||
[ci-monitor] Status: no_new_cipe
|
||||
[ci-monitor] --auto-fix-workflow enabled. Attempting lockfile update...
|
||||
[ci-monitor] Lockfile updated. Committed: def5678
|
||||
|
||||
[ci-monitor] Spawning subagent to poll CI status...
|
||||
[CI Monitor] New CI attempt detected!
|
||||
[CI Monitor] CI attempt: SUCCEEDED | Elapsed: 18m
|
||||
|
||||
[ci-monitor] CI passed successfully!
|
||||
|
||||
[ci-monitor] Summary:
|
||||
- Total cycles: 3
|
||||
- Total time: 22m 15s
|
||||
- Fixes applied: 1 (self-healing) + 1 (lockfile)
|
||||
- Result: SUCCESS
|
||||
```
|
||||
@@ -1,228 +0,0 @@
|
||||
---
|
||||
name: nx-generate
|
||||
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
|
||||
---
|
||||
|
||||
# Run Nx Generator
|
||||
|
||||
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
|
||||
|
||||
This skill applies when the user wants to:
|
||||
|
||||
- Create new projects like libraries or applications
|
||||
- Scaffold features or boilerplate code
|
||||
- Run workspace-specific or custom generators
|
||||
- Do anything else that an nx generator exists for
|
||||
|
||||
## Generator Discovery Flow
|
||||
|
||||
### Step 1: List Available Generators
|
||||
|
||||
Use the Nx CLI to discover available generators:
|
||||
|
||||
- List all generators for a plugin: `npx nx list @nx/react`
|
||||
- View available plugins: `npx nx list`
|
||||
|
||||
This includes:
|
||||
|
||||
- Plugin generators (e.g., `@nx/react:library`, `@nx/js:library`)
|
||||
- Local workspace generators (defined in the repo's own plugins)
|
||||
|
||||
### Step 2: Match Generator to User Request
|
||||
|
||||
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
|
||||
|
||||
- What artifact type they want to create (library, application, etc.)
|
||||
- Which framework or technology stack is relevant
|
||||
- Whether they mentioned specific generator names
|
||||
|
||||
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
|
||||
|
||||
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
|
||||
|
||||
## Pre-Execution Checklist
|
||||
|
||||
Before running any generator, complete these steps:
|
||||
|
||||
### 1. Fetch Generator Schema
|
||||
|
||||
Use the `--help` flag to understand all available options:
|
||||
|
||||
```bash
|
||||
npx nx g @nx/react:library --help
|
||||
```
|
||||
|
||||
Pay attention to:
|
||||
|
||||
- Required options that must be provided
|
||||
- Optional options that may be relevant to the user's request
|
||||
- Default values that might need to be overridden
|
||||
|
||||
### 2. Read Generator Source Code
|
||||
|
||||
Understanding what the generator actually does helps you:
|
||||
|
||||
- Know what files will be created/modified
|
||||
- Understand any side effects (updating configs, installing deps, etc.)
|
||||
- Identify options that might not be obvious from the schema
|
||||
|
||||
To find generator source code:
|
||||
|
||||
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
|
||||
- If that fails, read directly from `node_modules/<plugin>/generators.json`
|
||||
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
|
||||
|
||||
### 2.5 Reevaluate if the generator is right
|
||||
|
||||
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
|
||||
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
|
||||
|
||||
### 3. Understand Repo Context
|
||||
|
||||
Before generating, examine the target area of the codebase:
|
||||
|
||||
- Look at similar existing artifacts (other libraries, applications, etc.)
|
||||
- Identify patterns and conventions used in the repo
|
||||
- Note naming conventions, file structures, and configuration patterns
|
||||
- Try to match these patterns when configuring the generator
|
||||
|
||||
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
|
||||
If projects or other artifacts are organized with a specific naming convention, try to match it.
|
||||
|
||||
### 4. Validate Required Options
|
||||
|
||||
Ensure all required options have values:
|
||||
|
||||
- Map the user's request to generator options
|
||||
- Infer values from context where possible
|
||||
- Ask the user for any critical missing information
|
||||
|
||||
## Execution
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
|
||||
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
|
||||
|
||||
### Consider Dry-Run (Optional)
|
||||
|
||||
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
|
||||
|
||||
- For complex generators or unfamiliar territory: do a dry-run first
|
||||
- For simple, well-understood generators: may proceed directly
|
||||
- Dry-run shows file names and created/deleted/modified markers, but not content
|
||||
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
|
||||
|
||||
### Running the Generator
|
||||
|
||||
Execute the generator with:
|
||||
|
||||
```bash
|
||||
nx generate <generator-name> <options> --no-interactive
|
||||
```
|
||||
|
||||
**CRITICAL**: Always include `--no-interactive` to prevent prompts that would hang the execution.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx generate @nx/react:library --name=my-utils --no-interactive
|
||||
```
|
||||
|
||||
### Handling Generator Failures
|
||||
|
||||
If the generator fails:
|
||||
|
||||
1. **Diagnose the error** - Read the error message carefully
|
||||
2. **Identify the cause** - Missing options, invalid values, conflicts, etc.
|
||||
3. **Attempt automatic fix** - Adjust options or resolve conflicts
|
||||
4. **Retry** - Run the generator again with corrected options
|
||||
|
||||
Common failure reasons:
|
||||
|
||||
- Missing required options
|
||||
- Invalid option values
|
||||
- Conflicting with existing files
|
||||
- Missing dependencies
|
||||
- Generator doesn't support certain flag combinations
|
||||
|
||||
## Post-Generation
|
||||
|
||||
### 1. Modify Generated Code (If Needed)
|
||||
|
||||
Generators provide a starting point, but the output may need adjustment to match the user's specific requirements:
|
||||
|
||||
- Add or modify functionality as requested
|
||||
- Adjust imports, exports, or configurations
|
||||
- Integrate with existing code patterns in the repo
|
||||
|
||||
### 2. Format Code
|
||||
|
||||
Run formatting on all generated/modified files:
|
||||
|
||||
```bash
|
||||
nx format --fix
|
||||
```
|
||||
|
||||
Languages other than javascript/typescript might need other formatting invocations too.
|
||||
|
||||
### 3. Run Verification
|
||||
|
||||
Verify that the generated code works correctly. What this looks like will vary depending on the type of generator and the targets available.
|
||||
If the generator created a new project, run its targets directly
|
||||
Use your best judgement to determine what needs to be verified.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
nx lint <new-project>
|
||||
nx test <new-project>
|
||||
nx build <new-project>
|
||||
```
|
||||
|
||||
### 4. Handle Verification Failures
|
||||
|
||||
When verification fails:
|
||||
|
||||
**If scope is manageable** (a few lint errors, minor type issues):
|
||||
|
||||
- Fix the issues
|
||||
- Re-run verification to confirm
|
||||
|
||||
**If issues are extensive** (many errors, complex problems):
|
||||
|
||||
- Attempt simple, obvious fixes first
|
||||
- If still failing, escalate to the user with:
|
||||
- Description of what was generated
|
||||
- What verification is failing
|
||||
- What you've attempted to fix
|
||||
- Remaining issues that need user input
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Generator Failures
|
||||
|
||||
- Check the error message for specific causes
|
||||
- Verify all required options are provided
|
||||
- Check for conflicts with existing files
|
||||
- Ensure the generator name and options are correct
|
||||
|
||||
### Missing Options
|
||||
|
||||
- Consult the generator schema for required fields
|
||||
- Infer values from context when reasonable
|
||||
- Ask the user for values that cannot be inferred
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Local generators first** - Always prefer workspace/local generators over external plugin generators when both could work
|
||||
|
||||
2. **Understand before running** - Read both the schema AND the source code to fully understand what will happen
|
||||
|
||||
3. **No prompts** - Always use `--no-interactive` to prevent hanging
|
||||
|
||||
4. **Generators are starting points** - Modify the output as needed to fully satisfy the user's requirements
|
||||
|
||||
5. **Verify changes work** - Don't just generate; ensure the code builds, lints, and tests pass
|
||||
|
||||
6. **Be proactive about fixes** - Don't just report errors; attempt to resolve them automatically when possible
|
||||
|
||||
7. **Match repo patterns** - Study existing similar code in the repo and match its conventions
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
name: nx-plugins
|
||||
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
|
||||
---
|
||||
|
||||
## Finding and Installing new plugins
|
||||
|
||||
- List plugins: `pnpm nx list`
|
||||
- Install plugins `pnpm nx add <plugin>`. Example: `pnpm nx add @nx/react`.
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
name: nx-run-tasks
|
||||
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
|
||||
---
|
||||
|
||||
You can run tasks with Nx in the following way.
|
||||
|
||||
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
|
||||
|
||||
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
|
||||
|
||||
## Understand which tasks can be run
|
||||
|
||||
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
|
||||
|
||||
## Run a single task
|
||||
|
||||
```
|
||||
nx run <project>:<task>
|
||||
```
|
||||
|
||||
where `project` is the project name defined in `package.json` or `project.json` (if present).
|
||||
|
||||
## Run multiple tasks
|
||||
|
||||
```
|
||||
nx run-many -t build test lint typecheck
|
||||
```
|
||||
|
||||
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
|
||||
|
||||
Examples:
|
||||
|
||||
- `nx run-many -t test -p proj1 proj2` — test specific projects
|
||||
- `nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
|
||||
- `nx run-many -t test --projects=tag:api-*` — test projects by tag
|
||||
|
||||
## Run tasks for affected projects
|
||||
|
||||
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
|
||||
|
||||
```
|
||||
nx affected -t build test lint
|
||||
```
|
||||
|
||||
By default it compares against the base branch. You can customize this:
|
||||
|
||||
- `nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
|
||||
- `nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
|
||||
|
||||
## Useful flags
|
||||
|
||||
These flags work with `run`, `run-many`, and `affected`:
|
||||
|
||||
- `--skipNxCache` — rerun tasks even when results are cached
|
||||
- `--verbose` — print additional information such as stack traces
|
||||
- `--nxBail` — stop execution after the first failed task
|
||||
- `--configuration=<name>` — use a specific configuration (e.g. `production`)
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
name: nx-workspace
|
||||
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
|
||||
---
|
||||
|
||||
# Nx Workspace Exploration
|
||||
|
||||
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
|
||||
|
||||
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
|
||||
|
||||
## Listing Projects
|
||||
|
||||
Use `nx show projects` to list projects in the workspace.
|
||||
|
||||
```bash
|
||||
# List all projects
|
||||
nx show projects
|
||||
|
||||
# Filter by pattern (glob)
|
||||
nx show projects --projects "apps/*"
|
||||
nx show projects --projects "shared-*"
|
||||
|
||||
# Filter by project type
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
nx show projects --type e2e
|
||||
|
||||
# Filter by target (projects that have a specific target)
|
||||
nx show projects --withTarget build
|
||||
nx show projects --withTarget e2e
|
||||
|
||||
# Find affected projects (changed since base branch)
|
||||
nx show projects --affected
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Combine filters
|
||||
nx show projects --type lib --withTarget test
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Output as JSON
|
||||
nx show projects --json
|
||||
```
|
||||
|
||||
## Project Configuration
|
||||
|
||||
Use `nx show project <name> --json` to get the full resolved configuration for a project.
|
||||
|
||||
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
|
||||
|
||||
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Get full project configuration
|
||||
nx show project my-app --json
|
||||
|
||||
# Extract specific parts from the JSON
|
||||
nx show project my-app --json | jq '.targets'
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
|
||||
# Check project metadata
|
||||
nx show project my-app --json | jq '{name, root, sourceRoot, projectType, tags}'
|
||||
```
|
||||
|
||||
## Target Information
|
||||
|
||||
Targets define what tasks can be run on a project.
|
||||
|
||||
```bash
|
||||
# List all targets for a project
|
||||
nx show project my-app --json | jq '.targets | keys'
|
||||
|
||||
# Get full target configuration
|
||||
nx show project my-app --json | jq '.targets.build'
|
||||
|
||||
# Check target executor/command
|
||||
nx show project my-app --json | jq '.targets.build.executor'
|
||||
nx show project my-app --json | jq '.targets.build.command'
|
||||
|
||||
# View target options
|
||||
nx show project my-app --json | jq '.targets.build.options'
|
||||
|
||||
# Check target inputs/outputs (for caching)
|
||||
nx show project my-app --json | jq '.targets.build.inputs'
|
||||
nx show project my-app --json | jq '.targets.build.outputs'
|
||||
|
||||
# Find projects with a specific target
|
||||
nx show projects --withTarget serve
|
||||
nx show projects --withTarget e2e
|
||||
```
|
||||
|
||||
## Workspace Configuration
|
||||
|
||||
Read `nx.json` directly for workspace-level configuration.
|
||||
You can read the full project schema at `node_modules/nx/schemas/nx-schema.json` to understand nx project configuration options.
|
||||
|
||||
```bash
|
||||
# Read the full nx.json
|
||||
cat nx.json
|
||||
|
||||
# Or use jq for specific sections
|
||||
cat nx.json | jq '.targetDefaults'
|
||||
cat nx.json | jq '.namedInputs'
|
||||
cat nx.json | jq '.plugins'
|
||||
cat nx.json | jq '.generators'
|
||||
```
|
||||
|
||||
Key nx.json sections:
|
||||
|
||||
- `targetDefaults` - Default configuration applied to all targets of a given name
|
||||
- `namedInputs` - Reusable input definitions for caching
|
||||
- `plugins` - Nx plugins and their configuration
|
||||
- ...and much more, read the schema or nx.json for details
|
||||
|
||||
## Affected Projects
|
||||
|
||||
Find projects affected by changes in the current branch.
|
||||
|
||||
```bash
|
||||
# Affected since base branch (auto-detected)
|
||||
nx show projects --affected
|
||||
|
||||
# Affected with explicit base
|
||||
nx show projects --affected --base=main
|
||||
nx show projects --affected --base=origin/main
|
||||
|
||||
# Affected between two commits
|
||||
nx show projects --affected --base=abc123 --head=def456
|
||||
|
||||
# Affected apps only
|
||||
nx show projects --affected --type app
|
||||
|
||||
# Affected excluding e2e projects
|
||||
nx show projects --affected --exclude="*-e2e"
|
||||
|
||||
# Affected by uncommitted changes
|
||||
nx show projects --affected --uncommitted
|
||||
|
||||
# Affected by untracked files
|
||||
nx show projects --affected --untracked
|
||||
```
|
||||
|
||||
## Common Exploration Patterns
|
||||
|
||||
### "What's in this workspace?"
|
||||
|
||||
```bash
|
||||
nx show projects
|
||||
nx show projects --type app
|
||||
nx show projects --type lib
|
||||
```
|
||||
|
||||
### "How do I build/test/lint project X?"
|
||||
|
||||
```bash
|
||||
nx show project X --json | jq '.targets | keys'
|
||||
nx show project X --json | jq '.targets.build'
|
||||
```
|
||||
|
||||
### "What depends on library Y?"
|
||||
|
||||
```bash
|
||||
# Find projects that may depend on Y by searching for imports
|
||||
# (Nx doesn't have a direct "dependents" command via CLI)
|
||||
grep -r "from '@myorg/Y'" --include="*.ts" --include="*.tsx" apps/ libs/
|
||||
```
|
||||
|
||||
### "What configuration options are available?"
|
||||
|
||||
```bash
|
||||
cat node_modules/nx/schemas/nx-schema.json | jq '.properties | keys'
|
||||
cat node_modules/nx/schemas/project-schema.json | jq '.properties | keys'
|
||||
```
|
||||
|
||||
### "Why is project X affected?"
|
||||
|
||||
```bash
|
||||
# Check what files changed
|
||||
git diff --name-only main
|
||||
|
||||
# See which project owns those files
|
||||
nx show project X --json | jq '.root'
|
||||
```
|
||||
@@ -1,13 +0,0 @@
|
||||
# Enable pre/post-install which are disabled by default. Installing peer deps which is also disabled by default
|
||||
auto-install-peers=true
|
||||
enable-pre-post-scripts=true
|
||||
|
||||
# Enable lifecycle scripts for specific packages that require them (like post-install)
|
||||
enable-scripts=@napi-rs/canvas,sharp,@swc/core,@swc/cli,@swc-node/register,esbuild
|
||||
|
||||
# Compatibility
|
||||
strict-peer-dependencies=false
|
||||
lockfile-version-strict=false
|
||||
|
||||
# Consistency across environments
|
||||
use-node-version=20.19.0
|
||||
+1
-15
@@ -13,16 +13,10 @@ packages/express/src/schematics/**/files/**/*.json
|
||||
packages/nest/src/schematics/**/files/**/*.json
|
||||
packages/react/src/schematics/**/files/**/*.json
|
||||
packages/jest/src/schematics/**/files/**/*.json
|
||||
packages/gradle/project-graph/build/**/*.*
|
||||
packages/nx/src/plugins/js/lock-file/__fixtures__/**/*.*
|
||||
packages/**/schematics/**/files/**/*.html
|
||||
packages/**/generators/**/files/**/*.html
|
||||
packages/nx/src/native/**/*.rs
|
||||
packages/nx/src/native/browser.js
|
||||
packages/nx/src/native/nx.wasi-browser.js
|
||||
packages/nx/src/native/nx.wasi.cjs
|
||||
packages/nx/src/native/wasi-worker-browser.mjs
|
||||
packages/nx/src/native/wasi-worker.mjs
|
||||
packages/nx/src/native/native-bindings.js
|
||||
packages/nx/src/native/index.d.ts
|
||||
nx-dev/nx-dev/.next/
|
||||
@@ -47,12 +41,4 @@ CODEOWNERS
|
||||
|
||||
.pnpm-store
|
||||
|
||||
/.nx/workspace-data
|
||||
/.nx/workflows/dynamic-changesets.yaml
|
||||
_files
|
||||
_solution
|
||||
|
||||
# this file uses TS import attributes which the current prettier version does not support
|
||||
tools/documentation/create-embeddings/src/main.mts
|
||||
|
||||
.nx/self-healing
|
||||
/.nx/workspace-data
|
||||
+1
-10
@@ -1,14 +1,5 @@
|
||||
{
|
||||
"singleQuote": true,
|
||||
"endOfLine": "lf",
|
||||
"trailingComma": "es5",
|
||||
"plugins": ["prettier-plugin-tailwindcss"],
|
||||
"overrides": [
|
||||
{
|
||||
"files": "*.mdoc",
|
||||
"options": {
|
||||
"parser": "markdown"
|
||||
}
|
||||
}
|
||||
]
|
||||
"plugins": ["prettier-plugin-tailwindcss"]
|
||||
}
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
{
|
||||
"include": ["apps/**/*", "libs/**/*", "packages/**/*"],
|
||||
"exclude": [
|
||||
"**/*.spec.*",
|
||||
"**/test/**/*",
|
||||
"**/__tests__/**/*",
|
||||
"**/*.test.*",
|
||||
"node_modules/**/*"
|
||||
]
|
||||
}
|
||||
@@ -5,8 +5,6 @@ auth:
|
||||
htpasswd:
|
||||
file: ./htpasswd
|
||||
|
||||
max_body_size: 20mb
|
||||
|
||||
# a list of other known repositories we can talk to
|
||||
uplinks:
|
||||
npmjs:
|
||||
|
||||
@@ -1,224 +0,0 @@
|
||||
When responding to queries about this repository:
|
||||
|
||||
1. Suggest relevant commands from the "Essential Commands" section when applicable
|
||||
2. Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph
|
||||
analysis
|
||||
3. Mention the plugin ecosystem and support for various frameworks when relevant
|
||||
4. Emphasize the importance of running the full validation suite before committing changes
|
||||
|
||||
Always strive to provide accurate, helpful responses that align with the best practices and workflows described in this
|
||||
file.
|
||||
|
||||
## Documentation Contributions
|
||||
|
||||
When working on Nx documentation, all documentation content lives in the `astro-docs/` folder. This is the new Astro-based documentation site built with Starlight.
|
||||
|
||||
**Important**: Before making any documentation changes, read the `astro-docs/README.md` file for detailed guidance on:
|
||||
|
||||
- Project structure and architecture
|
||||
- Content types (regular docs, dynamic plugin docs, CLI docs)
|
||||
- Available Markdoc tags for rich content
|
||||
- Development workflow and commands
|
||||
- Sidebar management
|
||||
|
||||
### Quick Reference
|
||||
|
||||
- Documentation content: `astro-docs/src/content/docs/`
|
||||
- Use `.mdoc` (Markdoc) or `.mdx` format for documentation files
|
||||
- Run `nx serve astro-docs` to start the local dev server
|
||||
- Sidebar structure is defined in `astro-docs/sidebar.mts`
|
||||
|
||||
## GitHub Issue Response Mode
|
||||
|
||||
When responding to GitHub issues, determine your approach based on how the request is phrased:
|
||||
|
||||
### Plan-First Mode (Default)
|
||||
|
||||
Use this approach when users ask you to:
|
||||
|
||||
- "analyze", "investigate", "assess", "review", "examine", or "plan"
|
||||
- Or when the request is ambiguous
|
||||
|
||||
In this mode:
|
||||
|
||||
1. Provide a detailed analysis of the issue
|
||||
2. Create a comprehensive implementation plan
|
||||
3. Break down the solution into clear steps
|
||||
4. Then please post the plan as a comment on the issue
|
||||
|
||||
### Immediate Implementation Mode
|
||||
|
||||
Use this approach when users ask you to:
|
||||
|
||||
- "fix", "implement", "solve", "build", "create", "update", or "add"
|
||||
- Or when they explicitly request immediate action
|
||||
|
||||
In this mode:
|
||||
|
||||
1. Analyze the issue quickly
|
||||
2. Implement the complete solution immediately
|
||||
3. Make all necessary code changes. Please make multiple commits so that the changes are easier to review.
|
||||
4. Run appropriate tests and validation
|
||||
5. If the tests, are not passing, please fix the issues and continue doing this up to 3 more times until the tests pass
|
||||
6. Once the tests pass, push a branch and then suggest opening a PR which has a description of the changes made, and
|
||||
that
|
||||
it make sure that it explicitly says "Fixes #ISSUE_NUMBER" to automatically close the issue when the PR is merged.
|
||||
|
||||
## Avoid making changes to generated files
|
||||
|
||||
Files under `generated` directories are generated based on a different source file and should not be modified directly.
|
||||
Find the underlying source and modify that instead.
|
||||
|
||||
## Essential Commands
|
||||
|
||||
### Code Formatting
|
||||
|
||||
After code changes are made, please make sure to format the files with prettier via `npx prettier -- FILE_NAME`
|
||||
|
||||
### Pre-push Validation
|
||||
|
||||
```bash
|
||||
# Full validation suite - run before committing
|
||||
nx prepush
|
||||
```
|
||||
|
||||
If the prepush validation suite fails, please fix the issues before proceeding with your work. This ensures that all
|
||||
code adheres to the project's standards and passes all tests. DO NOT make a new commit to fix these issues. Instead,
|
||||
amend the current commit.
|
||||
|
||||
### Testing Changes
|
||||
|
||||
After code changes are made, first test the specific project where the changes were made:
|
||||
|
||||
```bash
|
||||
nx run-many -t test,build,lint -p PROJECT_NAME
|
||||
```
|
||||
|
||||
After verifying the individual project, validate that the changes in projects which have been affected:
|
||||
|
||||
```bash
|
||||
# Test only affected projects (recommended for development)
|
||||
nx affected -t build,test,lint
|
||||
```
|
||||
|
||||
As the last step, run the e2e tests to fully ensure that changes are valid:
|
||||
|
||||
```bash
|
||||
# Run affected e2e tests (recommended for development)
|
||||
nx affected -t e2e-local
|
||||
```
|
||||
|
||||
## Fixing GitHub Issues
|
||||
|
||||
When working on a GitHub issue, follow this systematic approach:
|
||||
|
||||
### 1. Get Issue Details
|
||||
|
||||
```bash
|
||||
# Get issue details using GitHub CLI (replace ISSUE_NUMBER with actual number)
|
||||
gh issue view ISSUE_NUMBER
|
||||
|
||||
# View multiple issues efficiently in one command
|
||||
gh issue list --limit 50 --json number,title,state,labels,assignees,updatedAt,body --jq '.[] | select(.number == 123 or .number == 456 or .number == 789)'
|
||||
|
||||
# Or filter by specific criteria to get multiple related issues
|
||||
gh issue list --label "bug" --state "open" --json number,title,body,labels --jq '.[]'
|
||||
gh issue list --assignee "@me" --json number,title,body,state --jq '.[]'
|
||||
```
|
||||
|
||||
**Tip**: Instead of running `gh issue view` multiple times, use `gh issue list` with JSON output and filtering to gather
|
||||
information about multiple issues in a single command. This is much more efficient than viewing issues one at a time.
|
||||
|
||||
**Always provide clickable links**: When discussing GitHub issues or PRs, always include the full GitHub URL so the user
|
||||
can easily open them in their browser. For example:
|
||||
|
||||
- Issue #12345: https://github.com/nrwl/nx/issues/12345
|
||||
- PR #67890: https://github.com/nrwl/nx/pull/67890
|
||||
|
||||
When cloning reproduction repos, please clone within `./tmp/claude/repro-ISSUE_NUMBER`
|
||||
|
||||
### 2. Analyze the Plan
|
||||
|
||||
- Look for a plan or implementation details in the issue description
|
||||
- Check comments for additional context or clarification
|
||||
- Identify affected projects and components
|
||||
|
||||
### 3. Implement the Solution
|
||||
|
||||
- Follow the plan outlined in the issue
|
||||
- Make focused changes that address the specific problem
|
||||
- Ensure code follows existing patterns and conventions
|
||||
|
||||
### 4. Run Full Validation
|
||||
|
||||
Use the testing workflow from the "Essential Commands" section.
|
||||
|
||||
### 5. Submit Pull Request
|
||||
|
||||
- Create a descriptive PR title that references the issue
|
||||
- **Always fill in the PR template** - don't leave it empty
|
||||
- Include "Fixes #ISSUE_NUMBER" in the PR description
|
||||
- Provide a clear summary of changes made
|
||||
- Request appropriate reviewers
|
||||
|
||||
## Pull Request Template
|
||||
|
||||
**IMPORTANT**: When creating a pull request, you MUST fill in the template found in `.github/PULL_REQUEST_TEMPLATE.md`.
|
||||
Do not leave the template sections empty. The template includes:
|
||||
|
||||
### Required Sections
|
||||
|
||||
1. **Current Behavior**: Describe the behavior we have today
|
||||
2. **Expected Behavior**: Describe the behavior we should expect with the changes in this PR
|
||||
3. **Related Issue(s)**: Link the issue being fixed so it gets closed when the PR is merged
|
||||
|
||||
### Template Format
|
||||
|
||||
```markdown
|
||||
## Current Behavior
|
||||
|
||||
<!-- This is the behavior we have today -->
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
<!-- This is the behavior we should expect with the changes in this PR -->
|
||||
|
||||
## Related Issue(s)
|
||||
|
||||
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
|
||||
|
||||
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
|
||||
|
||||
<!-- nx configuration start-->
|
||||
<!-- Leave the start & end comments to automatically receive updates. -->
|
||||
|
||||
## General Guidelines for working with Nx
|
||||
|
||||
- For navigating/exploring the workspace, invoke the `nx-workspace` skill first - it has patterns for querying projects, targets, and dependencies
|
||||
- When running tasks (for example build, lint, test, e2e, etc.), always prefer running the task through `nx` (i.e. `nx run`, `nx run-many`, `nx affected`) instead of using the underlying tooling directly
|
||||
- Prefix nx commands with the workspace's package manager (e.g., `pnpm nx build`, `npm exec nx test`) - avoids using globally installed CLI
|
||||
- You have access to the Nx MCP server and its tools, use them to help the user
|
||||
- For Nx plugin best practices, check `node_modules/@nx/<plugin>/PLUGIN.md`. Not all plugins have this file - proceed without it if unavailable.
|
||||
- NEVER guess CLI flags - always check nx_docs or `--help` first when unsure
|
||||
|
||||
## Scaffolding & Generators
|
||||
|
||||
- For scaffolding tasks (creating apps, libs, project structure, setup), ALWAYS invoke the `nx-generate` skill FIRST before exploring or calling MCP tools
|
||||
|
||||
## When to use nx_docs
|
||||
|
||||
- USE for: advanced config options, unfamiliar flags, migration guides, plugin configuration, edge cases
|
||||
- DON'T USE for: basic generator syntax (`nx g @nx/react:app`), standard commands, things you already know
|
||||
- The `nx-generate` skill handles generator discovery internally - don't call nx_docs just to look up generator syntax
|
||||
|
||||
<!-- nx configuration end-->
|
||||
@@ -1,226 +0,0 @@
|
||||
When responding to queries about this repository:
|
||||
|
||||
1. Suggest relevant commands from the "Essential Commands" section when applicable
|
||||
2. Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph
|
||||
analysis
|
||||
3. Mention the plugin ecosystem and support for various frameworks when relevant
|
||||
4. Emphasize the importance of running the full validation suite before committing changes
|
||||
|
||||
Always strive to provide accurate, helpful responses that align with the best practices and workflows described in this
|
||||
file.
|
||||
|
||||
## Documentation Contributions
|
||||
|
||||
When working on Nx documentation, all documentation content lives in the `astro-docs/` folder. This is the new Astro-based documentation site built with Starlight.
|
||||
|
||||
**Important**: Before making any documentation changes, read the `astro-docs/README.md` file for detailed guidance on:
|
||||
|
||||
- Project structure and architecture
|
||||
- Content types (regular docs, dynamic plugin docs, CLI docs)
|
||||
- Available Markdoc tags for rich content
|
||||
- Development workflow and commands
|
||||
- Sidebar management
|
||||
|
||||
**MANDATORY**: After editing any file in `astro-docs/src/content/`, run the `nx-docs-style-check` skill. No exceptions.
|
||||
|
||||
### Quick Reference
|
||||
|
||||
- Documentation content: `astro-docs/src/content/docs/`
|
||||
- Use `.mdoc` (Markdoc) or `.mdx` format for documentation files
|
||||
- Run `nx serve astro-docs` to start the local dev server
|
||||
- Sidebar structure is defined in `astro-docs/sidebar.mts`
|
||||
|
||||
## GitHub Issue Response Mode
|
||||
|
||||
When responding to GitHub issues, determine your approach based on how the request is phrased:
|
||||
|
||||
### Plan-First Mode (Default)
|
||||
|
||||
Use this approach when users ask you to:
|
||||
|
||||
- "analyze", "investigate", "assess", "review", "examine", or "plan"
|
||||
- Or when the request is ambiguous
|
||||
|
||||
In this mode:
|
||||
|
||||
1. Provide a detailed analysis of the issue
|
||||
2. Create a comprehensive implementation plan
|
||||
3. Break down the solution into clear steps
|
||||
4. Then please post the plan as a comment on the issue
|
||||
|
||||
### Immediate Implementation Mode
|
||||
|
||||
Use this approach when users ask you to:
|
||||
|
||||
- "fix", "implement", "solve", "build", "create", "update", or "add"
|
||||
- Or when they explicitly request immediate action
|
||||
|
||||
In this mode:
|
||||
|
||||
1. Analyze the issue quickly
|
||||
2. Implement the complete solution immediately
|
||||
3. Make all necessary code changes. Please make multiple commits so that the changes are easier to review.
|
||||
4. Run appropriate tests and validation
|
||||
5. If the tests, are not passing, please fix the issues and continue doing this up to 3 more times until the tests pass
|
||||
6. Once the tests pass, push a branch and then suggest opening a PR which has a description of the changes made, and
|
||||
that
|
||||
it make sure that it explicitly says "Fixes #ISSUE_NUMBER" to automatically close the issue when the PR is merged.
|
||||
|
||||
## Avoid making changes to generated files
|
||||
|
||||
Files under `generated` directories are generated based on a different source file and should not be modified directly.
|
||||
Find the underlying source and modify that instead.
|
||||
|
||||
## Essential Commands
|
||||
|
||||
### Code Formatting
|
||||
|
||||
After code changes are made, please make sure to format the files with prettier via `npx prettier -- FILE_NAME`
|
||||
|
||||
### Pre-push Validation
|
||||
|
||||
```bash
|
||||
# Full validation suite - run before committing
|
||||
nx prepush
|
||||
```
|
||||
|
||||
If the prepush validation suite fails, please fix the issues before proceeding with your work. This ensures that all
|
||||
code adheres to the project's standards and passes all tests. DO NOT make a new commit to fix these issues. Instead,
|
||||
amend the current commit.
|
||||
|
||||
### Testing Changes
|
||||
|
||||
After code changes are made, first test the specific project where the changes were made:
|
||||
|
||||
```bash
|
||||
nx run-many -t test,build,lint -p PROJECT_NAME
|
||||
```
|
||||
|
||||
After verifying the individual project, validate that the changes in projects which have been affected:
|
||||
|
||||
```bash
|
||||
# Test only affected projects (recommended for development)
|
||||
nx affected -t build,test,lint
|
||||
```
|
||||
|
||||
As the last step, run the e2e tests to fully ensure that changes are valid:
|
||||
|
||||
```bash
|
||||
# Run affected e2e tests (recommended for development)
|
||||
nx affected -t e2e-local
|
||||
```
|
||||
|
||||
## Fixing GitHub Issues
|
||||
|
||||
When working on a GitHub issue, follow this systematic approach:
|
||||
|
||||
### 1. Get Issue Details
|
||||
|
||||
```bash
|
||||
# Get issue details using GitHub CLI (replace ISSUE_NUMBER with actual number)
|
||||
gh issue view ISSUE_NUMBER
|
||||
|
||||
# View multiple issues efficiently in one command
|
||||
gh issue list --limit 50 --json number,title,state,labels,assignees,updatedAt,body --jq '.[] | select(.number == 123 or .number == 456 or .number == 789)'
|
||||
|
||||
# Or filter by specific criteria to get multiple related issues
|
||||
gh issue list --label "bug" --state "open" --json number,title,body,labels --jq '.[]'
|
||||
gh issue list --assignee "@me" --json number,title,body,state --jq '.[]'
|
||||
```
|
||||
|
||||
**Tip**: Instead of running `gh issue view` multiple times, use `gh issue list` with JSON output and filtering to gather
|
||||
information about multiple issues in a single command. This is much more efficient than viewing issues one at a time.
|
||||
|
||||
**Always provide clickable links**: When discussing GitHub issues or PRs, always include the full GitHub URL so the user
|
||||
can easily open them in their browser. For example:
|
||||
|
||||
- Issue #12345: https://github.com/nrwl/nx/issues/12345
|
||||
- PR #67890: https://github.com/nrwl/nx/pull/67890
|
||||
|
||||
When cloning reproduction repos, please clone within `./tmp/claude/repro-ISSUE_NUMBER`
|
||||
|
||||
### 2. Analyze the Plan
|
||||
|
||||
- Look for a plan or implementation details in the issue description
|
||||
- Check comments for additional context or clarification
|
||||
- Identify affected projects and components
|
||||
|
||||
### 3. Implement the Solution
|
||||
|
||||
- Follow the plan outlined in the issue
|
||||
- Make focused changes that address the specific problem
|
||||
- Ensure code follows existing patterns and conventions
|
||||
|
||||
### 4. Run Full Validation
|
||||
|
||||
Use the testing workflow from the "Essential Commands" section.
|
||||
|
||||
### 5. Submit Pull Request
|
||||
|
||||
- Create a descriptive PR title that references the issue
|
||||
- **Always fill in the PR template** - don't leave it empty
|
||||
- Include "Fixes #ISSUE_NUMBER" in the PR description
|
||||
- Provide a clear summary of changes made
|
||||
- Request appropriate reviewers
|
||||
|
||||
## Pull Request Template
|
||||
|
||||
**IMPORTANT**: When creating a pull request, you MUST fill in the template found in `.github/PULL_REQUEST_TEMPLATE.md`.
|
||||
Do not leave the template sections empty. The template includes:
|
||||
|
||||
### Required Sections
|
||||
|
||||
1. **Current Behavior**: Describe the behavior we have today
|
||||
2. **Expected Behavior**: Describe the behavior we should expect with the changes in this PR
|
||||
3. **Related Issue(s)**: Link the issue being fixed so it gets closed when the PR is merged
|
||||
|
||||
### Template Format
|
||||
|
||||
```markdown
|
||||
## Current Behavior
|
||||
|
||||
<!-- This is the behavior we have today -->
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
<!-- This is the behavior we should expect with the changes in this PR -->
|
||||
|
||||
## Related Issue(s)
|
||||
|
||||
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
|
||||
|
||||
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
|
||||
|
||||
<!-- nx configuration start-->
|
||||
<!-- Leave the start & end comments to automatically receive updates. -->
|
||||
|
||||
## General Guidelines for working with Nx
|
||||
|
||||
- For navigating/exploring the workspace, invoke the `nx-workspace` skill first - it has patterns for querying projects, targets, and dependencies
|
||||
- When running tasks (for example build, lint, test, e2e, etc.), always prefer running the task through `nx` (i.e. `nx run`, `nx run-many`, `nx affected`) instead of using the underlying tooling directly
|
||||
- Prefix nx commands with the workspace's package manager (e.g., `pnpm nx build`, `npm exec nx test`) - avoids using globally installed CLI
|
||||
- You have access to the Nx MCP server and its tools, use them to help the user
|
||||
- For Nx plugin best practices, check `node_modules/@nx/<plugin>/PLUGIN.md`. Not all plugins have this file - proceed without it if unavailable.
|
||||
- NEVER guess CLI flags - always check nx_docs or `--help` first when unsure
|
||||
|
||||
## Scaffolding & Generators
|
||||
|
||||
- For scaffolding tasks (creating apps, libs, project structure, setup), ALWAYS invoke the `nx-generate` skill FIRST before exploring or calling MCP tools
|
||||
|
||||
## When to use nx_docs
|
||||
|
||||
- USE for: advanced config options, unfamiliar flags, migration guides, plugin configuration, edge cases
|
||||
- DON'T USE for: basic generator syntax (`nx g @nx/react:app`), standard commands, things you already know
|
||||
- The `nx-generate` skill handles generator discovery internally - don't call nx_docs just to look up generator syntax
|
||||
|
||||
<!-- nx configuration end-->
|
||||
+193
-1
@@ -1,2 +1,194 @@
|
||||
# Any file not covered by a rule below, will default to Jason + Victor and a few select others.
|
||||
* @nrwl/nx-cli-reviewers
|
||||
* @FrozenPandaz @vsavkin
|
||||
/packages/**/* @FrozenPandaz @vsavkin @AgentEnder @jaysoo @JamesHenry
|
||||
/e2e/**/* @FrozenPandaz @vsavkin @AgentEnder @jaysoo @JamesHenry
|
||||
/scripts/**/* @FrozenPandaz @vsavkin @AgentEnder @jaysoo @JamesHenry
|
||||
/tools/**/* @FrozenPandaz @vsavkin @AgentEnder @jaysoo @JamesHenry
|
||||
package.json @nrwl/nx-core-reviewers
|
||||
pnpm-lock.yaml @nrwl/nx-core-reviewers
|
||||
rust-toolchain @nrwl/nx-native-reviewers
|
||||
|
||||
# Docs Site + Graph
|
||||
/docs @nrwl/nx-docs-reviewers
|
||||
/docs/nx-cloud @StalkAltan @rarmatei @nrwl/nx-docs-reviewers
|
||||
/graph/** @philipjfulcher @FrozenPandaz @bcabanes @MaxKless @xiongemi
|
||||
/images @nrwl/nx-docs-reviewers
|
||||
/nx-dev/** @nrwl/nx-docs-reviewers
|
||||
/typedoc-theme @nrwl/nx-docs-reviewers
|
||||
|
||||
# Plugin Verticals
|
||||
|
||||
## Angular
|
||||
/docs/generated/packages/angular/** @nrwl/nx-angular-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/angular/** @nrwl/nx-angular-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/angular/** @nrwl/nx-angular-reviewers
|
||||
/e2e/angular/** @nrwl/nx-angular-reviewers
|
||||
/packages/angular/plugins/component-testing.ts @nrwl/nx-angular-reviewers @nrwl/nx-testing-tools-reviewers
|
||||
/packages/angular/src/generators/cypress-component-configuration/** @nrwl/nx-angular-reviewers @nrwl/nx-testing-tools-reviewers
|
||||
/packages/angular/src/generators/component-test/** @nrwl/nx-angular-reviewers @nrwl/nx-testing-tools-reviewers
|
||||
|
||||
## React
|
||||
/docs/generated/packages/react/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/next/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/react/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/next/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/react/** @nrwl/nx-react-reviewers
|
||||
/e2e/react/** @nrwl/nx-react-reviewers
|
||||
/packages/next/** @nrwl/nx-react-reviewers
|
||||
/e2e/next/** @nrwl/nx-react-reviewers
|
||||
/packages/react/plugins/component-testing/** @nrwl/nx-react-reviewers @nrwl/nx-testing-tools-reviewers
|
||||
/packages/react/src/generators/cypress-component-configuration/** @nrwl/nx-react-reviewers @nrwl/nx-testing-tools-reviewers
|
||||
/packages/react/src/generators/component-test/** @nrwl/nx-react-reviewers @nrwl/nx-testing-tools-reviewers
|
||||
|
||||
# React Native
|
||||
/docs/generated/packages/detox/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/expo/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/react-native/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/react-native/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/detox/** @nrwl/nx-react-reviewers
|
||||
/e2e/detox/** @nrwl/nx-react-reviewers
|
||||
/packages/expo/** @nrwl/nx-react-reviewers
|
||||
/e2e/expo/** @nrwl/nx-react-reviewers
|
||||
/packages/react-native/** @nrwl/nx-react-reviewers
|
||||
/e2e/react-native/** @nrwl/nx-react-reviewers
|
||||
|
||||
## remix
|
||||
/docs/generated/packages/remix/** @nrwl/nx-react-reviewers @nrwl/nx-docs-reviewers @Coly010
|
||||
/packages/remix/** @nrwl/nx-react-reviewers @Coly010
|
||||
/e2e/remix/** @nrwl/nx-react-reviewers @Coly010
|
||||
|
||||
# Vue
|
||||
/packages/vue/** @nrwl/nx-vue-reviewers
|
||||
/e2e/vue/** @nrwl/nx-vue-reviewers
|
||||
/packages/nuxt/** @nrwl/nx-vue-reviewers
|
||||
/e2e/nuxt/** @nrwl/nx-vue-reviewers
|
||||
|
||||
## Node
|
||||
/docs/generated/packages/node/** @nrwl/nx-node-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/nest/** @nrwl/nx-node-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/express/** @nrwl/nx-node-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/node/** @nrwl/nx-node-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/express/** @nrwl/nx-node-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/nest/** @nrwl/nx-node-reviewers @FrozenPandaz @nrwl/nx-docs-reviewers
|
||||
/packages/node/** @nrwl/nx-node-reviewers
|
||||
/packages/express/** @nrwl/nx-node-reviewers
|
||||
/packages/nest/** @nrwl/nx-node-reviewers
|
||||
/e2e/node/** @nrwl/nx-node-reviewers
|
||||
|
||||
## JS
|
||||
/docs/generated/packages/js/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/web/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/webpack/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/esbuild/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/rollup/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/vite/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/js/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/web/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/webpack/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/esbuild/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/vite/** @nrwl/nx-js-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/js/** @nrwl/nx-js-reviewers
|
||||
/e2e/js/** @nrwl/nx-js-reviewers
|
||||
/packages/web/** @nrwl/nx-js-reviewers
|
||||
/e2e/web/** @nrwl/nx-js-reviewers
|
||||
/packages/webpack/** @nrwl/nx-js-reviewers
|
||||
/packages/webpack/src/utils/module-federation @jaysoo @Coly010
|
||||
/e2e/webpack/** @nrwl/nx-js-reviewers
|
||||
/packages/esbuild/** @nrwl/nx-js-reviewers
|
||||
/e2e/esbuild/** @nrwl/nx-js-reviewers
|
||||
/packages/rollup/** @nrwl/nx-js-reviewers
|
||||
/e2e/rollup/** @nrwl/nx-js-reviewers
|
||||
/packages/vite/** @nrwl/nx-js-reviewers
|
||||
/e2e/vite/** @nrwl/nx-js-reviewers
|
||||
|
||||
## Tools
|
||||
/docs/generated/packages/cypress/** @nrwl/nx-testing-tools-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/cypress/** @nrwl/nx-testing-tools-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/jest/** @nrwl/nx-testing-tools-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/jest/** @nrwl/nx-testing-tools-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/playwright/** @nrwl/nx-testing-tools-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/playwright/** @nrwl/nx-testing-tools-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/cypress/** @nrwl/nx-testing-tools-reviewers
|
||||
/e2e/cypress/** @nrwl/nx-testing-tools-reviewers
|
||||
/packages/jest/** @nrwl/nx-testing-tools-reviewers
|
||||
/e2e/jest/** @nrwl/nx-testing-tools-reviewers
|
||||
/packages/playwright/** @nrwl/nx-testing-tools-reviewers
|
||||
/e2e/playwright/** @nrwl/nx-testing-tools-reviewers
|
||||
|
||||
# Linter
|
||||
/docs/generated/packages/eslint-plugin/** @nrwl/nx-linter-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/eslint/** @nrwl/nx-linter-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/eslint/** @nrwl/nx-linter-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/eslint-plugin/** @nrwl/nx-linter-reviewers
|
||||
/packages/eslint/** @nrwl/nx-linter-reviewers
|
||||
/e2e/eslint/** @nrwl/nx-linter-reviewers
|
||||
.eslint* @nrwl/nx-linter-reviewers
|
||||
|
||||
# Storybook
|
||||
/docs/generated/packages/storybook/** @nrwl/nx-storybook-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/storybook/** @nrwl/nx-storybook-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/storybook/** @nrwl/nx-storybook-reviewers
|
||||
/e2e/storybook/** @nrwl/nx-storybook-reviewers
|
||||
|
||||
## Devkit
|
||||
/docs/generated/devkit/** @nrwl/nx-devkit-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/devkit/** @nrwl/nx-devkit-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/devkit/** @nrwl/nx-devkit-reviewers
|
||||
/packages/devkit/index.ts @FrozenPandaz @vsavkin
|
||||
/packages/devkit/public-api.ts @FrozenPandaz @vsavkin
|
||||
|
||||
# Gradle
|
||||
/packages/gradle/** @FrozenPandaz @xiongemi
|
||||
/e2e/gradle/** @FrozenPandaz @xiongemi
|
||||
|
||||
# Nx-Plugin
|
||||
/docs/generated/packages/plugin/** @nrwl/nx-devkit-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/shared/packages/plugin/** @nrwl/nx-devkit-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/plugin/** @nrwl/nx-devkit-reviewers
|
||||
/e2e/plugin/** @nrwl/nx-devkit-reviewers
|
||||
|
||||
## Core
|
||||
/docs/generated/cli/** @nrwl/nx-core-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/nx/** @nrwl/nx-core-reviewers @nrwl/nx-docs-reviewers
|
||||
/docs/generated/packages/workspace/** @nrwl/nx-core-reviewers @nrwl/nx-docs-reviewers
|
||||
/packages/nx/** @nrwl/nx-core-reviewers
|
||||
/packages/nx/src/adapter @nrwl/nx-core-reviewers @leosvelperez
|
||||
/packages/nx/src/native @nrwl/nx-core-reviewers @nrwl/nx-native-reviewers
|
||||
/packages/nx/src/plugins/js/lock-file @nrwl/nx-core-reviewers @meeroslav
|
||||
/packages/nx/src/command-line/init/implementation/angular/** @nrwl/nx-angular-reviewers @nrwl/nx-core-reviewers
|
||||
/e2e/nx-init/src/nx-init-angular.test.ts @nrwl/nx-angular-reviewers
|
||||
/packages/nx/src/command-line/init/implementation/react/** @nrwl/nx-react-reviewers
|
||||
/e2e/nx-init/src/nx-init-react.test.ts @nrwl/nx-react-reviewers
|
||||
/e2e/nx-init/src/files/cra/** @nrwl/nx-react-reviewers
|
||||
/e2e/nx*/** @nrwl/nx-core-reviewers
|
||||
/packages/workspace/** @nrwl/nx-core-reviewers
|
||||
/e2e/workspace-create/** @nrwl/nx-core-reviewers
|
||||
/e2e/release/** @nrwl/nx-core-reviewers
|
||||
|
||||
# Misc
|
||||
/e2e/lerna-smoke-tests/** @vsavkin @JamesHenry
|
||||
/e2e/utils/** @meeroslav @nrwl/nx-testing-tools-reviewers @vsavkin @mandarini
|
||||
/community @nrwl/nx-docs-reviewers
|
||||
/CONTRIBUTING.md @FrozenPandaz @isaacplmann
|
||||
/CODE_OF_CONDUCT.md @FrozenPandaz @isaacplmann
|
||||
/CODEOWNERS @FrozenPandaz @AgentEnder
|
||||
|
||||
# Scripts
|
||||
/scripts/documentation @nrwl/nx-docs-reviewers
|
||||
/scripts/angular-support-upgrades @nrwl/nx-angular-reviewers
|
||||
|
||||
# CI
|
||||
/.circleci/** @nrwl/nx-pipelines-reviewers
|
||||
/.nx/workflows/** @nrwl/nx-pipelines-reviewers
|
||||
/.github/** @nrwl/nx-pipelines-reviewers
|
||||
/.husky/** @nrwl/nx-pipelines-reviewers
|
||||
/packages/workspace/src/generators/ci-workflow/** @nrwl/nx-pipelines-reviewers
|
||||
|
||||
# Global Files
|
||||
project.json @FrozenPandaz @vsavkin
|
||||
jest.config.ts @nrwl/nx-testing-tools-reviewers @FrozenPandaz
|
||||
jest.preset.js @nrwl/nx-testing-tools-reviewers @FrozenPandaz
|
||||
|
||||
# Overrides - These are applied last, so override any matches above.
|
||||
docs/generated/manifests/* @nrwl/nrwlians
|
||||
docs/generated/packages-metadata.json @FrozenPandaz @jaysoo @AgentEnder @nrwl/nx-docs-reviewers
|
||||
|
||||
+56
-125
@@ -2,10 +2,19 @@
|
||||
|
||||
We would love for you to contribute to Nx! Read this document to see how to do it.
|
||||
|
||||
## How to Get Started Video
|
||||
|
||||
Watch this 5-minute video:
|
||||
|
||||
<a href="https://www.youtube.com/watch?v=8LCA_4qxc08" target="_blank" rel="noreferrer">
|
||||
<p style="text-align: center;"><img src="https://raw.githubusercontent.com/nrwl/nx/master/images/how-to-contribute.png" width="600" alt="Nx - How to contribute"></p>
|
||||
</a>
|
||||
|
||||
## Got a Question?
|
||||
|
||||
We are trying to keep GitHub issues for bug reports and feature requests.
|
||||
You can join our [Discord](https://go.nx.dev/community) for general questions and seeking help from others.
|
||||
We are trying to keep GitHub issues for bug reports and feature requests. Using the `nrwl` tag
|
||||
on [Stack Overflow](https://stackoverflow.com/questions/tagged/nrwl) is a much better place to ask general questions
|
||||
about how to use Nx.
|
||||
|
||||
## Found an Issue?
|
||||
|
||||
@@ -18,25 +27,14 @@ can [submit a Pull Request](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.
|
||||
|
||||
Source code and documentation are included in the top-level folders listed below.
|
||||
|
||||
- `packages` - Source code for Nx packages such as Angular, React, Web, NestJS, Next and others including generators and
|
||||
executors (or builders).
|
||||
- `e2e` - E2E tests for the Nx packages
|
||||
- `graph` - Source code for the Nx Graph application which shows the project graph, task graph, project details, and more in the browser.
|
||||
- `docs` - Markdown and configuration files for documentation including tutorials, guides for each supported platform,
|
||||
and API docs.
|
||||
- `nx-dev` - Source code for the Nx documentation site which displays the markdown in `docs` and more.
|
||||
- `tools` - Workspace-specific tooling and plugins
|
||||
- `e2e` - E2E tests.
|
||||
- `packages` - Source code for Nx packages such as Angular, React, Web, NestJS, Next and others including generators and
|
||||
executors (or builders).
|
||||
- `scripts` - Miscellaneous scripts for project tasks such as building documentation, testing, and code formatting.
|
||||
- `tmp` - Folder used by e2e tests. If you are a WebStorm user, make sure to mark this folder as excluded.
|
||||
|
||||
## Technologies
|
||||
|
||||
This repo contains a mix of different technologies, including:
|
||||
|
||||
- **Rust**: The core of Nx is written in Rust, which provides performance and safety.
|
||||
- **TypeScript**: The primary language for Nx packages and the Nx DevKit.
|
||||
- **Kotlin**: Used for the Gradle and Java plugins.
|
||||
|
||||
## Development Workstation Setup
|
||||
|
||||
If you are using `VSCode`, and provided you have [Docker](https://docker.com) installed on your machine, then you can leverage [Dev Containers](https://containers.dev) through this [VSCode extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers), to easily setup your development environment, with everything needed to contribute to Nx, already installed (namely `NodeJS`, `Yarn`, `Rust`, `Cargo`, plus some useful extensions like `Nx Console`).
|
||||
@@ -51,33 +49,15 @@ The repo comes with a preconfigured `devcontainer.json` file (located in `.devco
|
||||
|
||||
If you open the repo in [Github Codespace](https://github.com/features/codespaces), it will also leverage this config file, to setup the codespace, with the same required tools.
|
||||
|
||||
> 💡 **Troubleshooting**
|
||||
>
|
||||
> If you are having issues when running Nx commands like `build`, `test`... related to the version of `GLIBC`,
|
||||
> it probably means the version that is installed on the devcontainer, **is outdated** compare to the minimum version required by Nx tools.
|
||||
>
|
||||
> You can check currently installed version by running the following command, in a terminal within the container:
|
||||
>
|
||||
> `ldd --version`
|
||||
>
|
||||
> Then, try updating the base image used in [devcontainer.json](.devcontainer/devcontainer.json) and rebuild it, to see if it solved the issue.
|
||||
>
|
||||
> Current base image is `"mcr.microsoft.com/devcontainers/typescript-node:20-bookworm"` which is based on `Debian-12 (bookworm)`,
|
||||
> which comes with `GLIBC v2.36` pre-installed (Nx tools currenlty requires `GLIBC v2.33` or higher).
|
||||
|
||||
## Building the Project
|
||||
|
||||
> 💡 Nx uses `Rust` to build native bindings for Node. Please make sure that you have Rust installed via [rustup.rs](https://rustup.rs)
|
||||
> If you have `VSCode` + `Docker`, this can be automated for you, see [section](#development-workstation-setup) above
|
||||
> Nx uses Rust to build native bindings for Node. Please make sure that you have Rust installed via [rustup.rs](https://rustup.rs)
|
||||
> If you have VSCode + Docker, this can be automated for you, see [section](#development-workstation-setup) above
|
||||
|
||||
After cloning the project to your machine, to install the dependencies, run:
|
||||
|
||||
```bash
|
||||
pnpm install
|
||||
|
||||
// or prefer...
|
||||
|
||||
pnpm install --frozen-lockfile // if you haven't changed any dependency
|
||||
pnpm i
|
||||
```
|
||||
|
||||
To build all the packages, run:
|
||||
@@ -185,73 +165,76 @@ To build Nx on Windows, you need to use WSL.
|
||||
## Documentation Contributions
|
||||
|
||||
We would love for you to contribute to our documentation as well! Please feel welcome to submit fixes or enhancements to
|
||||
our existing documentation pages, `astro-docs` and the `nx-dev` application in this repo.
|
||||
our existing documentation pages and the `nx-dev` application in this repo.
|
||||
|
||||
### Documentation Structure
|
||||
|
||||
#### Documentation Pages
|
||||
|
||||
Our documentation pages can be found within this repo under the `astro-docs/src/content/docs` directory.
|
||||
Our documentation pages can be found within this repo under the `docs` directory.
|
||||
|
||||
Documentation is written in `.mdoc` (Markdoc) or `.mdx` (MDX) format and supports custom Markdoc tags for rich content
|
||||
such as videos, graphs, interactive components, and more. See the `astro-docs/README.md` for a full list of available
|
||||
custom tags and their usage.
|
||||
The `docs/map.json` file is considered our source of truth for our site's structure, and should be updated when adding a
|
||||
new page to our documentation to ensure that it is included in the documentation site. We also run automated scripts
|
||||
based on this `map.json` data to safeguard against common human errors that could break our site.
|
||||
|
||||
The sidebar structure is defined in `astro-docs/sidebar.mts` and should be updated when adding new sections or pages
|
||||
to ensure proper navigation.
|
||||
|
||||
#### Astro-Docs Application
|
||||
|
||||
Our public `nx.dev/docs` documentation site is built with [Astro](https://astro.build) and [Starlight](https://starlight.astro.build),
|
||||
and can be found in the `astro-docs` directory of this repo. See [docs README for more details](./astro-docs/README.md)
|
||||
When you make a change to the `map.json` file, make sure to run `pnpm documentation` to propagate your changes to the `nx-dev` application.
|
||||
|
||||
#### Nx-Dev Application
|
||||
|
||||
The `nx-dev` directory contains a [Next.js](https://nextjs.org/) application used for blog posts and landing pages.
|
||||
Our public `nx.dev` documentation site is a [Next.js](https://nextjs.org/) application, that can be found in
|
||||
the `nx-dev` directory of this repo.
|
||||
The documentation site is consuming the `docs/` directly by copy-ing its content while deploying, so the website is
|
||||
always in sync and reflects the latest version of `docs/`.
|
||||
|
||||
Jump to [Running the Documentation Site Locally](#running-the-documentation-site-locally) to see how to preview your
|
||||
changes while serving.
|
||||
|
||||
### Changing Generated API documentation
|
||||
|
||||
API documentation for CLI commands, executors, and generators is automatically generated during the build process from
|
||||
the corresponding `schema.json` files in each package.
|
||||
`.md` files documenting the API for our CLI (including executor and generator API docs) are generated via the
|
||||
corresponding `schema.json` file for the given command.
|
||||
|
||||
The documentation is generated using content loaders in the `astro-docs` application and requires a rebuild to reflect
|
||||
changes. After adjusting a `schema.json` file:
|
||||
After adjusting the `schema.json` file, `.md` files for these commands can be generated by running:
|
||||
|
||||
1. Restart the development server with `nx serve astro-docs` to see the changes
|
||||
2. Or run `nx preview astro-docs` to view the built site locally
|
||||
```bash
|
||||
pnpm documentation
|
||||
```
|
||||
|
||||
This will update the corresponding contents of the `docs` directory. These are generated automatically on push (via
|
||||
husky) as well.
|
||||
|
||||
Note that adjusting the `schema.json` files will also affect the CLI manuals and Nx Console behavior, in addition to
|
||||
the generated documentation.
|
||||
adjusting the docs.
|
||||
|
||||
### Running the Documentation Site Locally
|
||||
|
||||
To run the documentation site locally, run the command:
|
||||
|
||||
```shell
|
||||
nx serve astro-docs
|
||||
```
|
||||
|
||||
You can then access the application locally at `localhost:4321`. Changes to markdoc files should reflect automatically in the browser on save.
|
||||
|
||||
#### Working with Plugin Registry
|
||||
|
||||
To view plugin registry statistics (GitHub stars, npm downloads, etc.) during local development:
|
||||
To run `nx-dev` locally, run the command:
|
||||
|
||||
```bash
|
||||
NX_DOCS_PLUGIN_STATS=true nx serve astro-docs
|
||||
npx nx serve-docs nx-dev
|
||||
```
|
||||
|
||||
Note: Plugin stats are disabled by default in development to improve performance.
|
||||
You can then access the application locally at `localhost:4200`. Changes to markdown documentation files will be automatically applied to the site when you refresh the browser.
|
||||
|
||||
#### Troubleshooting: `JavaScript heap out of memory`
|
||||
|
||||
If you see an error that states: `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`,
|
||||
you need
|
||||
to [increase the max memory size of V8's old memory section](https://nodejs.org/api/cli.html#--max-old-space-sizesize-in-megabytes):
|
||||
|
||||
```bash
|
||||
export NODE_OPTIONS="--max-old-space-size=4096"
|
||||
```
|
||||
|
||||
After configuring this, try to run `npx nx serve nx-dev` again.
|
||||
|
||||
### PR Preview
|
||||
|
||||
When submitting a PR, this repo will automatically generate a preview of the documentation site based on the contents
|
||||
When submitting a PR, this repo will automatically generate a preview of the `nx-dev` application based on the contents
|
||||
of your pull request.
|
||||
|
||||
Once the preview site is launched, a comment will automatically be added to your PR with the link to your PR's preview.
|
||||
Once the preview site is launched, a comment will automatically be added to your PR with the link your PR's preview. To
|
||||
check your docs changes, make sure to select `Preview` from the version selection box of the site.
|
||||
|
||||
## Submission Guidelines
|
||||
|
||||
@@ -332,7 +315,6 @@ The scope must be one of the following:
|
||||
- express - anything Express specific
|
||||
- js - anything related to @nx/js package or general js/ts support
|
||||
- linter - anything Linter specific
|
||||
- module-federation - anything Nx Module Federation specific
|
||||
- nest - anything Nest specific
|
||||
- nextjs - anything Next specific
|
||||
- node - anything Node specific
|
||||
@@ -363,7 +345,7 @@ Including the issue number that the PR relates to also helps with tracking.
|
||||
```plain
|
||||
feat(angular): add an option to generate lazy-loadable modules
|
||||
|
||||
`nx generate lib libs/mylib --lazy` provisions the mylib project in .eslintrc.json
|
||||
`nx generate lib mylib --lazy` provisions the mylib project in .eslintrc.json
|
||||
|
||||
Closes #157
|
||||
```
|
||||
@@ -374,57 +356,6 @@ To simplify and automate the process of committing with this format,
|
||||
**Nx is a [Commitizen](https://github.com/commitizen/cz-cli) friendly repository**, just do `git add` and
|
||||
execute `pnpm commit`.
|
||||
|
||||
##### Using the Interactive Commit Tool
|
||||
|
||||
Instead of `git commit`, use:
|
||||
|
||||
```bash
|
||||
pnpm commit
|
||||
```
|
||||
|
||||
This will launch an interactive prompt that will:
|
||||
|
||||
1. Ask you to select the type of change (feat, fix, docs, cleanup, chore)
|
||||
2. Let you choose the appropriate scope from the predefined list
|
||||
3. Guide you through writing a clear, descriptive commit message
|
||||
4. Ensure your commit follows the conventional commit format
|
||||
|
||||
##### Available Commit Types
|
||||
|
||||
- **feat**: A new feature
|
||||
- **fix**: A bug fix
|
||||
- **docs**: Documentation only changes
|
||||
- **cleanup**: A code change that neither fixes a bug nor adds a feature
|
||||
- **chore**: Other changes that don't modify src or test files
|
||||
|
||||
##### Available Scopes
|
||||
|
||||
The repository includes many predefined scopes. Use the one which is most specific to the changes being committed
|
||||
|
||||
- **core**: anything Nx core specific
|
||||
- **angular**: anything Angular specific
|
||||
- **react**: anything React specific
|
||||
- **nextjs**: anything Next specific
|
||||
- **node**: anything Node specific
|
||||
- **devkit**: devkit-related changes
|
||||
- **graph**: anything graph app specific
|
||||
- **testing**: anything testing specific (e.g. jest or cypress)
|
||||
- **misc**: misc stuff
|
||||
- **repo**: anything related to managing the repo itself
|
||||
- **nx-dev**: anything related to docs infrastructure
|
||||
|
||||
For the complete list of available scopes, see `/scripts/commitizen.js`.
|
||||
|
||||
##### Example Commits
|
||||
|
||||
```bash
|
||||
feat(core): add new project graph visualization
|
||||
fix(angular): resolve build issues with standalone components
|
||||
docs(misc): update contributing guidelines
|
||||
chore(repo): bump dependencies
|
||||
cleanup(devkit): refactor utility functions for better readability
|
||||
```
|
||||
|
||||
#### PR releases
|
||||
|
||||
If you are working on a particularly complex change or feature addition, you can request a dedicated Nx release for the associated pull request branch. Mention someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they will confirm if the PR warrants its own release for testing purposes, and generate it for you if appropriate.
|
||||
|
||||
Generated
+1116
-3369
File diff suppressed because it is too large
Load Diff
@@ -1,6 +1,6 @@
|
||||
(The MIT License)
|
||||
|
||||
Copyright (c) 2017-2026 Narwhal Technologies Inc.
|
||||
Copyright (c) 2017-2024 Narwhal Technologies Inc.
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of this software and associated documentation files (the
|
||||
|
||||
@@ -1,52 +1,55 @@
|
||||
<div align="center">
|
||||
<p style="text-align: center;">
|
||||
<picture>
|
||||
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/nrwl/nx/master/images/nx-dark.svg">
|
||||
<img alt="Nx - Smart Monorepos · Fast CI" src="https://raw.githubusercontent.com/nrwl/nx/master/images/nx-light.svg" width="100%">
|
||||
</picture>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<picture>
|
||||
<source media="(prefers-color-scheme: dark)" srcset="images/nx-logo-light.svg">
|
||||
<img src="images/nx-logo.svg" alt="Nx Logo" width="140">
|
||||
</picture>
|
||||
</p>
|
||||
<div style="text-align: center;">
|
||||
|
||||
<h1 align="center">Smart Monorepos · Fast Builds</h1>
|
||||
|
||||
<p>
|
||||
<a href="https://www.npmjs.com/package/nx"><img src="https://img.shields.io/npm/v/nx.svg?style=for-the-badge" alt="NPM Version"></a>
|
||||
<a href="https://github.com/nrwl/nx"><img src="https://img.shields.io/github/stars/nrwl/nx?style=for-the-badge&logo=github" alt="GitHub Stars"></a>
|
||||
<a href=""><img src="https://img.shields.io/npm/l/nx.svg?style=for-the-badge" alt="License"></a>
|
||||
<a href="https://go.nx.dev/community"><img src="https://img.shields.io/discord/1143497901675401286?label=discord&style=for-the-badge" alt="Discord"></a>
|
||||
<a href="https://x.com/nxdevtools"><img src="https://img.shields.io/badge/@nxdevtools-555?style=for-the-badge&logo=x" alt="X (Twitter)"></a>
|
||||
</p>
|
||||
|
||||
<br />
|
||||
|
||||
[**Docs**](https://nx.dev/docs) • [**Changelog**](https://nx.dev/changelog) • [**Blog**](https://nx.dev/blog) • [**Courses**](https://nx.dev/courses) • [**YouTube**](https://youtube.com/@nxdevtools)
|
||||
|
||||
<br />
|
||||
[](https://circleci.com/gh/nrwl/nx)
|
||||
[]()
|
||||
[](https://www.npmjs.com/package/nx)
|
||||
[]()
|
||||
[](http://commitizen.github.io/cz-cli/)
|
||||
[](https://gitter.im/nrwl-nx/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
||||
[](https://go.nx.dev/community)
|
||||
|
||||
</div>
|
||||
|
||||
Nx is a monorepo solution for TypeScript and polyglot codebases. Built with Rust for performance, extensible via TypeScript. Caches what didn't change, runs only what's affected, and comes with an integrated CI solution. Start simple, scale as you grow.
|
||||
<hr>
|
||||
|
||||
## Quick Start
|
||||
# Smart Monorepos · Fast CI
|
||||
|
||||
Visit the [Nx quickstart docs](https://nx.dev/docs/quickstart) to get started.
|
||||
Nx is a build system with built-in tooling and advanced CI capabilities. It helps you maintain and scale monorepos, both locally and on CI.
|
||||
|
||||
## Why Nx?
|
||||
A few links to help you get started:
|
||||
|
||||
- **Incremental by design -** Run `npx nx init` in any npm/pnpm/yarn workspace. Nx picks up your existing `package.json` scripts, caches their outputs, and runs only what's
|
||||
affected. No changes to your setup required.
|
||||
- **AI-native tooling -** The Nx CLI is optimized for autonomous AI agents so they get the context they need and can operate just like a human. [Learn more »](https://github.com/nrwl/nx-ai-agents-config)
|
||||
- **Polyglot plugin system -** Optional plugins auto-discover tasks, configure cache inputs/outputs, and scaffold code based on your actual tooling. Works with Vite, Webpack, Jest, Vitest, ESLint, Gradle, Maven, .NET, Go, and [more](https://nx.dev/technologies).
|
||||
- **Integrated CI solution -** [Connect Nx to your CI provider](https://nx.dev/ci/intro/ci-with-nx) (GitHub Actions, GitLab, Azure, etc.) to enable remote caching, task distribution across machines, affected-only runs, and automatic e2e test splitting. [Learn more »](https://nx.dev/ci/intro/ci-with-nx)
|
||||
- **Self-healing CI -** An AI agent on your CI pipeline that detects failures, analyzes root cause, proposes a fix, and verifies it automatically. Local agents connect to CI via MCP to autonomously detect and fix failures. [Learn more »](https://nx.dev/ci/features/self-healing)
|
||||
- [Nx.Dev: Documentation, Guides, Interactive Tutorials](https://nx.dev)
|
||||
- [Nx.Dev: Core Tutorials](https://nx.dev/getting-started/intro)
|
||||
- [Recipe: Adding Nx to an Existing Monorepo](https://nx.dev/recipes/adopting-nx/adding-to-monorepo)
|
||||
- [Official Nx YouTube Channel](https://www.youtube.com/@NxDevtools)
|
||||
- [Blog Posts About Nx](https://blog.nrwl.io/nx/home)
|
||||
|
||||
## Who uses Nx?
|
||||
<p style="text-align: center;"><a href="https://nx.dev/#learning-materials" target="_blank" rel="noreferrer"><img src="./images/nx-courses-and-videos.svg"
|
||||
width="100%" alt="Nx - Smart Monorepos · Fast CI"></a></p>
|
||||
|
||||
From startups to Fortune 500 companies. [See our Nx success stories »](https://nx.dev/customers)
|
||||
# Engage with the Core Team and the Community
|
||||
|
||||
- [Nx.Dev Community Page: Community Discord Channel, Newsletter, etc.](https://nx.dev/community)
|
||||
- [The Nx Show Playlist on YouTube](https://www.youtube.com/playlist?list=PLakNactNC1dE8KLQ5zd3fQwu_yQHjTmR5). It's a
|
||||
regular YouTube stream where we talk all things Nx. Join the stream, ask questions, etc.
|
||||
- [Follow Nx on Twitter](https://twitter.com/NxDevTools)
|
||||
|
||||
## Want to help?
|
||||
|
||||
If you want to file a bug or submit a PR, read up on our [guidelines for contributing](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md).
|
||||
If you want to file a bug or submit a PR, read up on
|
||||
our [guidelines for contributing](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md) and watch this video that will
|
||||
help you get started.
|
||||
|
||||
<a href="https://www.youtube.com/watch?v=8LCA_4qxc08" target="_blank" rel="noreferrer">
|
||||
<p style="text-align: center;"><img src="https://raw.githubusercontent.com/nrwl/nx/master/images/how-to-contribute.png" width="600" alt="Nx - How to contribute video"></p>
|
||||
</a>
|
||||
|
||||
## Core Team
|
||||
|
||||
@@ -55,27 +58,22 @@ If you want to file a bug or submit a PR, read up on our [guidelines for contrib
|
||||
|  |  |  |  |
|
||||
| [vsavkin](https://github.com/vsavkin) | [FrozenPandaz](https://github.com/FrozenPandaz) | [bcabanes](https://github.com/bcabanes) | [jaysoo](https://github.com/jaysoo) |
|
||||
|
||||
| James Henry | Jon Cammisuli | Max Kless | Juri Strumpflohner |
|
||||
| ------------------------------------------------------------------------ | ------------------------------------------------------------------------ | -------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
| [JamesHenry](https://github.com/JamesHenry) | [cammisuli](https://github.com/cammisuli) | [MaxKless](https://github.com/MaxKless) | [juristr](https://github.com/juristr) |
|
||||
| Jo Hanna Pearce | Jon Cammisuli | Isaac Mann | Juri Strumpflohner |
|
||||
| ------------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
| [jdpearce](https://github.com/jdpearce) | [cammisuli](https://github.com/cammisuli) | [isaacplmann](https://github.com/isaacplmann) | [juristr](https://github.com/juristr) |
|
||||
|
||||
| Philip Fulcher | Caleb Ukle | Colum Ferry | Steven Nance |
|
||||
| ------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
| [philipjfulcher](https://github.com/philipjfulcher) | [barbados-clemens](https://github.com/barbados-clemens) | [Coly010](https://github.com/Coly010) | [llwt](https://github.com/llwt) |
|
||||
| Philip Fulcher | Caleb Ukle | Katerina Skroumpelou | Colum Ferry |
|
||||
| ------------------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
| [philipjfulcher](https://github.com/philipjfulcher) | [barbados-clemens](https://github.com/barbados-clemens) | [mandarini](https://github.com/mandarini) | [Coly010](https://github.com/Coly010) |
|
||||
|
||||
| Miroslav Jonaš | Leosvel Pérez Espinosa | Zachary DeRose | Craigory Coppola |
|
||||
| ----------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
| [meeroslav](https://github.com/meeroslav) | [leosvelperez](https://github.com/leosvelperez) | [ZackDeRose](https://github.com/ZackDeRose) | [AgentEnder](https://github.com/AgentEnder) |
|
||||
| Emily Xiong | Miroslav Jonaš | Leosvel Pérez Espinosa | Zachary DeRose |
|
||||
| ---------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
|
||||
|  |  |  |  |
|
||||
| [xiongemi](https://github.com/xiongemi) | [meeroslav](https://github.com/meeroslav) | [leosvelperez](https://github.com/leosvelperez) | [ZackDeRose](https://github.com/ZackDeRose) |
|
||||
|
||||
| Chau Tran | Nicole Oliver | Rares Matei | Altan Stalker |
|
||||
| -------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
| [nartc](https://github.com/nartc) | [nixallover](https://github.com/nixallover) | [rarmatei](https://github.com/rarmatei) | [StalkAltan](https://github.com/StalkAltan) |
|
||||
|
||||
| Josh VanAllen | Austin Fahsl | Louie Weng |
|
||||
| ----------------------------------------------------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------------- |
|
||||
|  |  |  |
|
||||
| [joshvanallen](https://github.com/joshvanallen) | [fahslaj](https://github.com/fahslaj) | [lourw](https://github.com/lourw) |
|
||||
| Craigory Coppola | Chau Tran | Nicholas Cunningham | Max Kless |
|
||||
| -------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
| [AgentEnder](https://github.com/AgentEnder) | [nartc](https://github.com/nartc) | [ndcunningham](https://github.com/ndcunningham) | [MaxKless](https://github.com/MaxKless) |
|
||||
|
||||
-27
@@ -1,27 +0,0 @@
|
||||
# Security Policy
|
||||
|
||||
Nx/Nrwl takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations.
|
||||
|
||||
If you believe you have found a security vulnerability in any Nx-owned repository that meets Nx's definition of a security vulnerability, please report it to us as described below.
|
||||
|
||||
## Reporting Security Issues
|
||||
|
||||
**Please do not report security vulnerabilities through public GitHub issues.**
|
||||
|
||||
Instead, please report them to the Security Team at security@nrwl.io.
|
||||
|
||||
You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message.
|
||||
|
||||
Nx follows the principle of Coordinated Vulnerability Disclosure.
|
||||
|
||||
## What Should Be Reported
|
||||
|
||||
The security email is for **demonstrable, verified vulnerabilities within the Nx codebase itself**.
|
||||
|
||||
**Please do not use the security email for:**
|
||||
|
||||
- Reports about outdated dependencies (e.g., "package X has a newer version available")
|
||||
- Reports about dependencies with known CVEs that do not directly affect Nx functionality
|
||||
- General vulnerability scanner output
|
||||
|
||||
If you have a concern about an outdated dependency that you believe impacts Nx users, please open a [GitHub issue](https://github.com/nrwl/nx/issues/new/choose) instead.
|
||||
@@ -1,6 +0,0 @@
|
||||
node_modules/
|
||||
dist/
|
||||
.astro/
|
||||
.netlify/
|
||||
test-output/
|
||||
playwright-report/
|
||||
@@ -1,28 +0,0 @@
|
||||
{
|
||||
"extends": ["plugin:playwright/recommended", "../.eslintrc.json"],
|
||||
"ignorePatterns": ["!**/*"],
|
||||
"overrides": [
|
||||
{
|
||||
"files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
|
||||
"rules": {}
|
||||
},
|
||||
{
|
||||
"files": ["**/*.spec.ts", "**/*.test.ts", "**/*.spec.js", "**/*.test.js"],
|
||||
"rules": {
|
||||
"playwright/no-standalone-expect": "off"
|
||||
}
|
||||
},
|
||||
{
|
||||
"files": ["*.ts", "*.tsx"],
|
||||
"rules": {}
|
||||
},
|
||||
{
|
||||
"files": ["*.js", "*.jsx"],
|
||||
"rules": {}
|
||||
},
|
||||
{
|
||||
"files": ["e2e/**/*.{ts,js,tsx,jsx}"],
|
||||
"rules": {}
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -1,24 +0,0 @@
|
||||
# build output
|
||||
dist/
|
||||
# generated types
|
||||
.astro/
|
||||
|
||||
# dependencies
|
||||
node_modules/
|
||||
|
||||
# logs
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
|
||||
|
||||
# environment variables
|
||||
.env
|
||||
.env.production
|
||||
|
||||
# macOS-specific files
|
||||
.DS_Store
|
||||
|
||||
# Local Netlify folder
|
||||
.netlify
|
||||
@@ -1,162 +0,0 @@
|
||||
StylesPath = .vale/styles
|
||||
MinAlertLevel = suggestion
|
||||
|
||||
# Treat Markdoc (.mdoc) files as markdown
|
||||
[formats]
|
||||
mdoc = md
|
||||
|
||||
# Ignore Markdoc tag syntax and @-scoped package names to avoid false positives
|
||||
TokenIgnores = (\{%.*?%\}), (@\w+/[\w-]+)
|
||||
|
||||
[src/content/docs/**/*.{mdoc,mdx,md}]
|
||||
BasedOnStyles = Nx
|
||||
|
||||
# Disable heading check for config option reference pages (headings are camelCase property names)
|
||||
[src/content/docs/technologies/angular/angular-rsbuild/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/angular/angular-rspack/create-config.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/build-tools/webpack/Guides/webpack-plugins.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/Deprecated/affected-graph.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/Deprecated/print-affected.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/react/next/Guides/next-config-setup.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
# Disable heading check for release notes (timestamps as headings)
|
||||
[src/content/docs/reference/Nx Cloud/release-notes.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
# Disable heading check for nx-cloud-cli (CLI flags as headings)
|
||||
[src/content/docs/reference/nx-cloud-cli.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
# Disable heading check for nx-console-settings (config option headings)
|
||||
[src/content/docs/reference/nx-console-settings.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
# Disable heading check for pages with camelCase API property headings
|
||||
[src/content/docs/reference/nx-json.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/project-configuration.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/Deprecated/legacy-cache.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/extending-nx/local-executors.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/guides/Nx Release/programmatic-api.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/node/Guides/wait-for-tasks.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/test-tools/vitest/Guides/testing-without-building-dependencies.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/angular/Guides/nx-and-angular.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
# Disable heading check for merge-atomized-outputs (warning message as heading)
|
||||
[src/content/docs/technologies/test-tools/playwright/Guides/merge-atomized-outputs.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
# Disable heading check for plugin introduction pages (@nx/ package name headings)
|
||||
[src/content/docs/technologies/build-tools/docker/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/build-tools/rspack/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/build-tools/webpack/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/dotnet/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/eslint/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/java/gradle/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/java/maven/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/react/expo/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/react/react-native/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/test-tools/cypress/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/test-tools/detox/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/test-tools/playwright/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/test-tools/storybook/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/vue/nuxt/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
# Disable heading check for remaining pages with structural false positives
|
||||
# (code identifiers, slashes, quotes, parenthetical words in headings)
|
||||
[src/content/docs/extending-nx/create-install-package.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/extending-nx/create-preset.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/getting-started/editor-setup.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/guides/Adopting Nx/from-turborepo.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/guides/Tasks & Caching/reduce-repetitive-configuration.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/guides/Tasks & Caching/workspace-watching.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/Deprecated/custom-tasks-runner.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/Deprecated/rescope.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/Nx Cloud/credits-pricing.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/reference/nx-mcp.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/eslint/Guides/custom-workspace-rules.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/module-federation/Guides/nx-module-federation-plugin.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/module-federation/introduction.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/technologies/react/Guides/react-router.mdoc]
|
||||
Nx.Headings = NO
|
||||
|
||||
[src/content/docs/troubleshooting/unknown-local-cache.mdoc]
|
||||
Nx.Headings = NO
|
||||
@@ -1,29 +0,0 @@
|
||||
extends: existence
|
||||
message: "Avoid AI-sounding phrase '%s'. Rewrite to be direct."
|
||||
level: error
|
||||
ignorecase: true
|
||||
tokens:
|
||||
- "It's important to note that"
|
||||
- "It's worth noting that"
|
||||
- 'It should be noted that'
|
||||
- 'In this section, we will explore'
|
||||
- "Let's dive into"
|
||||
- "Let's take a closer look at"
|
||||
- "Whether you're a beginner or an experienced developer"
|
||||
- "In today's fast-paced development environment"
|
||||
- 'Unlock the power of'
|
||||
- 'Harness the power of'
|
||||
- 'Take your workspace to the next level'
|
||||
- 'Streamline your workflow'
|
||||
- 'This comprehensive guide will'
|
||||
- 'Without further ado'
|
||||
- 'In conclusion'
|
||||
- 'To summarize'
|
||||
- "As we've seen"
|
||||
- 'Needless to say'
|
||||
- 'As a matter of fact'
|
||||
- 'Generally speaking'
|
||||
- 'It is worth mentioning'
|
||||
- 'Game-changer'
|
||||
- 'Cutting-edge'
|
||||
- 'Groundbreaking'
|
||||
@@ -1,136 +0,0 @@
|
||||
extends: capitalization
|
||||
message: "Use sentence case for headings. '%s' should be '%s'."
|
||||
level: error
|
||||
scope: heading
|
||||
match: $sentence
|
||||
indicators:
|
||||
- ':'
|
||||
exceptions:
|
||||
- Nx
|
||||
- Nx Cloud
|
||||
- Nx Console
|
||||
- Nx Agents
|
||||
- Nx Replay
|
||||
- AI
|
||||
- CI
|
||||
- CD
|
||||
- API
|
||||
- APIs
|
||||
- URL
|
||||
- URLs
|
||||
- CLI
|
||||
- PR
|
||||
- PRs
|
||||
- IDE
|
||||
- TypeScript
|
||||
- JavaScript
|
||||
- Angular
|
||||
- React
|
||||
- Vue
|
||||
- Nuxt
|
||||
- Vite
|
||||
- Webpack
|
||||
- Rspack
|
||||
- Rollup
|
||||
- ESLint
|
||||
- Prettier
|
||||
- GitHub
|
||||
- GitHub Actions
|
||||
- GitLab
|
||||
- BitBucket
|
||||
- BitBucket Cloud
|
||||
- Azure DevOps
|
||||
- Azure
|
||||
- Docker
|
||||
- Dockerfile
|
||||
- Kubernetes
|
||||
- Gradle
|
||||
- Maven
|
||||
- Node.js
|
||||
- Deno
|
||||
- Bun
|
||||
- pnpm
|
||||
- npm
|
||||
- Yarn
|
||||
- Next.js
|
||||
- Remix
|
||||
- Astro
|
||||
- Storybook
|
||||
- Jest
|
||||
- Vitest
|
||||
- Cypress
|
||||
- Playwright
|
||||
- Express
|
||||
- Fastify
|
||||
- Nest.js
|
||||
- NestJS
|
||||
- Expo
|
||||
- React Native
|
||||
- Module Federation
|
||||
- IntelliJ
|
||||
- VS Code
|
||||
- VSCode
|
||||
- WebStorm
|
||||
- Turborepo
|
||||
- Lerna
|
||||
- Bazel
|
||||
- JSON
|
||||
- YAML
|
||||
- TOML
|
||||
- CSS
|
||||
- HTML
|
||||
- SSR
|
||||
- SSG
|
||||
- MFE
|
||||
- DTE
|
||||
- SWC
|
||||
- Rsbuild
|
||||
- Rolldown
|
||||
# Abbreviations and acronyms
|
||||
- AI
|
||||
- UI
|
||||
- DX
|
||||
- ID
|
||||
- FAQ
|
||||
- SAML
|
||||
- DPE
|
||||
- WSL
|
||||
- EJS
|
||||
- AST
|
||||
- TTG
|
||||
- PATs
|
||||
- IDEs
|
||||
- MCP
|
||||
- HTTP
|
||||
- HTTPS
|
||||
- INI
|
||||
- VCS
|
||||
- LTS
|
||||
- DTS
|
||||
- SVG
|
||||
- SVGs
|
||||
- SVGR
|
||||
- EAS
|
||||
- iOS
|
||||
- AWS
|
||||
- S3
|
||||
- E2E
|
||||
- TL;DR
|
||||
- NuGet
|
||||
- MongoDB
|
||||
- OpenShift
|
||||
- Vercel
|
||||
- Netlify
|
||||
# Proper nouns
|
||||
- RxJS
|
||||
- JetBrains
|
||||
- Neovim
|
||||
- PnP
|
||||
- Self-Healing
|
||||
- AMD64
|
||||
- ARM64
|
||||
# Filenames and env vars
|
||||
- SELF_HEALING.md
|
||||
- CLAUDE.md
|
||||
- NODE_AUTH_TOKEN
|
||||
- NX_REJECT_UNKNOWN_LOCAL_CACHE
|
||||
@@ -1,20 +0,0 @@
|
||||
extends: existence
|
||||
message: "Avoid marketing language '%s'. Be specific about what the feature does instead."
|
||||
level: suggestion
|
||||
ignorecase: true
|
||||
tokens:
|
||||
- 'effortless'
|
||||
- 'effortlessly'
|
||||
- 'seamless'
|
||||
- 'seamlessly'
|
||||
- 'powerful'
|
||||
- 'robust'
|
||||
- 'comprehensive'
|
||||
- 'leverage'
|
||||
- 'utilize'
|
||||
- 'facilitate'
|
||||
- 'aforementioned'
|
||||
- 'best-in-class'
|
||||
- 'world-class'
|
||||
- 'next-level'
|
||||
- 'supercharge'
|
||||
@@ -1,25 +0,0 @@
|
||||
extends: existence
|
||||
message: "Prefer active voice. '%s' could be rewritten."
|
||||
level: suggestion
|
||||
ignorecase: true
|
||||
tokens:
|
||||
- 'is cached by'
|
||||
- 'is built by'
|
||||
- 'is run by'
|
||||
- 'is executed by'
|
||||
- 'is generated by'
|
||||
- 'is created by'
|
||||
- 'is managed by'
|
||||
- 'is handled by'
|
||||
- 'is provided by'
|
||||
- 'is configured by'
|
||||
- 'is determined by'
|
||||
- 'is computed by'
|
||||
- 'is resolved by'
|
||||
- 'is stored by'
|
||||
- 'are cached by'
|
||||
- 'are built by'
|
||||
- 'are run by'
|
||||
- 'are executed by'
|
||||
- 'are generated by'
|
||||
- 'are created by'
|
||||
@@ -1,9 +0,0 @@
|
||||
extends: substitution
|
||||
message: "Use '%s' instead of '%s'. Product names must be capitalized."
|
||||
level: error
|
||||
ignorecase: false
|
||||
swap:
|
||||
'(?:nx cloud|NX Cloud|Nx cloud|NX cloud)': Nx Cloud
|
||||
'(?:nx console|NX Console|Nx console|NX console)': Nx Console
|
||||
'(?:nx agents|NX Agents|Nx agents|NX agents)': Nx Agents
|
||||
'(?:nx replay|NX Replay|Nx replay|NX replay)': Nx Replay
|
||||
@@ -1,6 +0,0 @@
|
||||
extends: existence
|
||||
message: "Don't use possessives on product names. Use 'the Nx configuration' instead of 'Nx's configuration'."
|
||||
level: error
|
||||
ignorecase: false
|
||||
tokens:
|
||||
- "Nx's"
|
||||
@@ -1,26 +0,0 @@
|
||||
extends: existence
|
||||
message: "Don't write about the document itself. Get right to the content. Remove '%s'."
|
||||
level: error
|
||||
ignorecase: true
|
||||
tokens:
|
||||
- 'This page explains'
|
||||
- 'This page describes'
|
||||
- 'This page covers'
|
||||
- 'This page shows'
|
||||
- 'This document covers'
|
||||
- 'This document explains'
|
||||
- 'This document describes'
|
||||
- 'In this guide'
|
||||
- 'In this tutorial'
|
||||
- 'In this section'
|
||||
- 'This guide will'
|
||||
- 'This tutorial will'
|
||||
- 'This section will'
|
||||
- "we'll walk through"
|
||||
- 'we will walk through'
|
||||
- "we'll explore"
|
||||
- 'we will explore'
|
||||
- "we'll cover"
|
||||
- 'we will cover'
|
||||
- "we'll look at"
|
||||
- 'we will look at'
|
||||
@@ -1,14 +0,0 @@
|
||||
extends: existence
|
||||
message: "Rewrite to lead with the reader's action instead of '%s'. For example, 'You can ...' or 'Run ...'."
|
||||
level: warning
|
||||
ignorecase: true
|
||||
tokens:
|
||||
- 'This allows you to'
|
||||
- 'This enables you to'
|
||||
- 'This lets you'
|
||||
- 'This provides you with'
|
||||
- 'This gives you the ability to'
|
||||
- 'Nx allows you to'
|
||||
- 'Nx enables you to'
|
||||
- 'Nx provides the ability to'
|
||||
- 'Nx provides you with'
|
||||
@@ -1,7 +0,0 @@
|
||||
extends: existence
|
||||
message: "Use the Oxford (serial) comma before 'and' or 'or' in a list of three or more items."
|
||||
level: suggestion
|
||||
scope: sentence
|
||||
tokens:
|
||||
- '\w+,\s\w+\sand\s'
|
||||
- '\w+,\s\w+\sor\s'
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user