What to include in a CI failure reproduction packet

A CI failure reproduction packet should give another developer enough context to rerun the failing command without reading the whole job log.

Start with the smallest failing command, not the entire workflow file. Include repository branch, commit, runner OS, package manager, runtime version, working directory, environment variables that affect behavior, cache state if relevant, and the exact command that failed. Add the expected result, actual result, and the first meaningful error line. Long logs are useful later, but the first pass needs a compact comparison.

Separate environment facts from guesses. “Node 22 on Ubuntu, command run from packages/api, missing DATABASE_URL in step env” is better than “CI is broken.” If the command works locally, list local versions and working directory so the difference can be compared. If the command fails only after cache restore, include cache key and whether a clean run was tried.

A good packet also names the ownership question: who can change the workflow, who owns the secret, who can rerun with debug logging, and which step is safe to retry. Without that, the ticket may have the facts but no next action.

The practical test is whether a teammate can copy the command, set the listed variables, and reproduce the same error or confidently identify the missing difference.

What to include in a CI failure reproduction packet

// COMMENTS

ON THIS PAGE