Session M4-03 lab: Debug pipelines from logs and local checks¶
Duration: 2 hours Difficulty: Advanced Prerequisites: Sessions M1-01 to M1-03, M2-01 to M2-02 and M4-01 Deliverable: Three investigation records, fixed workflows, and a reviewed security patch
Lab overview¶
You will investigate three pipeline failures, review a security repair, and improve feedback speed without removing checks.
| Part | Work | Time |
|---|---|---|
| 1 | Check the local application baseline | 10 min |
| 2 | Investigate three pipeline cases | 50 min |
| 3 | Review a security remediation | 30 min |
| 4 | Improve feedback speed | 20 min |
| 5 | Collect investigation records | 10 min |
Before you start¶
Read the course safety baseline. You must have GitHub Copilot access and Node.js 20.x. Use only the supplied application, logs, and workflow files.
Remote workflow runs and security products are optional. Use them only when the instructor checks access and permits their use. You must complete the local work. If GitHub Copilot access is unavailable, stop.
Do not open lab/solution/fixed-pipelines/ until a checkpoint tells you to compare.
For Case 3, do not open error-log-3-stage-2.txt until the first repair is complete.
Setup¶
Run all commands from this session directory unless a command changes directory.
Check that the application works before you inspect the pipeline:
cd lab/starter/pipeline-app
npm ci
npm test
npm run lint
npm run build
test -f dist/index.js
cd ../../..
Expected result: install, tests, lint, and build pass.
Create one investigation record per case:
| Field | Record |
|---|---|
| Failed job and step | |
| Exact observation | |
| Local proof command | |
| Hypothesis | |
| Smallest repair | |
| Proof after repair |
Part 1: Investigate the pipeline cases¶
For every case:
- Read the workflow and failed-step output.
- Record observations without naming a root cause.
- Run the local command and record its result.
- State one hypothesis.
- Ask Copilot to challenge the hypothesis and propose the smallest repair.
- Validate the repaired YAML.
- Compare with the solution only after the checkpoint.
Use this prompt:
Read this workflow and failed-step output. Separate observations from hypotheses.
Use the supplied local command as additional evidence. Propose the smallest repair
and one proof command. Do not change unrelated jobs.
Case 1¶
Open pipeline-1.yml and error-log-1.txt.
Run:
Record what the log and package metadata say. Edit only after your hypothesis explains both.
After the repair:
ruby -e 'require "yaml"; Psych.parse_stream(File.read(ARGV[0]))' \
lab/starter/failing-pipelines/pipeline-1.yml
Checkpoint: Record the parser result, then compare with
lab/solution/fixed-pipelines/pipeline-1.yml.
Case 2¶
Open pipeline-2.yml and error-log-2.txt.
Run the failing command from the workflow location:
Expected failure: npm cannot find the project package metadata in the session root. Now check the same command in the application directory:
After the repair, parse the YAML and compare with the solution.
Checkpoint: The repair must explain why changing dependency resolution would not address the observed path failure.
Case 3: multi-stage failure¶
Open pipeline-3.yml and error-log-3.txt. Investigate only the first failed
stage.
Run:
Repair the first failure and parse the workflow. Then open
error-log-3-stage-2.txt. The second log represents the next run after the first
repair.
Use the new log. Do not restore the first change or add unrelated fixes. After the second repair, run:
ruby -e 'require "yaml"; Psych.parse_stream(File.read(ARGV[0]))' \
lab/starter/failing-pipelines/pipeline-3.yml
npm --prefix lab/starter/pipeline-app run build
test -f lab/starter/pipeline-app/dist/index.js
Checkpoint: Record two observations, two repairs, and separate check results for each
stage. Then compare with lab/solution/fixed-pipelines/pipeline-3.yml.
Part 2: Review a security remediation¶
Open lab/starter/vulnerable-app/src/app.js. Check its syntax locally:
Complete the CodeQL workflow template. If an approved remote scan is available, inspect its findings. Otherwise use the supplied source as the finding context.
Investigate these sinks without opening the secure solution:
- SQL query construction;
- HTML response construction;
- file path resolution.
Ask for one repair at a time in lab/starter/vulnerable-app/src/app.js.
Review the diff. Copy only the supplied test harness and dependency manifests,
not the solution source, into your working app:
mkdir -p lab/starter/vulnerable-app/test
cp lab/solution/secure-app/package.json lab/solution/secure-app/package-lock.json \
lab/starter/vulnerable-app/
cp lab/solution/secure-app/test/security.test.js \
lab/starter/vulnerable-app/test/
node --check lab/starter/vulnerable-app/src/app.js
npm ci --prefix lab/starter/vulnerable-app
npm test --prefix lab/starter/vulnerable-app
Explain how each repair protects its code path: parameterized queries for SQL,
output encoding for HTML, and resolved-path containment for file access.
The three tests must pass. Do not rely only on an absence of scanner findings.
Then compare your repair with lab/solution/secure-app/src/app.js.
Part 3: Improve feedback speed¶
Review lab/starter/slow-pipeline/workflow.yml. Preserve its checks while adding
lockfile caching, parallel lint and test jobs, shallow checkout, and a main-push
deployment condition.
Validate:
ruby -e 'require "yaml"; Psych.parse_stream(File.read(ARGV[0]))' \
lab/starter/slow-pipeline/workflow.yml
grep -nE "cache: 'npm'|needs: \\[lint, test\\]|fetch-depth: 1|github.event_name" \
lab/starter/slow-pipeline/workflow.yml
Then compare your workflow with lab/solution/optimized-pipeline/workflow.yml.
Final deliverable¶
Submit:
- Three fixed workflows.
- Three investigation records, with two stages for Case 3.
- A reviewed security patch and local syntax-check output.
- The optimized workflow review.
Write the root-cause statement after the observation and local check results. Keep the original logs unchanged with the investigation records.