19 ਦਸੰ 2025·6 ਮਿੰਟ
CI ਫੇਲ੍ਹਾਂ ਲਈ Claude Code: ਛੋਟੇ ਫਿਕਸ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਸ
Claude Code for CI failures: ਲਾਗ ਨੂੰ quote ਕਰੋ, ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ ਸੁਝਾਓ, ਅਤੇ ਦੁਹਰਾਅ ਰੋਕਣ ਲਈ regression ਟੈਸਟ ਜੋੜੋ।
Claude Code for CI failures: ਲਾਗ ਨੂੰ quote ਕਰੋ, ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ ਸੁਝਾਓ, ਅਤੇ ਦੁਹਰਾਅ ਰੋਕਣ ਲਈ regression ਟੈਸਟ ਜੋੜੋ।
CI ਫੇਲ੍ਹ ਆਮ ਤੌਰ 'ਤੇ ਰਾਜ਼ਦਾਰ ਨਹੀਂ ਹੁੰਦਾ। ਲਾਗ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਰੁਕਿਆ, ਕਿਹੜੀ ਕਮਾਂਡ ਫੇਲ ਹੋਈ, ਅਤੇ ਤਰੁੱਟੀ ਸੁਨੇਹਾ ਕੀ ਹੈ। ਇੱਕ ਚੰਗੀ ਰਨ ਵਿੱਚ stack trace, compiler error ਜਿਸ ਵਿੱਚ ਫਾਈਲ ਅਤੇ ਲਾਈਨ ਨੰਬਰ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਟੈਸਟ ਰਿਪੋਰਟ ਜਿਸ ਵਿੱਚ ਦਿਖਾਇਆ ਹੋਵੇ ਕਿ ਕਿਹੜਾ assertion ਫੇਲ ਹੋਇਆ। ਕਈ ਵਾਰੀ ਤੁਹਾਨੂੰ diff-ਸਟਾਈਲ ਇਸ਼ਾਰਾ ਵੀ ਮਿਲਦਾ ਹੈ ਜਿਵੇਂ "expected X, got Y" ਜਾਂ ਕੋਈ ਸਪਸ਼ਟ ਫੇਲ੍ਹਿੰਗ ਸਟੈਪ ਜਿਵੇਂ "lint", "build", ਜਾਂ "migrate database".
ਅਸਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਲੋਕ (ਅਤੇ AI) ਅਕਸਰ ਲਾਗ ਨੂੰ ਪਿਛੋਕੜ ਸ਼ੋਰ ਸਮਝ ਲੈਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਲੰਬਾ ਲਾਗ ਪੇਸਟ ਕਰਦੇ ਹੋ ਅਤੇ ਸਧਾਰਨ taur 'ਤੇ "ਇੱਕ ਫਿਕਸ" ਮੰਗਦੇ ਹੋ, ਬਹੁਤ ਸਾਰੇ ਮਾਡਲ ਆਖਰੀ ਅਰਥਪੂਰਣ ਲਾਈਨਾਂ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਬਜਾਏ ਪਰਿਚਿਤ ਵੇਰਵੇ ਉਪਰ ਛਾਲ ਮਾਰਦੇ ਹਨ। ਜਦੋਂ error ਆਮ ਲੱਗਦੀ ਹੈ ("module not found", "timeout", "permission denied"), ਤਦ ਗੈਸਿੰਗ ਹੋਰ ਭਿਆਨਕ ਹੋ ਜਾਂਦੀ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ ਤੁਹਾਡੇ ਕੋਲ ਵੱਡਾ ਰੀਰਾਈਟ, ਨਵਾਂ ਡੀਪੈਂਡੇੰਸੀ, ਜਾਂ "ਸਭ ਕੁਝ ਅਪਡੇਟ ਕਰਕੇ ਦੇਖੋ" ਵਰਗਾ ਜਵਾਬ ਆ ਸਕਦਾ ਹੈ ਜੋ ਅਸਲ ਫੇਲ੍ਹ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਮਕਸਦ "ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਪਾਸ ਕਰਵਾਉਣਾ" ਨਹੀਂ ਹੈ। ਇਹ ਸਾਦਾ ਹੈ:
ਅਮਲ ਵਿੱਚ, "ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ" ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਥਾਂ ਤੇ ਕੁਝ ਲਾਈਨਾਂ ਦਾ ਕੋਡ ਬਦਲਾਅ, ਇੱਕ ਗੁੰਮ ਹੋਇਆ import ਜਾਂ ਗਲਤ ਪਾਥ, CI ਵਾਤਾਵਰਨ ਲਈ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਗਲਤ ਕੋਈ config value, ਜਾਂ ਇੱਕ ਅਚਾਨਕ ਤੋੜਣ ਵਾਲੀ ਬਦਲਾਅ ਨੂੰ ਵਾਪਸ ਕਰਨਾ ਬਜਾਏ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੇ।
ਫਾਲੋ-ਅੱਪ ਟੈਸਟ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਵਾਰੀ CI ਪਾਸ ਹੋਣਾ ਉਸੇ ਗੱਲ ਨਹੀਂ ਕਿ ਮੁੜ ਹੋਣ ਤੋਂ ਰੋਕਣਾ। ਜੇ ਫੇਲ੍ਹ ਇੱਕ ਐਜ ਕੇਸ ਕਾਰਨ ਆਇਆ (null input, timezone, rounding, permissions), ਤਾਂ ਇੱਕ regression ਟੈਸਟ ਜੋ ਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ ਹੋਵੇ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪਾਸ ਹੋ ਜਾਵੇ, ਜੋੜੋ। ਇਸ ਨਾਲ ਇੱਕ ਇਕ-ਵਾਰੀ ਰੈਸਕਿਊ ਇਕ ਗਾਰਡਰੇਲ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਖਰਾਬ ਫਿਕਸ ਅਭਾਵੀ ਸੰਦਰਭ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਆਖਰੀ ਲਾਲ ਲਾਈਨ ਪੇਸਟ ਕਰਦੇ ਹੋ, ਮਾਡਲ ਨੂੰ ਪਹਿਲਾਂ ਹੋਏ ਘਟਨਾਕ੍ਰਮ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਪਏਗਾ, ਅਤੇ ਅਨੁਮਾਨ ਅਕਸਰ ਰੀਰਾਈਟ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਇੰਨਾ ਵੇਰਵਾ ਦਿਓ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਫੇਲ੍ਹ ਨੂੰ ਪਹਿਲੀ ਅਸਲ ਗਲਤੀ ਤੋਂ ਅਖੀਰ ਤੱਕ ਫਾਲੋ ਕਰ ਸਕੇ, ਤੇ ਬਹੁਤ ਘੱਟ ਤਬਦੀਲੀ ਕਰੇ।
ਆਪਣੇ ਸੁਨੇਹੇ ਵਿੱਚ ਇਹਨਾਂ ਨੂੰ (ਸਥਿਤੀ ਅਨੁਸਾਰ ਵਰਤੋਂ):
go test ./..., npm test, flutter test, golangci-lint run ਆਦਿ)।ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਜੋੜੋ। ਜੇ ਤੁਸੀਂ ਛੋਟਾ ਫਿਕਸ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਹ ਦੱਸੋ: ਕੋਈ refactor ਨਹੀਂ, ਕੋਈ ਬਿਹੇਵੀਅਰ ਬਦਲਾਅ ਸਿਵਾਏ ਜਰੂਰਤ ਦੇ, ਪੈਚ ਨੂੰ ਸਿਰਫ਼ ਫੇਲ੍ਹਿੰਗ ਖੇਤਰ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: CI ਇੱਕ lint ਸਟੈਪ 'ਤੇ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ dependency bump ਤੋਂ ਬਾਅਦ। ਪਹਿਲੀ ਚੇਤਾਵਨੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ lint ਆਉਟਪੁੱਟ ਪੇਸਟ ਕਰੋ, CI ਨੇ ਕਿਹੜੀ ਕਮਾਂਡ ਚਲਾਈ ਸੀ ਦੱਸੋ, ਅਤੇ ਇਕ ਪੈਕੇਜ ਵਰਜਨ ਬਦਲਾਅ ਦਾ ਜ਼ਿਕਰ ਕਰੋ। ਇਹ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ ਕਿ ਕੋਈ ਇਕ ਲਾਈਨ ਦੀ config ਟਵੀਕ ਜਾਂ ਛੋਟਾ ਕੋਡ ਬਦਲਾਅ ਸੁਝਾਇਆ ਜਾਵੇ, ਨ ਕਿ ਰਿਪੋ ਦਾ ਅੱਧਾ ਰੀਫਾਰਮੇਟ।
ਜੇ ਤੁਸੀਂ ਕੁਝ ਕੁਪੀ-ਪੇਸਟ ਕਰਕੇ ਚਾਹੁੰਦੇ ਹੋ, ਇਹ ਢਾਂਚਾ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ:
CI command:
Failing output (full):
Recent changes:
Constraints (smallest fix, no refactor):
Flaky? (runs attached):
ਜਦੋਂ ਕੋਈ ਮਾਡਲ CI ਬ੍ਰੇਕ 'ਤੇ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟ ਦੀ ਵਜ੍ਹਾ ਹੈ ਜੋ ਉਸਨੂੰ ਗੈਸ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਕੰਮ ਮਾਡਲ ਨੂੰ ਇਹ ਦਿਖਾਉਣਾ ਹੈ ਕਿ ਉਹ ਆਪਣਾ ਕੰਮ ਦਿਖਾਏ, ਸਹੀ ਲਾਗ-ਪਾਰਟੀ ਦੀ ਵਰਤੋਂ ਕਰੇ, ਅਤੇ ਫਿਰ ਉਹੀ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਸੁਝਾਏ ਜੋ ਨੌਕਰੀ ਨੂੰ ਪਾਸ ਕਰਵਾ ਸਕੇ।
ਸਬੂਤ ਅਤੇ ਇੱਕ ਨਿਾ ਯੋਜਨਾ ਲਾਜ਼ਮੀ ਕਰੋ। ਇੱਕ ਚੰਗਾ ਪ੍ਰਾਂਪਟ ਪੰਜ ਗੱਲਾਂ ਨੂੰ ਜ਼ੋਰ ਨਾਲ ਮੰਗਦਾ ਹੈ:
ਅਣਨਿਸ਼ਚਿਤਤਾ ਠੀਕ ਹੈ। ਪਰ ਚੁਪੀ ਅਣਨਿਸ਼ਚਿਤਤਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੀ ਹੈ।
ਸਵਾਲ ਦੇ ਉਪਰ ਇਹ ਪੇਸਟ ਕਰੋ:
Use ONLY the evidence in the CI output below.
1) Quote the exact failing lines you are using.
2) Give ONE sentence: the most likely cause.
3) Propose the smallest fix: 1-3 edits, with file paths.
4) Do NOT do formatting/renames/refactors or "cleanup".
5) List uncertainties + the one extra detail that would confirm the diagnosis.
ਜੇ ਲਾਗ ਵਿੱਚ "expected 200, got 500" ਅਤੇ stack trace user_service.go:142 ਵੱਲ ਦਿਖਾ ਰਿਹਾ ਹੈ, ਇਹ ਢਾਂਚਾ ਜਵਾਬ ਨੂੰ ਉਸ ਫੰਕਸ਼ਨ ਵੱਲ ਧਕੇਲਦਾ ਹੈ ਅਤੇ ਛੋਟੀ ਗਾਰਡ ਜਾਂ error handling ਬਦਲਾਅ ਸੁਝਾਂਦਾ ਹੈ, ਨ ਕਿ ਏਂਡਪਾਇੰਟ ਦਾ ਰੀਡਿਜ਼ਾਈਨ।
ਤੇਜ਼ ਫੈਂਦੇ ਉਹ ਹੁੰਦੇ ਹਨ ਜੋ ਲਾਗ ਨੂੰ ਕੋਟ ਕਰਨ, ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਰਹਿਣ, ਅਤੇ ਜਦੋਂ ਕੁਝ ਘੱਟ ਹੋਵੇ ਤਦ ਰੁਕ ਜਾਣ ਲਈ ਪ੍ਰਾਂਪਟ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ।
You are helping me fix a CI failure.
Repo context (short):
- Language/framework:
- Test/build command that failed: <PASTE THE EXACT COMMAND>
- CI environment (OS, Node/Go/Python versions, etc.):
Failing output (verbatim, include the first error and 20 lines above it):
<PASTE LOG>
Constraints:
- Propose the smallest possible code change that makes CI pass.
- Do NOT rewrite/refactor unrelated code.
- Do NOT touch files you do not need for the fix.
- If behavior changes, make it explicit and justify why it is correct.
Stop rule (no guessing):
- If the log is incomplete or you need more info (missing stack trace, config, versions, failing test name), STOP and ask only the minimum questions needed.
Your response format (follow exactly):
1) Evidence: Quote the exact log lines that matter.
2) Hypothesis: Explain the most likely cause in 2-4 sentences.
3) Smallest fix: Describe the minimal change and why it addresses the evidence.
4) Patch: Provide a unified diff.
5) Follow-up: Tell me the exact command(s) to rerun locally to confirm.
Then, write ONE regression test (or tweak an existing one) that would fail before this fix and pass after it, to prevent the same failure class.
- Keep the test focused. No broad test suites.
- If a test is not feasible, explain why and propose the next-best guardrail (lint rule, type check, assertion).
ਦੋ ਵਿਸ਼ੇ ਜੋ ਬੈਕ-ਅਤੇ-ਫੋਰ ਘਟਾਉਂਦੇ ਹਨ:
ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਖੋ ਜਾਣ ਦਾ ਹੈ ਕਿ ਤੁਸੀਂ "ਕਲੀਨਅਪ" ਤਬਦੀਲੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੋ ਜੋ ਪੰਜ ਚੀਜ਼ਾਂ ਨੂੰ ਇੱਕੋ ਵਾਰੀ ਬਦਲ ਦੈਂ। ਪਹਿਲਾਂ ਹੀ "ਮਿਨੀਮਲ" ਪਰਿਭਾਸ਼ਾ ਕਰੋ: ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ diff ਜੋ ਫੇਲ੍ਹਿੰਗ ਨੌਕਰੀ ਨੂੰ ਪਾਸ ਕਰਵਾਏ, ਸਭ ਤੋਂ ਘੱਟ ਖਤਰਾ ਅਤੇ ਤੁਰੰਤ ਵੈਰੀਫਾਈ ਕਰਨਯੋਗ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਪਹਿਲਾਂ ਸਿੰਬਟਮ ਨੂੰ ਫਿਕਸ ਕਰੋ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਵਿਆਪਕ ਰੀਫੈਕਟਰ ਲੋੜੀਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਲਾਗ ਇੱਕ ਫਾਈਲ, ਇੱਕ ਫੰਕਸ਼ਨ, ਇੱਕ ਗੁੰਮ ਆਈਮਪੋਰਟ, ਜਾਂ ਇੱਕ ਐਜ ਕੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਉਥੇ ਹੀ ਲਕੜੀ ਲਗਾਓ। "ਅਸੀਂ ਇੱਥੇ ਹੋਣ ਦੇ ਦੌਰਾਨ" ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਚੋ।
ਜੇ ਤੁਹਾਨੂੰ ਸਚਮੁੱਚ ਵਿਵਕਲਪ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਦੋ ਅਤੇ ਸਿਰਫ਼ ਦੋ ਮੰਗੋ: "ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਮਿਨੀਮਲ ਫਿਕਸ" ਵਿਰੁੱਧ "ਤੇਜ਼ਤਮ ਮਿਨੀਮਲ ਫਿਕਸ"। ਤੁਸੀਂ tradeoffs ਚਾਹੁੰਦੇ ਹੋ, ਨ ਕਿ ਮੇਨੂ।
ਸਾਥ ਹੀ ਲੋਕਲ verification ਦੀ ਮੰਗ ਕਰੋ ਜੋ CI ਵਰਗੇ ਕਮਾਂਡ (ਜਾਂ ਉਸ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ) ਨੂੰ ਚਲਾਏ, ਤਾਂ ਕਿ ਤੁਸੀਂ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰ ਸਕੋ:
# run the same unit test target CI runs
make test
# or the exact script used in CI
npm test
ਜੇ ਜਵਾਬ ਵੱਡੇ ਬਦਲਾਅ ਸਝਾਉਂਦਾ ਹੈ, ਤਾਂ ਦੁਬਾਰਾ ਪੁੱਛੋ: "ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਪੈਚ ਦਿਖਾਓ ਜੋ ਫੇਲ੍ਹ ਹੋਈ assertion ਨੂੰ ਠੀਕ ਕਰੇ, ਕਿਸੇ ਗੈਰ-ਸੰਬੰਧਤ formatting ਜਾਂ renames ਦੇ ਬਗੈਰ।"
ਬਿਨਾਂ ਟੈਸਟ ਦੇ ਫਿਕਸ ਇੱਕ ਸ਼ਰਤ ਹੈ ਕਿ ਤੁਸੀਂ ਦੁਬਾਰਾ ਨਹੀਂ ਆਓਗੇ। ਹਮੇਸ਼ਾਂ ਇੱਕ ਫਾਲੋ-ਅੱਪ ਟੈਸਟ ਮੰਗੋ ਜੋ ਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ ਅਤੇ ਫਿਕਸ ਤੋਂ ਬਾਅਦ ਪਾਸ ਹੋਵੇ।
"ਚੰਗਾ" ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ:
ਇੱਕ ਉਪਯੋਗ ਪੈਟਰਨ: ਟੈਸਟ ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ, ਉਸਦਾ ਨਾਮ ਕੀ ਹੋਵੇ, ਕਿਹੜਾ ਵਿਵਹਾਰ ਕਵਰ ਕਰੇ, ਅਤੇ 2–3 ਸੰਗੀਨ ਵਾਕ — ਇਹ ਸਭ ਮੰਗੋ।
ਕਾਪੀ-ਰੇਡੀ ਐਡ-ਆਨ:
ਉਦਾਹਰਨ: CI ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ API ਹੈਂਡਲਰ ਖਾਲੀ string ID ਮਿਲਣ 'ਤੇ panic ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਨਾ ਸਿਰਫ਼ ਇਕ ਲਾਈਨ ਲਈ ਟੈਸਟ ਮੰਗੋ, ਬਲਕਿ invalid IDs (empty, whitespace, wrong format) ਲਈ ਟੈਸਟ ਮੰਗੋ। ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ ਇੱਕ guard clause ਹੋ ਸਕਦਾ ਹੈ ਜੋ 400 ਰਿਸਪਾਂਸ ਰਿਟਰਨ ਕਰਦਾ ਹੈ। ਫਾਲੋ-ਅੱਪ ਟੈਸਟ ਕਈ invalid inputs 'ਤੇ assert ਕਰੇਗਾ, ਤਾਂ ਜੇ ਤੁਸੀਂ parsing ਨੂੰ ਬਾਅਦ 'ਚ ਰੀਫੈਕਟਰ ਕੀਤਾ ਤਾਂ CI ਤੁਰੰਤ fail ਹੋ ਜਾਵੇਗਾ।
CI ਲਾਗ ਦਾ ਸੈਕਸ਼ਨ ਪੇਸਟ ਕਰੋ ਜਿਸ ਵਿੱਚ error ਅਤੇ 20–40 ਲਾਈਨਾਂ ਉਪਰ ਲਾਈਨ ਆਏ। ਨਾਲ ਹੀ ਐਕਜ਼ੈਕਟ failing command ਅਤੇ ਮੁੱਖ ਵਾਤਾਵਰਨ ਵੇਰਵੇ (OS, runtime versions, महत्वपूर्ण flags) ਦਿਓ।
ਫਿਰ ਮੰਗੋ ਕਿ ਉਹ ਜੋ ਫੇਲ੍ਹ ਹੋਇਆ ਉਹ ਸਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੁਹਰਾਏ ਅਤੇ ਉਹ ਲਾਈਨ(ਆਂ) ਨੂੰ ਦਰਸਾਏ ਜੋ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਇਹ ਲਾਗ ਕੋਟ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਇਸਨੇ ਸਚਮੁਚ ਪੜ੍ਹਿਆ ਹੀ ਨਹੀਂ।
ਸਭ ਤੋਂ ਛੋਟਾ ਕੋਡ ਬਦਲਾਅ ਮੰਗੋ ਜੋ ਫੇਲ੍ਹਿੰਗ ਕਮਾਂਡ ਨੂੰ ਪਾਸ ਕਰਵਾਏ। ਰੀਫੈਕਟਰਨ ਤੇ ਵਾਪਸ ਧੱਕੋ। ਯਾਦ ਰੱਖੋ ਕਿ ਲਾਗ ਦੇ ਅਧਾਰ 'ਤੇ ਇਹਨਾਂ ਗੱਲਾਂ ਨੂੰ ਲਿਖੋ:
ਪੈਚ ਲਗਾਓ ਅਤੇ ਓਹੀ ਫੇਲ੍ਹਿੰਗ ਕਮਾਂਡ ਲੋਕਲ ਰੂਪ ਵਿੱਚ ਜਾਂ CI 'ਚ ਚਲਾਓ। ਜੇ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਸਿਰਫ ਨਵੀਂ ਫੇਲ੍ਹ ਆਉਟਪੁੱਟ ਪੇਸਟ ਕਰੋ ਅਤੇ ਦੁਹਰਾਓ। ਛੋਟਾ context ਜਵਾਬ ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦਾ ਹੈ।
ਜਦੋਂ ਗ੍ਰੀਨ ਆ ਗਿਆ, ਇਕ focused regression ਟੈਸਟ ਜੋੜੋ ਜੋ ਪਿਛਲੇ ਕੋਡ 'ਤੇ ਫੇਲ਼ ਹੁੰਦਾ ਅਤੇ ਹੁਣ ਪਾਸ ਹੁੰਦਾ। ਇੱਕ ਟੈਸਟ, ਇੱਕ ਕਾਰਨ—ਸਪਸ਼ਟ ਰਿਹਾ।
ਇੱਕ ਛੋਟਾ commit message ਅਤੇ PR ਵਰਣਨ ਮੰਗੋ ਜਿਸ ਵਿੱਚ ਦਰਸਾਇਆ ਹੋਵੇ: ਕੀ ਫੇਲ੍ਹ ਹੋਇਆ, ਕੀ ਬਦਲਿਆ ਗਿਆ, ਤੁਸੀਂ ਕਿਵੇਂ ਵੈਰੀਫਾਈ ਕੀਤਾ, ਅਤੇ ਕਿਹੜਾ ਟੈਸਟ ਮੁੜ ਆਉਣ ਤੋਂ ਰੋਕੇਗਾ। ਰਿਵਿਊਅਰ਼ ਤੇਜ਼ੀ ਨਾਲ ਚਲਦੇ ਹਨ ਜਦੋਂ ਕਾਰਨ ਸਪਸ਼ਟ ਹੋਵੇ।
ਇੱਕ ਆਮ ਫੇਲ੍ਹ: ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਭ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਫਿਰ ਇੱਕ ਛੋਟੀ ਬਦਲਾਅ ਨੇ CI 'ਤੇ ਟੈਸਟ ਫੇਲ੍ਹ ਕਰਵਾ ਦਿੱਤਾ। ਹੇਠਾਂ ਇੱਕ ਹੋਰਮਿਸਾਲ Go API ਦੀ ਹੈ ਜਿੱਥੇ ਹੈਂਡਲਰ ਹੁਣ date-only value (2026-01-09) ਸਵੀਕਾਰ ਕਰ ਰਿਹਾ ਸੀ ਪਰ ਕੋਡ ਅਜੇ ਵੀ RFC3339 timestamps ਹੀ ਪਾਰਸ ਕਰ ਰਿਹਾ ਸੀ।
ਇਹ ਉਸ ਤਰ੍ਹਾਂ ਦਾ ਛੋਟਾ ਸਨਿੱਪੇਟ ਹੈ ਜੋ ਤੁਸੀਂ ਪੇਸਟ ਕਰੋਗੇ (ਛੋਟਾ ਰੱਖੋ, ਪਰ error ਲਾਈਨ ਸ਼ਾਮਿਲ ਕਰੋ):
--- FAIL: TestCreateInvoice_DueDate (0.01s)
invoice_test.go:48: expected 201, got 400
invoice_test.go:49: response: {"error":"invalid due_date: parsing time \"2026-01-09\" as \"2006-01-02T15:04:05Z07:00\": cannot parse \"\" as \"T\""}
FAIL
exit status 1
FAIL app/api 0.243s
ਹੁਣ ਇਕ ਪ੍ਰਾਂਪਟ ਵਰਤੋ ਜੋ ਲਾਗ ਕੋਟ ਕਰਨ, ਮਿਨੀਮਲ ਫਿਕਸ, ਅਤੇ ਟੈਸਟ ਮੰਗਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ:
You are fixing a CI failure. You MUST use the log to justify every claim.
Context:
- Language: Go
- Failing test: TestCreateInvoice_DueDate
- Log snippet:
<PASTE LOG>
Task:
1) Quote the exact failing line(s) from the log and explain the root cause in 1-2 sentences.
2) Propose the smallest possible code change (one function, one file) to accept both RFC3339 and YYYY-MM-DD.
3) Show the exact patch.
4) Add one regression test that fails before the fix and passes after.
Return your answer with headings: Evidence, Minimal Fix, Patch, Regression Test.
ਇੱਕ ਚੰਗਾ ਜਵਾਬ parsing layout mismatch ਨੂੰ ਨੁਹਣਾ ਕਰੇਗਾ, ਫਿਰ ਇੱਕ ਛੋਟੀ-ਜਿਹੀ ਤਬਦੀਲੀ ਕਰੇਗਾ (ਉਦਾਹਰਨ: parseDueDate invoice.go ਵਿੱਚ) ਜੋ ਪਹਿਲਾਂ RFC3339 ਨੂੰ ਕੋਸ਼ਿਸ਼ ਕਰੇ ਅਤੇ ਫਿਰ 2006-01-02 'ਤੇ fallback ਕਰੇ।
Regression ਟੈਸਟ ਰੱਖਣ ਵਾਲੀ ਗਾਰਡ: due_date: "2026-01-09" ਭੇਜੋ ਅਤੇ 201 ਦੀ ਉਮੀਦ ਰਖੋ। ਜੇ ਕੋਈ ਬਾਅਦ ਵਿੱਚ fallback ਹਟਾਉਂਦਾ ਹੈ ਤਾਂ CI ਫੇਲ੍ਹ ਕਰੇਗਾ।
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਘੰਟਾ ਖੋ ਜਾਣ ਦਾ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਕ੍ਰਾਪਡ ਦੁਆਰਾ ਦਿਓ। CI ਲਾਗ ਸ਼ੋਰ-ਭਰਪੂਰ ਹਨ, ਪਰ ਉਪਯੋਗੀ ਹਿੱਸਾ ਆਮ ਤੌਰ 'ਤੇ ਆਖਰੀ ਗਲਤੀ ਤੋਂ 20 ਲਾਈਨਾਂ ਉਪਰ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਫੰਦਾ ਹੈ ਕਿ ਸਿਰਫ ਆਖਰੀ ਲਾਲ ਲਾਈਨ ਪੇਸਟ ਕੀਤੀ ਜਾਵੇ (ਜਿਵੇਂ "exit 1") ਪਰ ਅਸਲੀ ਕਾਰਨ ਪਹਿਲਾਂ ਆ ਰਿਹਾ ਹੁੰਦਾ ਹੈ (ਗੁੰਮ env var, failing snapshot, ਜਾਂ ਪਹਿਲੀ ਟੈਸਟ ਜੋ ਢਹਿ ਗਈ)। ਠੀਕ ਕਰਨ ਲਈ: ਪਹਿਲੀ ਅਸਲ ਗਲਤੀ ਲਾਈਨ ਅਤੇ ਫੇਲ੍ਹਿੰਗ ਕਮਾਂਡ ਸ਼ਾਮਿਲ ਕਰੋ।
ਹੋਰ ਸਮੇਂ ਖਰਚ ਕਰਨ ਵਾਲੀ ਗਲਤੀ: ਮਾਡਲ ਨੂੰ ਰਸਦ-ਸਾਫ਼ਾਈ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ। ਵਾਧੂ formatting, dependency bumps, ਜਾਂ ਰੀਫੈਕਟਰਿੰਗ ਦੀਆਂ ਬਦਲਾਅ ਰਿਵਿਊ ਨੂੰ ਮੁਸ਼ਕਲ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਤੋੜ ਸਕਦੀਆਂ ਹਨ। ਫਿਕਸ: ਸਕੋਪ ਲਾਕ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਘੱਟ ਤਬਦੀਲੀ ਮਨਜ਼ੂਰ ਕਰੋ।
ਕੁਝ ਆਮ ਪੈਟਰਨਾਂ:
ਪੁਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਛੋਟਾ sanity ਪਾਸ ਕਰੋ। ਮਕਸਦ ਇਹ ਸ਼ੁਨਿਸ਼ਚਤ ਕਰਨਾ ਹੈ ਕਿ ਬਦਲਾਅ ਅਸਲੀ ਹੈ, ਘੱਟੋ-ਘੱਟ ਹੈ, ਅਤੇ ਦੋਹਰਾਏ ਜਾ ਸਕਦਾ ਹੈ — ਨਾ ਕਿ ਇੱਕ ਕਿਸਮ ਦੀ ਕਿਸਮਤ ਦੀ ਪਾਸ।
ਅੰਤ ਵਿੱਚ, ਫਿਕਸ ਪੈਕੇਟ ਨੂੰ push ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਵੱਡੇ ਟਾਰਗਟਸ (ਉਦਾਹਰਨ: lint ਅਤੇ unit tests) ਵੀ ਚਲਾ ਲਓ। ਇੱਕ ਆਮ ਫੰਦ ਇਹ ਹੈ ਕਿ ਇੱਕ ਫਿਕਸ ਮੂਲ ਨੌਕਰੀ ਨੂੰ ਪਾਸ ਕਰਵਾ ਦਿੰਦਾ ਹੈ ਪਰ ਕਿਸੇ ਹੋਰ ਟਾਰਗਟ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਹਫ਼ਤੇ-ਬ-ਹਫ਼ਤੇ ਸਮਾਂ ਬਚਾਏ, ਤਾਂ ਆਪਣੇ ਪ੍ਰਾਂਪਟ ਅਤੇ ਜਵਾਬ ਢਾਂਚੇ ਨੂੰ ਟੀਮ ਪ੍ਰਕਿਰਿਆ ਸਮਝੋ। ਮਕਸਦ ਦੁਹਰਾਅਯੋਗ ਇਨਪੁਟ, ਦੁਹਰਾਅਯੋਗ ਆਉਟਪੁਟ, ਅਤੇ ਘੱਟ "ਰਹੱਸਮਈ ਫਿਕਸ" ਜੋ ਕੁਝ ਹੋਰ ਤੋੜ ਦਿੰਦੇ ਹਨ।
ਆਪਣੇ ਬਿਹਤਰ ਪ੍ਰਾਂਪਟ ਨੂੰ ਇੱਕ ਰਿਪੋ ਸਨਿੱਪੇਟ ਵਜੋਂ ਸੇਵ ਕਰੋ ਅਤੇ ਟੀਮ ਚੈਟ 'ਚ ਪਿਨ ਕਰੋ। ਨਤੀਜਾ ਇਹ ਹੋਵੇ ਕਿ ਰਿਵਿਊਅਰਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਨਿਰਣਾ ਲੈ ਲੈਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਜਾਣਦੇ ਹਨ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ।
ਜੇ ਤੁਸੀਂ chat-ਪਹਿਲਾ ਵਰਕਫਲੋ ਪਸੰਦ ਕਰਦੇ ਹੋ ਤਾਂ ਉੱਥੇ ਹੀ fix-and-test ਲੂਪ ਨੂੰ ਚਲਾਓ (ਉਦਾਹਰਨ: Koder.ai) ਅਤੇ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸੋਐਰਸ export ਕਰੋ ਅਤੇ merge ਕਰੋ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲੀ ਗਲਤੀ ਨਾਲ — ਆਖਰੀ exit 1 ਨਾਲ ਨਹੀਂ।
ਉਸਨੂੰ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕਹੋ ਕਿ ਉਸਨੇ ਲਾਗ ਪੜ੍ਹਿਆ ਹੈ।
ਇੱਕ ਸੀਮਾ ਵਰਗਾ ਇਹ ਵਰਤੋਂ:
CV ਫੇਲ੍ਹ ਲਈ "ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ" ਦਾ ਮਤਲਬ: ਉਸ ਇੱਕ ਸਟੈਪ ਨੂੰ ਸਫਲ ਬਣਾਉਣ ਵਾਲੀ ਸਭ ਤੋਂ ਘੱਟ ਤਬਦੀਲੀ।
ਇਸਦਾ ਅਰਥ ਆਮ ਤੌਰ 'ਤੇ:
CI ਗ੍ਰੀਨ ਹੋਣ ਤੱਕ “ਕਲੀਨਅਪ” ਬਦਲਾਵਾਂ ਤੋਂ ਬਚੋ।
ਫੇਲ੍ਹ ਨੂੰ ਦੁਹਰਾਉਣ ਲਈ ਕਾਫ਼ੀ ਸੀਟੂਏਸ਼ਨ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਸਮੱਗਰੀ ਪੇਸਤ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ ਆਖਰੀ ਲਾਲ ਲਾਈਨ।
ਸ਼ਾਮِل ਕਰੋ:
go test ./..., npm test, , ਆਦਿ)।ਹਾਂ — ਸਪਸ਼ਟ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਸਧੇ ਪਾਓ।
ਉਦਾਹਰਨ ਵੱਜੋਂ ਸੀਮਾਵਾਂ:
ਇਸ ਨਾਲ ਜਵਾਬ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਅਤੇ ਆਸਾਨ ਰਿਵਿਊਯੋਗ ਬਣਦਾ ਹੈ।
ਸਭ ਤੋਂ ਪਹਿਲੀ ਅਸਲ ਗਲਤੀ ਨੂੰ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ।
ਸੰਦੇਹ ਹੋਵੇ ਤਾਂ ਮਾਡਲ ਨੂੰ ਲਾਗ ਵਿੱਚੋਂ ਪਹਿਲੀ ਫੇਲ ਹੋਈ ਕਦਮ ਪੁਛੋ ਅਤੇ ਉਸੇ ਨਾਲ ਟਿਕੇ ਰਹੋ।
ਫਲੇਕਿਨੈਸ ਨੂੰ ਰੀਟ੍ਰਾਈਜ਼ ਨਾਲ ਢੱਕੋ ਨਾ — ਉਨ੍ਹਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਹਟਾਓ ਜੋ nondeterministic ਹਨ।
ਆਮ ਸਥਿਰ ਕਰਨ ਵਾਲੀਆਂ ਗੱਲਾਂ:
ਇਹ ਕਰਨ ਮਗਰੋਂ “ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ” ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ।
CI ਨੇ ਜੋ ਕਮਾਂਡ ਚਲਾਈ ਸੀ وَਹੇ ਕਮਾਂਡ ਲੋਕਲ ਚ ਚਲਾਓ:
ਜੇ ਲੋਕਲ ਰੀਪ੍ਰੋ ਦੇਣ ਮੁਸ਼ਕਲ ਹੈ, ਤਾਂ ਇੱਕ ਮਿਨੀਮਲ ਰിപਰੋ ਦੇਵੋ ਜੋ ਰੇਪੋ ਦੇ ਅੰਦਰ ਇੱਕ ਹੀ ਗਲਤੀ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰੇ।
ਨੌਕਸਾਨ ਮੁੜ ਆਉਣ ਤੋਂ ਬਚਾਉਣ ਲਈ ਇੱਕ ਕੇਂਦਰੀ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟ ਲਿਖੋ ਜੋ ਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਕਸ ਤੋਂ ਬਾਅਦ ਪਾਸ ਹੁੰਦਾ ਹੈ।
ਚੰਗੇ ਲਕੜੀ-ਨਿਸ਼ਾਨੇ:
ਜੇ ਇਹ lint/build ਮਸਲਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਇੱਕ ਸਖ਼ਤ lint ਰੂਲ ਜਾਂ ਚੈੱਕ ਨਾਲ enforce ਕਰੋ।
ਸਨੈਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਵਰਤੋ ਤਾਂ ਜੋ ਪ੍ਰਯੋਗ ਰਿਵਰਸਬਲ ਰਹਿਣ।
ਪ੍ਰੈਕਟਿਕਲ ਲੂਪ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ ਸਨੈਪਸ਼ਾਟ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਦੁਬਾਰਾ ਕੋਡ ਸਥਿਤੀ 'ਤੇ ਵਾਪਸ ਆਉਣ ਦੇਣਗੇ।
flutter test