Hosting Operations
Read-only, can be slowScan Every CI Log for Error Lines
Multiple CI logs may contain errors, warnings, stack traces, and test failures, but opening each file manually is slow.
Command
grep -RInE 'error|failed|failure|exception|traceback' artifacts logs | head -50Before you run this
System impact: Read-only. Can create load on large logs, directories, filesystems, or process tables.
When not to use it: Do not treat every warning-like match as fatal; confirm with the surrounding log context.
Expected output
Matching error-like lines with file paths and line numbers.
System impact
Read-only, can be slow. Nothing changes. grep prints matching file names, line numbers, and excerpts.
Scope this to the smallest useful path or service on busy systems.
Recovery / rollback: no state is changed.
When to use it
Use for the first pass over CI logs when the failing stage is unclear.
When not to use it
Do not treat every warning-like match as fatal; confirm with the surrounding log context.
Watch this command run
Command transcript
This sanitized transcript shows the commands and output shape without exposing host details.
$ cd /work/ci-artifacts && grep -RInE 'error|failed|failure|exception|traceback' artifacts logs | head -50
artifacts/build/webpack.log:1:webpack 5.91.0 compiled with 1 error
artifacts/build/app-build.log:5:Build failed with exit code 1
artifacts/test/pytest.log:6:tests/test_billing.py::test_invoice passed on retry after failed attempt 1
artifacts/test/pytest.log:7:1 failed, 2 passed, 1 rerun
artifacts/test/junit.xml:1:<testsuite name="api" tests="4" failures="1" errors="0" skipped="1">
artifacts/test/junit.xml:4: <failure message="expected 201 got 500">AssertionError</failure>
logs/deploy.log:4:Deploy failed: missing artifacts/dist/robots.txt$ cd /work/ci-artifacts && grep -RInE 'error|failed|failure|exception|traceback' artifacts logs | cut -d: -f1 | sort -u
artifacts/build/app-build.log
artifacts/build/webpack.log
artifacts/test/junit.xml
artifacts/test/pytest.log
logs/deploy.log$ cd /work/ci-artifacts && sed -n '1,120p' artifacts/test/pytest.log
============================= test session starts =============================
tests/test_api.py::test_health PASSED
tests/test_api.py::test_create_user FAILED
Traceback (most recent call last):
AssertionError: expected 201 got 500
tests/test_billing.py::test_invoice passed on retry after failed attempt 1
1 failed, 2 passed, 1 rerunView commands shown
These are the commands shown in the sanitized transcript.
Commands shown
cd /lab/ci-artifacts && grep -RInE 'error|failed|failure|exception|traceback' artifacts logs | head -50cd /lab/ci-artifacts && grep -RInE 'error|failed|failure|exception|traceback' artifacts logs | cut -d: -f1 | sort -ucd /lab/ci-artifacts && sed -n '1,120p' artifacts/test/pytest.log
next steps
Related commands
Tail the Failing CI Lines
Skip the full CI log and jump straight to lines that usually explain the failure.
grep -RInE 'error|failed|exception|traceback|fatal' logs/ | tail -50
Find Tests That Passed After Rerun
A green retry can still hide a flaky test.
grep -RInE 'rerun|retry|flaky|passed on retry|failed attempt' artifacts logs
Detect Secret Leak Markers in Artifacts
Artifacts are public more often than you think.
grep -RInE 'AWS_ACCESS_KEY|SECRET|TOKEN|PRIVATE KEY|PASSWORD' artifacts logs | head -50
List Failed Tests from JUnit XML
The XML report already knows which tests failed.
grep -RIn '<failure\|<error' artifacts/test/*.xml
Find Coverage Regression Lines
Coverage failures usually say the threshold out loud.
grep -RInE 'coverage|threshold|minimum|below' artifacts logs
Study mapping
Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.
Useful for
- LPIC-1 style command-line practice
- LFCS style performance tasks
- Linux+ style troubleshooting review
Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.