Stage 5 · Platform
CI/CD Foundations
Pipeline Feedback Loops
Using pull request checks, commit statuses, notifications, and flaky-test quarantine to shorten feedback.
Why Feedback Speed Matters
The value of a pipeline is proportional to how quickly it delivers feedback. A pipeline that takes 30 minutes to report a linting error has already lost — the developer context-switched to another task. Fast feedback keeps developers in flow and catches errors while the code is still fresh in their mind.
Research from the DORA team shows that elite performers have pipeline durations under 10 minutes. This is not just about speed — it is about creating a tight loop between writing code and knowing whether it works.
Commit Statuses
Commit statuses are the primary feedback mechanism. When a pipeline runs, it reports its status back to the commit — pending, success, failure, or error. These statuses appear in the GitHub UI, on pull requests, and in commit history.
name: Status Checks
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run lint
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run typecheck
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm testEach job reports its own status. Branch protection rules can require all three checks to pass before merging. This gives developers immediate feedback on what broke.
Pull Request Checks
Pull request checks are the most visible form of pipeline feedback. They appear as a list of checks on the PR, showing pass/fail status for each job. GitHub and GitLab both support required checks that block merging until they pass.
lint:
stage: test
script:
- npm run lint
artifacts:
when: always
reports:
dotenv: lint-report.env
test:
stage: test
script:
- npm test
coverage: '/Statements\s*:\s*(\d+\.\d+)%/'
artifacts:
when: always
reports:
junit: test-results/junit.xml
coverage_report:
coverage_format: cobertura
path: coverage/cobertura.xml
sast:
stage: test
script:
- semgrep --config auto --sarif -o sast-results.sarif .
artifacts:
reports:
sast: sast-results.sarifGitLab CI supports multiple report formats that render directly in the merge request. Coverage percentages appear in the MR widget, SAST results appear in the security dashboard, and test results show pass/fail counts.
Notifications and Alerts
Beyond the commit status, pipelines should notify the right people when things break. This can be Slack messages, email, webhook calls, or even PagerDuty alerts for critical failures.
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
notify:
needs: build
if: failure()
runs-on: ubuntu-latest
steps:
- name: Notify Slack
uses: slackapi/slack-github-action@v1
with:
payload: |
{
"text": "Pipeline failed on ${{ github.ref_name }}",
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*Pipeline Failed*\nRepo: ${{ github.repository }}\nBranch: ${{ github.ref_name }}\nCommit: ${{ github.sha }}"
}
}
]
}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}The notify job only runs when the build job fails (if: failure()). It sends a structured Slack message with repository, branch, and commit information so the team can quickly investigate.
Flaky Test Quarantine
Flaky tests — tests that pass and fail intermittently — destroy trust in the pipeline. When developers see random failures, they start re-running pipelines instead of investigating. Quarantining flaky tests keeps the pipeline green while the underlying issues are fixed.
jobs:
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
steps:
- uses: actions/checkout@v4
- run: npm ci
- name: Run tests with retry
uses: nick-fields/retry@v3
with:
timeout_minutes: 10
max_attempts: 3
command: npm test
- name: Upload flaky test report
if: failure()
uses: actions/upload-artifact@v4
with:
name: flaky-report
path: test-results/The retry action automatically retries failed tests up to 3 times. If a test passes on retry, it is likely flaky and should be quarantined. The flaky report artifact helps identify which tests need attention.
Measuring Pipeline Health
Track these metrics to understand and improve your pipeline feedback loops. Without measurement, you cannot improve.
- Pipeline duration — total time from trigger to completion. Target under 10 minutes for CI.
- Time to first feedback — how long until the first check reports. Linting should be under 2 minutes.
- Flaky test rate — percentage of tests that are intermittent. Target under 1%.
- Pipeline success rate — percentage of pipeline runs that pass on first try. Target above 95%.
- Mean time to recovery — how long until a broken pipeline is fixed. Track this for process improvement.
GitHub provides workflow run analytics in the Actions tab. GitLab offers pipeline analytics under CI/CD > Analytics. Use these built-in tools before investing in external monitoring — they already track duration, success rate, and failure reasons.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.