[Self-Heal] Add self-scheduling auto-repair workflow#43
Conversation
Adds automated self-repair pipeline configured to safely resolve common build/drift issues (like formatting, snapshots). It computes its own schedule from project velocity via telemetry data, checks for secrets before patching, and creates PRs rather than directly merging. Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces an automated self-healing CI pipeline, including documentation, dynamic scheduling based on repository telemetry, and scripts for health checks and automated repairs. Feedback highlights critical issues with non-existent dependency versions for ESLint and Prettier in package.json, an inverted cron expression in the schedule computation script, and the use of a deprecated ESLint flag. Additionally, the reviewer suggested avoiding non-zero exit codes when the system is healthy to prevent false-positive CI failures and unnecessary noise in the action history.
| "@types/which": "^3.0.4", | ||
| "@vitest/coverage-v8": "3.1.1", | ||
| "esbuild": "^0.25.2", | ||
| "eslint": "^10.4.0", |
There was a problem hiding this comment.
The version ^10.4.0 for eslint does not exist in the public npm registry. The current stable major version is 9. This will cause npm install or npm ci to fail.
| "eslint": "^10.4.0", | |
| "eslint": "^9.14.0", |
| "js-yaml": "^4.1.1", | ||
| "multer": "1.4.5-lts.1", | ||
| "openai": "^4.91.1", | ||
| "prettier": "^3.8.3", |
There was a problem hiding this comment.
The version ^3.8.3 for prettier does not exist in the public npm registry. The current latest stable version is 3.3.3. This will cause npm install or npm ci to fail.
| "prettier": "^3.8.3", | |
| "prettier": "^3.3.3", |
| } | ||
|
|
||
| function computeSchedule(telemetry, activeHourOffset) { | ||
| let scheduleStr = `${activeHourOffset} 0 * * *`; |
There was a problem hiding this comment.
The cron expression logic here is inverted. In a standard cron expression, the first field is minutes and the second is hours. Using ${activeHourOffset} 0 results in 'at minute X of hour 0', which contradicts the rationale 'daily at X UTC' and the fallback logic at line 86.
| let scheduleStr = `${activeHourOffset} 0 * * *`; | |
| let scheduleStr = `0 ${activeHourOffset} * * *`; |
|
|
||
| // Check 2: Linting | ||
| // Run eslint if available in package.json devDependencies | ||
| allPassed = runCheck('npx eslint . --ext .ts,.js,.mjs', 'ESLint') && allPassed; |
There was a problem hiding this comment.
The --ext flag was removed in ESLint 9.0.0. Since the project is targeting a modern version of ESLint (specified as ^10.4.0 in package.json), this command will fail. Modern ESLint automatically handles file extensions based on the configuration file.
| allPassed = runCheck('npx eslint . --ext .ts,.js,.mjs', 'ESLint') && allPassed; | |
| allPassed = runCheck('npx eslint .', 'ESLint') && allPassed; |
|
|
||
| if (isHealthy && !modified) { | ||
| console.log("Pipeline completed. System is healthy and no drift detected. Exiting cleanly with non-zero code to block PR."); | ||
| process.exit(1); |
There was a problem hiding this comment.
Exiting with a non-zero code (1) when the system is healthy and no drift is detected will cause the GitHub Action run to be marked as 'Failed' (Red X). This is generally considered poor practice for scheduled maintenance tasks as it creates noise in the action history. It is better to exit with 0 and use a conditional check in the workflow (e.g., checking for git changes) to decide whether to proceed with PR creation.
1 participant
[Self-Heal] Add self-scheduling auto-repair workflow
This PR introduces an automated self-healing CI pipeline configured via GitHub Actions.
The Repair Pipeline (Idempotent)
The
scripts/self_heal.mjsscript performs the following idempotent steps:npm cieslint --fixandprettier -wvitest run -uSchedule Dynamics
The schedule is dynamically computed based on PR merge velocity. High-velocity periods increase runs (up to 6 hours), while low periods scale down to weekly.
Checklists
yaml.dumpprevents configuration drift corruption.See
SELF_HEAL_SETUP.mdfor full instructions.(Generated by Claude Code / Jules coding agent)
PR created automatically by Jules for task 12931954551745270157 started by @badMade