Skip to content
Latchkey

semantic-release "remote repository could not be found" (repositoryUrl) in CI

During "Verify Conditions", semantic-release confirms the remote repository exists and is reachable using the resolved repositoryUrl. If the URL is wrong, or the token cannot access it, it reports that the repository could not be found.

What this error means

The run fails with "EINVALIDGITURL" or "The git repository at URL ... could not be found", pointing at the repositoryUrl it derived.

semantic-release
[semantic-release] > EINVALIDGITURL The git repository URL is not valid.
The repositoryUrl option, or the repository property in package.json, must point to a valid,
reachable Git repository. Received: git@github.com:owner/wrong-repo.git

Common causes

A stale repository field in package.json

The repository URL in package.json points at an old or renamed repo, so semantic-release targets a remote that no longer exists.

The token cannot access a private remote

The URL is correct but the token has no access to the private repository, so the reachability check fails.

How to fix it

Correct the repository URL

  1. Fix the repository.url in package.json to the current remote.
  2. Or set repositoryUrl explicitly in the semantic-release config.
  3. Re-run so verification finds the real remote.
package.json
{
  "repository": { "type": "git", "url": "https://github.com/owner/repo.git" }
}

Ensure the token can reach the remote

For private repos, pass a token with read access so the reachability check succeeds.

.github/workflows/release.yml
env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

How to prevent it

  • Keep package.json repository.url current after renames.
  • Set repositoryUrl explicitly when the package.json field is ambiguous.
  • Give the release token read access to the target repository.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →