CI Log Diff Open the app

Practical guide

How to compare a failed CI run with a passing run

A short workflow that works with any diff tool, and where CI Log Diff helps.

  1. Pick two comparable runs

    Use the same workflow and the same job, ideally the last run that passed on the same branch and the first that failed. A different runner image, a dependency bump or a changed matrix entry will show up as differences too — which is sometimes the answer.

  2. Download the raw job logs

    Use the CI provider’s “download log” or “view raw logs” for the single job, not the archive for the whole workflow. Save them as plain UTF-8 text.

  3. Normalize only noise you can name

    Timestamps are safe to ignore. Absolute workspace paths are, when they differ between runners. Do not strip “all numbers”: you would also erase exit codes, ports, test counts and durations, and those are often the lead.

  4. Read from the first change, not the last error

    The final error is usually a consequence. Step through changed blocks from the top: a new warning during install, a changed version, a different port. Error candidates are convenient entry points, not the full story.

  5. Verify in the raw log

    Use the line ranges to open the original file and read around the block. Widen the context before you conclude anything.

  6. Share ranges, not secrets

    When you hand the finding to someone else, line ranges and classifications are usually enough. Include log text only after reading it; logs often contain tokens, internal URLs and customer data.

References

External links open other websites. Formats can change; CI Log Diff 1.0.0-rc.1 implements ruleset ci-log-diff-v2.