|
37 | 37 | LogInputSchema, |
38 | 38 | LogOutputSchema, |
39 | 39 | Task, |
| 40 | + BackportData, |
| 41 | + ErrorData, |
40 | 42 | ) |
41 | 43 | from common.utils import redis_client, fix_await |
42 | 44 | from constants import I_AM_JOTNAR, CAREFULLY_REVIEW_CHANGES |
|
68 | 70 | GitPatchCreationTool, |
69 | 71 | GitPreparePackageSources, |
70 | 72 | ) |
71 | | -from triage_agent import BackportData, ErrorData |
72 | 73 | from utils import ( |
73 | 74 | check_subprocess, |
74 | 75 | get_agent_execution_config, |
@@ -313,11 +314,13 @@ def get_fix_build_error_prompt() -> str: |
313 | 314 |
|
314 | 315 | The package built successfully before your patches were added - the spec file and build configuration are correct. |
315 | 316 | Your task is to fix this build error by improving the patches - NOT by modifying the spec file. |
| 317 | + This includes BOTH compilation errors AND test failures during the check section. |
316 | 318 | Make ONE attempt to fix the issue - you will be called again if the build still fails. |
317 | 319 |
|
318 | 320 | Follow these steps: |
319 | 321 |
|
320 | 322 | STEP 1: Analyze the build error |
| 323 | + - Identify if it's a compilation error (undefined symbols, headers) or test failure (in check section) |
321 | 324 | - Identify what's missing: undefined functions, types, macros, symbols, headers, or API changes |
322 | 325 | - Look for patterns like "undefined reference", "implicit declaration", "undeclared identifier", etc. |
323 | 326 | - Note the specific names of missing symbols |
@@ -366,6 +369,13 @@ def get_fix_build_error_prompt() -> str: |
366 | 369 | - Cherry-pick some commits, then manually adapt code where needed |
367 | 370 | - Use the upstream repo as a reference while writing your own backport |
368 | 371 |
|
| 372 | + SPECIAL CONSIDERATIONS FOR TEST FAILURES: |
| 373 | + - Tests validate the fix - they MUST pass |
| 374 | + - If tests use missing functions/helpers: backport ONLY the minimal necessary test helpers |
| 375 | + (search upstream history for test utility commits and cherry-pick or manually add them) |
| 376 | + - If tests fail due to API changes: adapt test code to work with older APIs |
| 377 | + - NEVER skip or disable tests - fix them instead |
| 378 | +
|
369 | 379 | STEP 4: Regenerate the patch |
370 | 380 | - After making your fixes (cherry-picked or manual), regenerate the patch file |
371 | 381 | - Use `generate_patch_from_commit` tool with the PATCHED_BASE commit |
@@ -401,10 +411,11 @@ def get_fix_build_error_prompt() -> str: |
401 | 411 | - Work in the EXISTING {{local_clone}}-upstream directory (don't clone again) |
402 | 412 | - NEVER modify the spec file - build failures are caused by incomplete patches, not spec issues |
403 | 413 | - The ONLY dist-git file you can modify is {{jira_issue}}.patch (by regenerating it from upstream repo) |
404 | | - - Fix build errors by adding missing prerequisites/dependencies to your patches in upstream repo |
| 414 | + - Fix build errors (compilation AND test failures) by adding missing prerequisites/dependencies to your patches in upstream repo |
| 415 | + - For test failures: backport minimal necessary test helpers/functions to make tests pass |
405 | 416 | - You can freely explore, edit, cherry-pick, and commit in the upstream repo - it's your workspace |
406 | 417 | - Use the upstream repo as a rich source of information and examples |
407 | | - - Be creative and pragmatic - the goal is a working build, not perfect git history |
| 418 | + - Be creative and pragmatic - the goal is a working build with passing tests, not perfect git history |
408 | 419 | - Make ONE solid attempt to fix the issue - if the build fails, report the error clearly |
409 | 420 | - Your work will persist in the upstream repo for the next attempt if needed |
410 | 421 |
|
|
0 commit comments