Pull request builds in Jenkins - Time & Space Complexity

Time Complexity: Pull request builds

O(n)

Understanding Time Complexity

We want to understand how the time to run pull request builds changes as the number of pull requests grows.

How does the system handle more pull requests and how does that affect build time?

Scenario Under Consideration

Analyze the time complexity of the following Jenkins pipeline snippet for pull request builds.

pipeline {
  agent any
  stages {
    stage('Build PRs') {
      steps {
        script {
          def prs = getOpenPullRequests()
          prs.each { pr ->
            build job: 'Build-Job', parameters: [string(name: 'PR_ID', value: pr.id)]
          }
        }
      }
    }
  }
}

This code gets all open pull requests and triggers a build job for each one.

Identify Repeating Operations

Look for loops or repeated actions in the code.

• Primary operation: Looping over each pull request to trigger a build.
• How many times: Once for each open pull request.

How Execution Grows With Input

The number of builds triggered grows as the number of pull requests grows.

Input Size (n)	Approx. Operations
10	10 build triggers
100	100 build triggers
1000	1000 build triggers

Pattern observation: The work grows directly with the number of pull requests.

Final Time Complexity

Time Complexity: O(n)

This means the time to trigger builds grows linearly as the number of pull requests increases.

Common Mistake

[X] Wrong: "Triggering builds for pull requests happens all at once and takes the same time no matter how many PRs there are."

[OK] Correct: Each pull request triggers a separate build, so more PRs mean more builds and more time overall.

Interview Connect

Understanding how build time scales with pull requests shows you can reason about system load and efficiency, a useful skill in real projects.

Self-Check

What if we changed the code to trigger builds only for pull requests updated in the last hour? How would the time complexity change?