Skip Unchanged Work with Vercel CI

Use Turborepo and Vercel CI to skip unchanged monorepo tasks.

Introduction

30 Second Summary

A tiny change in one app can make a shared pipeline repeat minutes of unrelated work. That delay adds up whenever every push rebuilds the whole project.

In this project, you will create a two-app monorepo on GitHub whose checks run through Turborepo. You will connect it to Vercel CI to compare a full run with runs that skip unchanged work.

What You'll Build

A one-line app change triggers a Vercel CI run where the dashboard shows the untouched app's tasks as skipped.

By the end of this project, you'll have:

An automated build-quality workflow for both apps. Every push runs its build task plus its lint task plus its test task.
A before-and-after run record that makes skipped work visible alongside the change in total time.
A controlled CI failure that pinpoints one broken test before a fixed push returns the pipeline to green.
Secret Mission: An optional challenge to push your CI optimisation skills further.

What do I need before starting?

You need GitHub and Vercel accounts. You also need Node with npx available on your computer.

Before We Start

Your Vercel CI runs will read project code from GitHub. Both services need to recognize your account before a run can start.

Git will track your files locally. Node.js supplies npx, which scaffolds the Turborepo later.

A terminal gives you one place to confirm that each local tool is available.

In this step, get ready to:

Prepare a terminal with Git access.
Install the Node.js toolchain.
Authenticate your GitHub plus Vercel browser sessions.

Prepare Git in your terminal

The terminal runs the commands that create your monorepo later. Your first check asks whether Git is already available there.

macOS

Press Cmd+Space to open Spotlight.
Type Terminal into the search field.
Press Return to open Terminal.

Windows

Press the Windows key to open Search.
Type Windows Terminal into the search field.
Press Enter to open Windows Terminal.

Linux

Open the application launcher for your Linux desktop.
Search for your terminal application.
Select the terminal application from the results.

Check whether your terminal can reach Git by running this command:

git --version

What Does This Command Check?

The command asks Git to print its installed version. A version line proves that the terminal can find the Git executable.

✔️ I see a version number

Your terminal can reach Git. Keep this terminal available for the remaining checks.

ⓧ Command not found

Git needs to be installed before the terminal can report a version. Choose your operating system below.

macOS

Open the official Git installation page for macOS in your browser.
Start the Xcode Command Line Tools installer by running this command:

xcode-select --install

What Does This Command Do?

This command asks macOS to install the Xcode Command Line Tools package. That package includes Git.

Complete the installer prompt shown by macOS.
Return to Terminal after the installation finishes.

Git is now available for the combined tool check later in this step.

Windows

Open the official Git installation page for Windows in your browser.
Download the standalone installer that matches your computer's processor.

The Git for Windows installer appears in your Downloads folder.

Run the downloaded installer.
Keep the default installation options.
Finish the installation.

The installer confirms that Git for Windows is installed.

Close Windows Terminal.
Reopen Windows Terminal through Windows Search.

The new terminal session can now detect Git during the combined tool check.

Linux

Open the official Git installation page for Linux in your browser.
Find the section for your Linux distribution.
Run the installation command shown in that section.

Your package manager reports when Git has finished installing.

Having Trouble Installing Git?

Confirm that you followed the instructions for your operating system. Linux installation commands differ between distributions.

Restart your terminal after the installer completes so it can detect the updated command path.

Help me install Git on my computer.

Install the Node.js toolchain

Node.js runs the JavaScript tools used by Turborepo. Its installer also provides npm plus npx.

Check whether Node.js is already available by running this command:

node --version

What Does This Command Check?

The command asks Node.js to print its installed version. A version line proves that your terminal can find the runtime.

✔️ I see a version number

Node.js is available in your terminal. The combined check below confirms its package tools too.

ⓧ Command not found

Open the official Node.js download page in your browser.
Choose the LTS installer for your operating system.

The Node.js installer appears in your Downloads folder.

Run the downloaded installer.
Keep the default installation options.
Finish the installation.

The installer confirms that Node.js has been installed.

Close your terminal application.
Reopen your terminal application through operating system search.

Still Missing Node.js?

Confirm that you downloaded the LTS installer for your operating system. Restart the terminal after the installer completes.

Help me diagnose my Node.js installation.

Before you run the combined check, how many version lines do you expect the terminal to print?

Verify the complete local toolchain by running these commands:

git --version
node --version
npm --version
npx --version

What Does This Tool Check Prove?

The first line confirms that Git is available for version control.
The second line confirms that Node.js can run JavaScript tooling.
The third line confirms that npm is available for package management.
The fourth line confirms that npx can run the Turborepo scaffolding tool later.

You should see four version lines. That is your local toolchain ready for the monorepo.

Missing One of the Version Lines?

Restart the terminal after each installation. A terminal opened before an installer finished may still use the old command path.

Reinstall Node.js from the LTS download if npm or npx is missing.

Help me fix my local tool check.

Authenticate your browser accounts

GitHub stores the monorepo that you create in the next step. Vercel connects to that repository when you enable CI.

✔️ I have a GitHub account

Open the GitHub sign-in page in your browser.
Enter your GitHub account details.
Complete any account verification requested by GitHub.

Your signed-in GitHub home page loads in the browser.

ⓧ I need a GitHub account

Open the GitHub sign-up page in your browser.
Create your GitHub account using the guided form.
Complete the verification requested by GitHub.

Your signed-in GitHub home page loads after registration.

Vercel can use your GitHub identity for account access. This keeps the repository connection tied to the account that owns your code.

Open the Vercel sign-up page in another browser tab.
Select Continue with GitHub.

GitHub shows an authorization screen when the accounts need to be connected.

Approve the access requested for your Vercel account.
Complete any remaining Vercel account details.

Your Vercel dashboard loads in the browser. No Vercel project has been created.

Before you make the final check, do you expect the repository form plus the Vercel dashboard to be available without creating a project?

Open the new repository page in your GitHub tab.
Confirm that the Owner field includes your personal GitHub account.
Confirm that the Create repository button is available.
Return to your Vercel dashboard tab.
Confirm that the dashboard remains signed in.

The GitHub form proves that your account can create a repository. The Vercel dashboard proves that your browser session is authenticated.

Your accounts are ready to carry the monorepo into CI. You have completed the access checks without creating a repository or CI project.

✔️ My setup matches

Your local tools plus browser sessions are ready for the project.

ⓧ I'd like to double check my setup

Your finished local development environment should match this state.

Confirm that Git is installed.
Confirm that Node.js is installed.
Confirm that terminal access is available.
Confirm that an authenticated GitHub browser session is open.
Confirm that an authenticated Vercel browser session is open.
Confirm that no monorepo or CI project exists yet.

Your development environment is ready. Next, you will scaffold the two-app monorepo plus push it to GitHub.

Create and Push the Monorepo

A CI system can only skip unchanged work when it can separate one app's tasks from another app's tasks. A monorepo gives those apps one home while preserving their workspace boundaries.

You will scaffold a two-app Turborepo locally. You will publish the initial project to GitHub so Vercel can connect to it in the next step.

In this step, get ready to:

Scaffold a Turborepo containing the web app plus the documentation app.
Register build, lint, and test tasks across both workspaces.
Publish the initial monorepo commit to GitHub.

Scaffold the two-app workspace

The Turborepo scaffolder creates the workspace structure plus the shared configuration. Its starter includes applications at apps/web and apps/docs.

Return to the terminal from your setup.
Move to your Desktop by running this command:

cd ~/Desktop

Why Use the Desktop?

The Desktop gives ci-skip-demo a predictable location. You can find the project without tracing whichever folder the terminal started in.

The first scaffold downloads the starter plus its dependencies. The terminal may stay busy while npm prepares the workspace.

Approve the npm download by entering y if the first run asks for permission.
Create ci-skip-demo with npm by running this command:

npx create-turbo@latest ci-skip-demo --package-manager npm

What Does This Command Create?

The scaffolder creates the ci-skip-demo monorepo on your Desktop.
The npm option creates the workspace metadata plus the dependency lockfile for npm.
The starter places the two applications inside the apps directory.

Enter the new monorepo directory by running these commands:

cd ci-skip-demo
ls apps

What Does This Check?

The first command moves your terminal into ci-skip-demo. The second command lists the application workspaces created by the starter.

You should see docs plus web in the output. Good progress. Your local monorepo now has two separate applications.

Are the App Folders Missing?

Confirm that the scaffold command finished without a network or permission error. Check that your terminal is inside the ci-skip-demo directory before listing apps.

Remove an incomplete project folder before repeating the scaffold. This prevents the scaffolder from writing into a partially created workspace.

Help me diagnose my Turborepo scaffold.

Register the CI tasks

Each workspace script defines the command an app can perform. The root task graph tells Turborepo how to find that script across the monorepo.

The starter already provides build plus lint scripts. You will add a test entry point to both apps before registering it in turbo.json.

Add a test script to both app workspaces by running these commands:

npm pkg set scripts.test="node --test" --workspace=web --workspace=docs
npm pkg set scripts.test="turbo run test"

How Do the Test Scripts Connect?

The app-level script starts the built-in Node.js test runner. The root script asks Turborepo to run that script in every workspace that defines it.

This gives both apps the same task name. Turborepo can now schedule each app's test work separately.

node -e "const fs = require('node:fs'); const path = 'turbo.json'; const config = JSON.parse(fs.readFileSync(path, 'utf8')); config.tasks.test = {}; fs.writeFileSync(path, JSON.stringify(config, null, 2) + '\n');"

What Does This Configuration Change?

The command reads turbo.json before adding a task named test. It writes the updated task graph back to the same file.

An empty task configuration uses Turborepo's default inputs. Changes inside one app can therefore affect that app's test task without changing the other app's task.

✔️ Awesome, I've got everything!

Your workspace scripts plus the root task graph are ready. The next run proves that Turborepo can find all three task types.

ⓧ I'd like to double check the full code

Your complete turbo.json contains the starter tasks plus the new test task.

{
  "$schema": "https://turborepo.dev/schema.json",
  "ui": "tui",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", ".env*"],
      "outputs": [".next/**", "!.next/cache/**", "!.next/dev/**"]
    },
    "lint": {
      "dependsOn": ["^lint"]
    },
    "check-types": {
      "dependsOn": ["^check-types"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    },
    "test": {}
  }
}

Before you run the task graph, which app names do you expect to appear under build, lint, and test?

Run all three task types from ci-skip-demo with these commands:

npm run build
npm run lint
npm run test

What Does This Task Run Prove?

The build command compiles both applications through the root Turborepo script.
The lint command checks both application workspaces.
The test command reaches the new script in web plus docs.

You should see successful build, lint, and test tasks for both apps. The test runner reports zero discovered test files while confirming that each workspace test script is runnable.

Does a Task Fail?

Check that your terminal remains inside the ci-skip-demo directory. Running the root scripts from the Desktop prevents npm from finding the monorepo's package.json.

Confirm that test appears inside the tasks object in turbo.json. Confirm that both app package files contain the test script.

Help me diagnose my monorepo tasks.

Publish the initial commit

A Git commit records the working monorepo as one version. Pushing that commit gives Vercel a repository it can connect to.

Switch back to the signed-in GitHub browser tab from your setup.
Select the menu in the upper-right corner of the GitHub header.
Click New repository.
Select your account from the Owner menu.
Enter ci-skip-demo in the Repository name field.
Choose your preferred repository visibility.
Leave Add README disabled.

Why Start With an Empty Repository?

Your local project already contains its starter files plus Git history. An empty GitHub repository avoids an extra remote commit that could conflict with the local branch.

Leave Add .gitignore unset.
Leave Choose a license unset.
Click Create repository.
Copy the repository URL from the Quick Setup page.
Record the copied URL here: https://github.com/YOUR_USERNAME/ci-skip-demo.git.

Return to the terminal inside ci-skip-demo.
Stage the monorepo files plus create the initial project commit by running these commands:

git add .
git commit -m "First commit"

What Did Git Record?

The first command stages the scaffold plus your task configuration. The second command saves that staged state as a commit that can be pushed to GitHub.

Connect the local repository to the GitHub repository by running these commands:

git remote add origin [[GITHUB_REPO_URL="https://github.com/YOUR_USERNAME/ci-skip-demo.git"]]
git remote -v

What Does the Remote Represent?

The remote named origin points at your GitHub repository. The verification command prints the destination Git uses for fetching plus pushing.

Before you push, what two app folders do you expect GitHub to show after the upload finishes?

Push the current branch plus set its upstream destination by running this command:

git push --set-upstream origin HEAD

What Does the Push Do?

The command uploads your current commit to origin. Setting the upstream lets future pushes use the same remote branch.

The terminal should confirm that the branch reached the remote repository. Complete GitHub's authentication flow if your terminal requests access.

Return to the ci-skip-demo repository page in your browser.
Refresh the repository page.
Select the apps directory.

You should see docs plus web in the GitHub file list. The initial commit now contains the two-app monorepo plus its build, lint, and test task wiring.

Did the Push Fail?

Confirm that the copied repository URL belongs to your ci-skip-demo repository. A URL for another repository sends Git to the wrong destination.

Complete any authentication request from GitHub before repeating the push. Repository permission errors require access through the account that owns the new repository.

Help me diagnose my GitHub push.

That's the foundation in place. Your two-app monorepo now runs its task graph locally plus lives on GitHub.

Next, you will connect this repository to Vercel and start its first CI run.

Enable Vercel CI

Your Turborepo workspace is already on GitHub. It now needs a Vercel connection before pushes can launch Vercel CI.

You will import the repository as a Vercel project. You will enable CI for that connected repository before finding the first run.

In this step, get ready to:

Connect the GitHub repository to a Vercel project.
Check the Vercel CLI version required for CI.
Start the first CI run in the Vercel dashboard.

Connect the GitHub repository

A Vercel project gives CI a team-owned connection to your repository. Vercel CI needs at least one connected project before it can run repository tasks.

Switch back to the Vercel dashboard in the browser from earlier.
Select the Vercel team that should own your project.
Click Create New in the dashboard.
Select Project.
Find ci-skip-demo under Import Git Repository.
Click Import beside ci-skip-demo.
Grant Vercel access to ci-skip-demo if GitHub opens a permission screen.

Why Connect One App?

The Vercel project can use apps/web as its deployment root. Vercel CI still evaluates tasks across the connected repository.

One project connection gives the repository the Vercel team ownership that CI needs.

Confirm the project name shows ci-skip-demo.
Click Edit beside Root Directory.
Select apps/web.
Click Deploy.
Wait for the ci-skip-demo project dashboard to load.

Good progress. ci-skip-demo now has the project connection Vercel CI requires.

Prepare the Vercel CLI

The Vercel CLI turns repository-level CI on. Vercel CI requires version 64.3.1 or later.

Return to the terminal from earlier inside your local ci-skip-demo folder.
Check the installed Vercel CLI version by running this command:

vercel --version

What Does This Check?

The command reports the installed Vercel CLI version. A result of 64.3.1 or higher includes the required CI commands.

✔️ I see version 64.3.1 or higher

You're set. Your Vercel CLI can manage Vercel CI for this repository.

ⓧ I see an older version

An older Vercel CLI does not include the required CI commands. Updating replaces the global package with the latest published version.

Update the Vercel CLI by running this command:

npm i -g vercel@latest

What Does This Install?

The command replaces the global Vercel CLI package with the latest published version.

The global installation makes the vercel command available from your project folder.

Confirm the updated version by running this command:

vercel --version

What Confirms the Update?

The command reads the version from the updated global installation.

You should now see version 64.3.1 or higher.

Does the Update Fail?

If npm reports a permissions problem, use its official permissions guidance for your platform.

Confirm that Node.js remains available in this terminal session.

Help me fix the Vercel CLI update. You can also ask the Vercel Community.

ⓧ Command not found

The Vercel CLI is not installed globally. Installing the latest package adds the command required to enable CI.

Install the Vercel CLI by running this command:

npm i -g vercel@latest

What Does This Install?

The command installs the latest Vercel CLI package globally.

The global installation makes the vercel command available from your project folder.

Confirm the installation by running this command:

vercel --version

What Confirms the Installation?

The command reports the version of the newly installed Vercel CLI.

You should now see version 64.3.1 or higher.

Is the Command Still Missing?

Restart your terminal if the installation succeeds but the command remains unavailable. This reloads the command search path.

Help me find the installed Vercel CLI. You can also ask the Vercel Community.

Start the first CI run

The CLI uses the repository's Git remote to identify the connected GitHub repository. Authentication lets the command update its Vercel CI setting.

Authenticate the Vercel CLI by running this command:
Complete the browser confirmation with the Vercel account from earlier when prompted.

vercel login

What Does This Command Do?

The command starts an interactive Vercel sign-in. It connects the terminal session to your Vercel account without placing a credential in the project files.

The terminal confirms the authenticated Vercel account when the sign-in finishes.

Does Authentication Stall?

Return to the browser confirmation page if the terminal is still waiting. Confirm that you are using the same Vercel account that owns the new project.

Help me complete Vercel CLI authentication. You can also ask the Vercel Community.

A team picker can appear while CI is being enabled. Choose the team that owns the ci-skip-demo Vercel project.

Enable Vercel CI for the connected repository by running this command:
Select the team that contains ci-skip-demo if the CLI asks you to choose one.

vercel ci enable

What Does This Command Enable?

The command enables Vercel CI for the repository identified by its Git remote. The connected Vercel project supplies the required team ownership.

CI can now schedule the repository tasks whenever Vercel receives a supported push.

The terminal confirms that Vercel CI is enabled for the repository.

Before you check the dashboard, do you expect the current commit to appear immediately?

Switch back to the ci-skip-demo project in the Vercel dashboard.
Select the CI tab.
Locate the first run associated with the initial commit.

You will see the initial-commit run in the dashboard. Its activity shows that the first CI run has started.

Why Is the First Run Important?

This run proves that Vercel can read the repository's Turborepo task graph. It also establishes the baseline that later runs can compare against.

Is the First Run Missing?

Refresh the CI tab. Confirm that the Vercel project belongs to the same team selected by the CLI.

Confirm that ci-skip-demo remains connected to its GitHub repository.

Help me find the missing Vercel CI run. You can also ask the Vercel Community.

Your repository is connected. Its first CI run is moving through Vercel. Next, you will let that full run finish before recording its baseline.

Record the Full CI Run

The first Vercel CI run is already in motion from the initial commit. This gives you the untouched starting point for the whole comparison.

Turborepo has no earlier task results to reuse for this fresh run. The completed run becomes your full-run baseline.

In this step, get ready to:

Watch run 1 finish successfully.
Account for every configured task.
Record the total duration plus the skipped-task count.

Let the first run finish

The first pass has the most work because no previous task result can be reused. A live task list can keep changing until the run finishes.

Switch back to the browser tab showing the Vercel dashboard from earlier.
Select the CI run for the initial commit.
Wait for the overall run to finish.

You should see a successful overall result for the initial commit.

That first run is complete. You now have a stable result to measure later runs against.

Capture the full-run baseline

A full-run baseline starts with the total duration. This tells you how long the complete workload took.

The executed-task list records the work Vercel CI completed. The skipped-task count shows how much work it reused.

Before you inspect the final task list, do you expect this first run to skip anything?

Locate the total duration in the completed run details.
Record the displayed value here: your run 1 total duration.
Review every task result for apps/web.
Review every task result for apps/docs.
Record the executed-task list here: your run 1 executed-task list.
Count the task results marked as skipped.
Record the skipped-task count here: your run 1 skipped-task count.

You should see six completed task results. Run 1 should show no skipped work.

Run 1 Task Inventory

The apps/web build task completed.
The apps/web lint task completed.
The apps/web test task completed.
The apps/docs build task completed.
The apps/docs lint task completed.
The apps/docs test task completed.
The skipped-task count is 0.

Missing One of the Six Tasks?

Confirm that you are viewing the initial-commit run for ci-skip-demo.
Check whether any task ended before completion.

Help me diagnose a missing task in run 1.

The checkpoint below stores these values as the baseline entry in your CI run comparison record.

Your baseline now captures the full workload plus its duration. Next, you will make a one-app change to reveal which tasks Vercel CI can skip.

Push a One-App Change

Run 1 proved that every configured task could finish in Vercel CI. It also established your full-run baseline.

Now you need evidence that unchanged work can disappear from the next run. A one-line edit inside apps/web gives Turborepo one changed workspace to evaluate.

Publishing that controlled edit through GitHub starts the second run. Its task results reveal whether the workspace boundary works.

In this step, get ready to:

Make one application-line change inside apps/web.
Publish the isolated change to GitHub.
Verify that run 2 skips tasks for apps/docs.

Change one line in the web app

This experiment depends on a clean workspace boundary. Only apps/web should contain a new edit.

Use a text editor to expand the apps/web folder inside ci-skip-demo.
Select an application source file that contains visible page copy.
Replace one existing line of page copy with Web app changed for CI run 2.
Save the file.
Return to the terminal in the ci-skip-demo folder from earlier.
Confirm that the edit is isolated to apps/web by running these commands:

git status --short
git diff -- apps/web

What Do These Commands Prove?

The first command lists every changed path in a compact format.
The second command limits the diff to apps/web.
Together they confirm that the experiment changes one app.

You should see one modified path under apps/web. Its diff should show one removed line plus one added line.

Do You See Extra Changes?

Revert any unrelated edits before continuing. Confirm that no path under apps/docs appears in the status output.

If the diff contains several changed lines, undo those extra edits in your text editor. Save the file before running both checks again.

Help me isolate extra files from my one-line web app change.

Commit and push the isolated change

The Git staging area controls what enters a commit. Staging only apps/web keeps this CI experiment focused.

Publish the isolated web change by running these commands:

git add apps/web
git commit -m "Change web app copy"
git push

What Does This Sequence Do?

The first command stages changes found under apps/web.
The second command records the staged snapshot with the message Change web app copy.
The final command publishes the commit to the current branch on GitHub.

Return to the ci-skip-demo repository on GitHub in your browser from earlier.
Confirm that the newest commit message reads Change web app copy.

The repository now shows your second commit. That push starts Vercel CI run 2.

Did the Push Fail?

Confirm that the terminal is inside ci-skip-demo. A command run from another folder cannot publish this repository.

A rejected push can mean the remote branch has newer commits. Avoid forcing the push because that can overwrite remote history.

Help me diagnose my failed Git push.

Verify the skipped docs tasks

Run 2 compares each task's inputs with the baseline. This check reveals whether unchanged work stays out of the execution path.

Before you inspect run 2, which app do you expect to perform work?

The run may stay active for a few minutes while its tasks finish. That pause means CI is still evaluating the commit.

Return to the Vercel project ci-skip-demo in your browser from earlier.
Select the newest CI run associated with Change web app copy.
Wait for the run to finish.
Inspect the task results for apps/web to identify which tasks ran.
Inspect the task results for apps/docs to identify which tasks were marked skipped.

You should see relevant apps/web tasks completed. You should see unaffected apps/docs tasks marked skipped.

That's the key result. Your one-app edit avoided unnecessary work for the untouched app.

Did the Docs Tasks Run?

Check the commit on GitHub for changes outside apps/web. A changed shared file can affect both apps.

If only the web app changed, review the task input configuration from earlier. Inputs that cover the whole repository can make the docs tasks eligible to run.

Help me understand why the docs tasks were not skipped.

Count the task results marked skipped.
Note the total duration for run 2.

What Should the Run 2 Record Contain?

The total duration shown for run 2.
The executed tasks associated with apps/web.
The skipped tasks associated with apps/docs.
The total number of skipped tasks.

Complete the run 2 entry in your CI run comparison record using the four values above.

You now have proof that a one-app change can produce a smaller CI run. Next, you will break one test on purpose before restoring the pipeline to green.

Test a Failure and Fix

The previous Vercel CI run proved that Turborepo can skip untouched work in your monorepo. A successful pipeline still needs to show where a real defect lives.

Now you will challenge that safety net with a controlled test failure. A separate Git commit keeps the experiment easy to trace.

In this step, get ready to:

Introduce a controlled failure in apps/web.
Identify the single failed task in Vercel CI.
Restore the passing test state through a later commit.

Create a controlled test failure

A test compares actual behavior with an expected result. Changing only the expected value creates a focused defect while the application code stays unchanged.

Return to the code editor you used for the earlier apps/web change.
Use the editor search to locate an existing test assertion inside apps/web.
Select one passing assertion with a literal expected value.
Replace the expected value with a value that the application does not produce.
Save the test file.
Confirm that only the intended test file changed by running this command:

git status

What Does This Command Show?

The git status command reports files that differ from the latest commit.
The result lets you catch accidental edits before creating the failure commit.

You should see one modified test file under apps/web. This proves the deliberate edit stays inside the web app.

Before you publish the change, which task do you expect CI to identify as the cause? Keep that prediction in mind.

Publish the deliberate test failure by running these commands:

git add apps/web
git commit -m "Break web test intentionally"
git push

What Do These Commands Do?

The git add apps/web command stages changes from the web app only.
The git commit -m "Break web test intentionally" command records the planned failure in its own commit.
The git push command sends that commit to the connected repository.

Did the Push Fail?

Confirm that the terminal is inside the local ci-skip-demo folder.
Check that the commit was created before retrying the push.
Confirm that the current branch still has its remote tracking branch.

Help me diagnose the failed Git push.

Trace the failed CI task

The run task list separates the cause from work that completed or skipped. The focused failure should lead back to the assertion you changed.

Before you inspect the new run, consider whether one task or several tasks will fail. Use your earlier prediction as the comparison point.

Return to the ci-skip-demo project in Vercel from earlier.
Select the newest CI run from the project run list.
Wait for the run to finish.
Open the failed task details.
Find the assertion failure caused by the expected value you changed.

You will see the apps/web test task identified as the only failed task. The assertion details point to your intentional mismatch.

What Does the Failed Run Prove?

The failed task identifies apps/web as the source of the defect. Other tasks remain successful or skipped.

Good. The planned failure has shown that the pipeline can isolate a broken test.

Does the Wrong Task Fail?

Confirm that the newest repository commit uses the message Break web test intentionally.
Check that the changed assertion still contradicts the application's actual value.
Return to the newest run triggered by that commit.

Help me trace the unexpected CI result.

Restore the passing test

Each Git commit preserves a project snapshot. The parent of the broken commit contains the passing apps/web test plus your earlier one-line application change.

Return to the terminal in the local ci-skip-demo folder.
Restore the previous apps/web snapshot by running these commands:

git restore --source=HEAD~1 -- apps/web
git status

How Does the Restore Work?

The HEAD~1 revision selects the parent of the current broken-test commit.
The -- apps/web path limits the restoration to the web workspace.
The final git status command reports the restored test file as modified.

The output lists the test file under apps/web as modified. Its content now matches the passing snapshot from before the planned failure.

Did the Restore Miss the Test?

Confirm that the terminal is inside the local ci-skip-demo folder.
Check that the broken-test commit is the current HEAD.
Confirm that the modified file shown by the status command belongs to apps/web.

Help me restore the passing web test.

Commit the restored test state by running these commands:

git add apps/web
git commit -m "Restore passing web test"
git push

Why Does This Commit Fix the Run?

The staging command includes the restored test file in the next commit.
The commit records the passing state after the deliberate failure.
The push triggers another CI run for the fixed repository state.

Before you inspect the replacement run, consider whether the same test task will pass after the snapshot is restored. Keep the earlier assertion failure in mind.

Return to the ci-skip-demo project in Vercel.
Select the newest CI run triggered by Restore passing web test.
Wait for the run to finish.
Inspect the relevant apps/web task results.

You will see the relevant apps/web tasks complete successfully. The run no longer reports the intentional assertion mismatch.

That is the recovery proven. The latest run is green after the test fix.

Is the Fixed Run Still Failing?

Confirm that the newest repository commit uses the message Restore passing web test.
Open the failing apps/web task details to identify the remaining assertion.
Compare the local test file with the passing version from the commit before the deliberate failure.

Help me diagnose the fixed CI run.

You now have evidence from four CI runs. Next, you will compare their durations plus skipped-task counts in one table.

Compare CI Results

Your deliberate test failure pinpointed the apps/web test task. The repaired test then produced a green Vercel CI run.

Separate runs make the pattern hard to scan. A four-column comparison turns those results into evidence of how Turborepo skips unchanged work.

In this step, get ready to:

Capture the final fixed-test run results.
Assemble a comparison table for all three successful runs.
Verify the duration change plus the skipped-task pattern.

Capture the final run

The fixed-test run closes the timeline with a successful result after the deliberate failure. Its duration plus skipped-task count complete the evidence for your comparison.

Switch back to the Vercel dashboard from earlier.
Select the successful run triggered by the test-fix commit.

You should see a green run with the relevant apps/web tasks completed successfully.

Record the total duration here: your fixed-test run duration.
Count the tasks marked as skipped in that run.
Record the skipped-task count here: your fixed-test skipped-task count.

Use one view for every run

A fair comparison gives every run the same fields. This keeps the table focused on outcome, elapsed time, plus avoided work.

What Does Each Column Show?

The Run column identifies the change scenario.
The Outcome column records whether CI succeeded or failed.
The Total duration column records the elapsed time.
The Skipped-task count column measures how much work CI avoided.

Return to the CI run comparison record from earlier.
Create a four-column table using the fields above.

The empty table now gives every run the same measurement frame.

Add the recorded run 1 values to the Full run row.
Add the recorded run 2 values to the apps/web-only change run row.

The first two rows now place the full baseline beside the web-only change.

Record successful in the fixed-test run's Outcome cell.
Add your fixed-test run duration to the fixed-test run's Total duration cell.

The final row now shows the green outcome plus its elapsed time.

Add your fixed-test skipped-task count to the fixed-test run's Skipped-task count cell.
Confirm the failed-test diagnostic remains below the comparison table.

Your record now contains the three-run comparison. It still preserves the diagnostic that identified the deliberate apps/web test failure.

Read the pattern across runs

Before you compare the rows, which run do you expect to show the clearest reduction in repeated work?

Compare the total duration in the Full run row with the apps/web-only change run row.
Confirm the web-only row shows a lower total duration.
Confirm its skipped-task count reflects the untouched apps/docs tasks.
Verify every row contains values across all four columns.
Confirm the retained diagnostic identifies the deliberate apps/web test failure.

The table now contains three complete rows. The web-only row shows a shorter duration plus skipped work for apps/docs.

The fixed-test row is successful. The retained diagnostic still identifies the earlier test failure.

Your comparison now proves that the web-only change avoided untouched work. It also preserves the failed-test diagnostic beside the final green recovery.

Secret mission

Audit Your CI Skip Efficiency

Turn the three recorded runs into a skip-rate audit. Compare avoided tasks with each run's duration. Define a warning rule for future one-app changes.

Clean Up Your Resources

Choose whether to keep the project connected, pause new CI runs, or remove every copy. Your cost check only applies to Vercel CI because the local folder creates no ongoing charges.

Cost warning

Vercel CI is in beta. If you use a paid plan, check your usage before keeping CI enabled.

The beta may be billed later. The Pause and Delete options below prevent new runs from this project.

Resources you used:

The Vercel project ci-skip-demo with Vercel CI enabled.
The GitHub repository ci-skip-demo containing your complete commit history.
The local ci-skip-demo folder containing your Turborepo workspace.

Keep everything running

No action needed. Choose this if you want to reuse the monorepo as a template for future CI experiments.

Keep the local ci-skip-demo folder as your editable workspace.
Keep the GitHub repository as your remote template.
Leave the Vercel project connected to the repository.
Review your current Vercel usage to decide whether keeping CI enabled fits your plan.

Pause - I'll come back to this later

Switch off automated CI runs while preserving your code. Your local folder and GitHub history stay ready for another session.

Return to the signed-in Vercel browser session from earlier.
Select ci-skip-demo from the project list.
Enter the settings area for that project.
Locate the Vercel CI configuration.
Switch Vercel CI off.
Confirm that the configuration shows CI as disabled.

New pushes should no longer start Vercel CI runs for this project. Your saved workspace remains intact.

Delete - I don't want to use this again

Remove all project resources to start fresh. This looks drastic, but each resource is handled separately so you can stop before the local folder is removed.

Delete the Vercel project

Return to the signed-in Vercel browser session from earlier.
Select ci-skip-demo from the project list.
Enter the settings area for that project.
Scroll to the area containing the permanent project deletion control.
Choose the control that deletes the project.
Complete the confirmation check shown for ci-skip-demo.
Approve the permanent deletion.

You should no longer see ci-skip-demo in your Vercel project list. This removes its CI configuration before you delete the source repository.

Delete the GitHub repository

Return to the signed-in GitHub browser session from earlier.
Select the ci-skip-demo repository.
Enter the repository settings area.
Scroll to the section containing permanent repository actions.
Choose the control that deletes the repository.
Complete the confirmation check shown for ci-skip-demo.
Approve the permanent deletion.

You should no longer see ci-skip-demo in your GitHub repository list. Your remote commit history is now removed.

Delete the local folder

Select your operating system below to remove the final copy of the workspace.

macOS

Close any terminal window currently using the ci-skip-demo folder.
Open your macOS file browser.
Navigate to the parent folder where you created ci-skip-demo.
Move the ci-skip-demo folder to your deleted items.
Empty your deleted items to remove the folder permanently.

You should no longer see ci-skip-demo in its parent folder. That completes the local cleanup.

Windows

Close any terminal window currently using the ci-skip-demo folder.
Open your Windows file browser.
Navigate to the parent folder where you created ci-skip-demo.
Move the ci-skip-demo folder to your deleted items.
Empty your deleted items to remove the folder permanently.

You should no longer see ci-skip-demo in its parent folder. That completes the local cleanup.

Linux

Close any terminal window currently using the ci-skip-demo folder.
Open your Linux file browser.
Navigate to the parent folder where you created ci-skip-demo.
Move the ci-skip-demo folder to your deleted items.
Empty your deleted items to remove the folder permanently.

You should no longer see ci-skip-demo in its parent folder. That completes the local cleanup.

Nice Work!

You did it! You built a two-app Turborepo monorepo that uses Vercel CI to skip unchanged work. Your comparison record proves the pipeline can isolate a failed test before returning to green.

You've learned how to:

Create a two-app monorepo on GitHub. Configure build tasks for both apps. Add lint tasks for both apps. Add test tasks for both apps.
Prove that unchanged work gets skipped after changing only apps/web. Compare each run's duration. Compare the skipped-task counts across all three runs.
Trace an intentional test failure to the apps/web test task. Fix the test. Confirm Vercel CI returns to green.
Secret Mission: Complete an optional challenge that extends your CI workflow.

Ready to quiz yourself?