How Threadline Detects Code Changes

Threadline automatically detects your CI/CD environment and gathers the appropriate code changes (diff) for analysis. Understanding what changes are included helps you know exactly what your threadlines are testing.

Each environment has a specific strategy optimized for that platform's capabilities and limitations.

GitHub Actions

GitHub Actions provides rich context about PRs and branch pushes. Threadline handles four scenarios:

1. Pull Request Context

When: GITHUB_EVENT_NAME="pull_request"

What's included: All changes in the PR (target branch vs source branch)

How: Compares origin/{GITHUB_BASE_REF}...origin/{GITHUB_HEAD_REF}

This shows the cumulative changes across all commits in the PR, giving you complete coverage of what's being merged.

2. Merge Commit to Default Branch

When: Push event to default branch (e.g., main), merge commit

What's included: All changes that were merged in

How: Compares origin/default~1...origin/default

This captures all changes introduced by the merge, ensuring threadlines validate everything that entered the default branch.

3. Feature Branch Push

When: Push event to a feature branch (not default branch)

What's included: Cumulative changes in feature branch vs default branch

How: Compares origin/default...origin/{GITHUB_REF_NAME}

This shows all commits in the feature branch compared to the default branch, giving you full branch-level coverage.

4. Direct Commit to Default Branch

When: Push event to default branch, non-merge commit

What's included: Changes in the direct commit

How: Compares origin/default~1...origin/default

This validates direct commits to the default branch, ensuring even hotfixes are checked.

Note: Default branch detection uses GITHUB_EVENT_PATHto read repository.default_branch, so it works even if your default branch isn't named "main".

GitLab CI

GitLab CI performs shallow clones (only the current branch), so Threadline fetches additional branches on-demand when needed.

1. Merge Request Context

When: CI_MERGE_REQUEST_IID is set

What's included: All changes in the MR (target branch vs source branch)

How: Fetches target branch, then compares origin/{CI_MERGE_REQUEST_TARGET_BRANCH_NAME}...origin/{CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}

The target branch is fetched on-demand since GitLab only clones the source branch by default.

2. Feature Branch Push

When: Push to feature branch (CI_COMMIT_REF_NAME != CI_DEFAULT_BRANCH)

What's included: Cumulative changes in feature branch vs default branch

How: Fetches default branch, then compares origin/{CI_DEFAULT_BRANCH}...origin/{CI_COMMIT_REF_NAME}

The default branch is fetched on-demand for comparison, ensuring you see all changes relative to main.

3. Default Branch Push

When: Push to default branch (CI_COMMIT_REF_NAME == CI_DEFAULT_BRANCH)

What's included: Changes in the last commit

How: Compares HEAD~1...HEAD

No fetch needed since we're already on the default branch. This shows the changes in the most recent commit.

Vercel

When: Vercel build/deployment

What's included: Changes in the commit being deployed

How: Uses git show {VERCEL_GIT_COMMIT_SHA}

Vercel provides the commit SHA being deployed via VERCEL_GIT_COMMIT_SHA. Threadline shows the diff for that specific commit, validating what's being deployed.

Note: Vercel's CI environment only provides the current commit context, not branch comparisons. This means you'll see the commit-level changes, not cumulative branch changes.

Local Development

When: Running threadlines check locally

What's included: Staged changes (if any), otherwise unstaged changes

How:

  • Priority 1: git diff --cached (staged changes)
  • Priority 2: git diff (unstaged changes)

This allows you to review what you've staged before committing, or review unstaged changes if nothing is staged. Perfect for catching issues before they reach your CI pipeline.

Understanding Your Test Coverage

The diff detection strategy directly impacts what your threadlines test:

  • PR/MR context: Tests all changes that will be merged, giving you complete coverage of the feature
  • Branch pushes: Tests cumulative changes in the branch vs default, showing the full scope of work
  • Commit-level (Vercel, direct commits): Tests individual commits, useful for validating specific changes
  • Local (staged/unstaged): Tests your work-in-progress, catching issues before commit

Each threadline filters the diff to only include files matching its patterns. This means:

  • A threadline for *.ts files won't see changes to *.md files
  • If no files match a threadline's patterns, that threadline is marked as "not relevant"
  • You can see exactly which files were sent to each threadline in the check details page

Context Lines

Threadline requests 200 lines of context around each change (-U200) to give the LLM sufficient surrounding code for accurate analysis. The diff viewer in the UI shows only the changes by default, with an option to expand and see the full context.