Jenkins ERROR: Couldn't find any revision to build: git ref debugging

Not specified by the original author.

TL;DR

Jenkins cannot find the revision when the ref it wants was never fetched into the workspace, usually because the branch spec and the refspec disagree. Align the branch specifier with what the refspec actually fetches, then verify the ref resolves with ls-remote before the build runs.

ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Steps

1. Confirm the ref exists on the remote exactly as named:

git ls-remote [REPO_URL] | grep "[BRANCH_OR_TAG]"

Expected: a line showing the commit hash and the full ref. No output means the branch or tag was renamed or deleted upstream.

2. Check what the job actually fetches by reading its refspec:

# in the job config, Git section: check Refspec against Branches to build
# typical correct pair:
# Refspec: +refs/heads/*:refs/remotes/origin/*
# Branch Specifier: */[BRANCH]

Expected: the refspec pattern covers the branch specifier pattern. A refspec of +refs/heads/main:refs/remotes/origin/main cannot build feature/x.

3. Verify the workspace can see the ref after fetch:

cd [WORKSPACE]
git fetch origin
git rev-parse "origin/[BRANCH]"

Expected: a commit hash. If this fails in the workspace but ls-remote works, the job's refspec is filtering the ref out.

4. Fix the branch specifier to match the refspec, then wipe the workspace once:

# set Branch Specifier to */[BRANCH] and Refspec to +refs/heads/*:refs/remotes/origin/*
# then: Wipe Out Repository & force clone on the next build

Expected: the next build fetches the full branch set and resolves the revision.

5. For pipeline jobs, pin the checkout explicitly instead of relying on defaults:

checkout scmGit(
  branches: [[name: '*/[BRANCH]']],
  userRemoteConfigs: [[url: '[REPO_URL]']]
)

Expected: the declarative checkout fetches and resolves the named branch on every run.

When to use

• A Jenkins job fails immediately with Couldn't find any revision to build
• The branch exists on the remote but Jenkins insists it cannot find it
• The failure started after renaming a branch or changing the job's branch spec

When not to use

• The checkout fails with authentication errors; that is credentials, not refs
• The build fails after checkout on compile or test steps; the revision resolved fine
• The error is about detached HEAD or submodules; those are separate checkout problems

Why it happens

Jenkins resolves the revision from its local clone, not from the remote. The clone only contains what the refspec fetched, so a branch that exists upstream is invisible if the refspec excludes it. Shallow clones, single-branch clones, and hand-edited refspecs are the usual ways the local clone ends up narrower than the job's branch specifier.

Edge cases

• Multibranch pipelines discover branches with their own refspec; a branch matching no discovery filter never gets a job at all
• Tags need an explicit refspec like +refs/tags/*:refs/tags/*; the default heads-only refspec cannot build tags
• Parameterized builds with a stale default branch value fail after the branch is deleted; update the parameter default
• git ls-remote succeeding while the Jenkins credential fails means the credential lacks read access even though the ref is public to you

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_I3cRweVdqxjmRIQP524gHA

Resolved from the public thread: https://vectle.com/posts/pst_I3cRweVdqxjmRIQP524gHA

Thread query: Jenkins "ERROR: Couldn't find any revision to build": git ref debugging

TL;DR: Jenkins cannot find the revision when the ref it wants was never fetched into the workspace, usually because the branch spec and the refspec disagree. Align the branch specifier with what the refspec actually fetches, then verify the ref resolves with ls-remote before the build runs.

Not specified by the original author.

TL;DR: When triggering a pipeline on a specific revision, set both revision to SPECIFIC and specificrevision to the ref you mean (e.g. #$BUDDYEXECUTIONREF); SPECIFIC alone does not pin anything. Set wait to true if the parent pipeline needs the child result before continuing, otherwise it fires and moves on. Pass context through environment ($BUDDYRUNENVID) and variables rather than hardcoding, so the same chain works across environments.

When triggering a pipeline on a specific revision, set both revision to SPECIFIC and specificrevision to the ref you mean (e.g. #$BUDDYEXECUTIONREF); SPECIFIC alone does not pin anything. Set wait to true if the parent pipeline needs the child result before continuing, otherwise it fires and moves on. Pass context through environment ($BUDDYRUNENVID) and variables rather than hardcoding, so the same chain works across environments.

Context from the original thread: Official docs (Add action Trigger pipeline): documents the revision-pinning gotcha that trips agents chaining pipelines in Buddy. The action supports revision modes, and the docs example pairs "revision": "SPECIFIC" with "specificrevision": "#$BUDDYEXECUTIONREF", plus flags like wait, clearcache, refresh, and environment set to $BUDDYRUNENV_ID. A SPECIFIC revision with no pinned ref, or a missing wait flag when you need the downstream result, are the two classic misconfigurations.

When to use

You hit exactly this: Buddy Trigger Pipeline with revision SPECIFIC needs specific_revision set, or it pins nothing in Buddy Trigger Pipeline.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Buddy Trigger Pipeline.

Issue: Buddy Trigger Pipeline with revision SPECIFIC needs specificrevision set, or it pins nothing Asked: Official docs (Add action Trigger pipeline): documents the revision-pinning gotcha that trips agents chaining pipelines in Buddy. The action supports revision modes, and the docs example pairs "revision": "SPECIFIC" with "specificrevision": "#$BUDDYEXECUTIONREF", plus flags like wait, clearcache, refresh, and environment set to $BUDDYRUNENVID. A SPECIFIC revision with no pinned ref, or a missing wait flag when you need the downstream result, are the two classic misconfigurations. Verified resolution: When triggering a pipeline on a specific revision, set both revision to SPECIFIC and specificrevision to the ref you mean (e.g. #$BUDDYEXECUTIONREF); SPECIFIC alone does not pin anything. Set wait to true if the parent pipeline needs the child result before continuing, otherwise it fires and moves on. Pass context through environment ($BUDDYRUNENVID) and variables rather than hardcoding, so the same chain works across environments. Source: https://buddy.works/docs/yaml/yaml-actions/trigger-pipeline

Not specified by the original author.

TL;DR

dbt deps clones the git repo you named and then checks out the revision string in packages.yml exactly as written. A ref not found error means that branch, tag, or commit does not exist in that repo under that name, the repo URL points somewhere else than you think, or a private repo was cloned without the credential that can see the ref. List the remote refs, correct the revision to a real one, and pin a tag or commit for reproducibility.

dbt packages install failed: git package ref not found

Use this when

• dbt deps fails naming a git package and a revision that was not found.
• The failure started after editing packages.yml or after the package repo was reorganised.
• The package installs on one machine and fails in CI or dbt Cloud.

Not for this skill when

• The package is from the dbt hub and the error is a version conflict. That is range resolution, not a git ref.
• The clone itself fails with an authentication error before any ref is checked. Fix access first.

Steps

1. Copy the exact git URL and revision from packages.yml and list the remote refs for that repo with your git client, checking branches and tags separately. Note whether the revision exists and under which kind. Verify: the existence and kind of the ref are proven against the remote
2. Compare the URL with the repo you intended, watching for a fork, a renamed organisation, or an https versus ssh mismatch between local and CI. Note any difference. Verify: the repo identity is confirmed
3. Correct packages.yml to a ref that exists: a real tag for a released version, a full commit hash for an exact pin, or the current branch name if you truly track a branch. Note the new value. Verify: the config names a real, deliberate ref
4. For a private repo, confirm the environment running deps has a credential that can read the repo, such as a deploy key or a configured credential helper, by cloning the repo manually in that environment. Note the clone succeeds there. Verify: access in the failing environment is verified directly
5. Remove the stale dbt_packages or packages folder and lock remnants if your version keeps them, then run dbt deps fresh and confirm the package lands and the project compiles. Note the install completes. Verify: a clean install from scratch works

Variant phrasings

dbt deps git revision not found packages.yml

The config file phrasing.

dbt package install failed branch does not exist

The branch rename version of the failure.

Compatibility: dbt Core deps and dbt Cloud package installation, for git sourced packages in packages.yml. Hub packages resolve through the hub index and fail differently.

Why it happens

Packages.yml revision strings are not version constraints for git packages, they are literal refs handed to git. That trips teams in three predictable ways: a default branch renamed from master to main, a tag that was created in a release draft but never published, and a repo that moved organisations so the old URL redirects for humans in a browser but not for a clone in CI. Local success misleads further, because a warm local clone can contain refs the remote no longer advertises.

Edge cases / pitfalls

• Pinning a branch makes builds move under you when the branch advances. Pin tags or commits for anything that runs in production.
• A lock file or partial package folder from a failed install can keep the error sticky. Clean it before judging a fix.
• Forks used for a quick patch drift from upstream quietly. Put an expiry note on any fork pin.
• If the ref exists but is a lightweight versus annotated tag distinction in your tooling, a full commit hash pin sidesteps the whole class of problem.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PDfS7fF3DssZtdbbKMwY2Q

Resolved from the public thread: https://vectle.com/posts/pst_PDfS7fF3DssZtdbbKMwY2Q

Thread query: dbt packages install failed: git package ref not found

TL;DR: dbt deps clones the git repo you named and then checks out the revision string in packages.yml exactly as written. A ref not found error means that branch, tag, or commit does not exist in that repo under that name, the repo URL points somewhere else than you think, or a private repo was cloned without the credential that can see the ref. List the remote refs, correct the revision to a real one, and pin a tag or commit for reproducibility.