Private Mode
The most common root cause for this issue is when your source control management system (GitHub Enterprise, Gitea, etc) is running in Private Mode, which means you need to authenticate to clone public repositories.
By default, Drone will only authenticate with your GitHub remote when cloning a private repository. You can configure Drone to always authenticate when cloning a repository using the following server setting:
DRONE_GIT_ALWAYS_AUTH=true
Public Changed to Private
If you added a repository to Drone and the repository was public, and it was later changed to private in our source control management system, Drone may not be aware of this change.
This can cause problems because you need to authenticate to clone private git repositories. If Drone is unaware the repository is now private, it will not authenticate when attempting to clone, resulting in a clone failure.
This can generally be resolved by re-syncing your account, but in some cases could require a manual database update if the problem persists.
Permissions Revoked
If you activate the repository with a user account, and then either delete that user account or revoke Drone’s access to that user account, the system will be unable to clone the repository.
This can be resolved by de-activating the repository and re-activating. The user that re-activates the repository will be assigned ownership.
Invalid Password
Please note that you do not need to provide Drone with a username and password to clone your repository. Drone automatically authenticates using your oauth2 token.
If you decided to override the default authentication behavior and provide static clone credentials, please double-check the username and password, and make sure the user has adequate permission to clone the repository.
DRONE_GIT_USERNAME=<username>
DRONE_GIT_PASSWORD=<password>
EDIT: please note that you should almost never need to override the default git clone credentials. If you are reading this thread and thinking you may need to set these values, but you don’t understand why, then you should definitely NOT be setting these values.
Networking Issues
This is also a common root cause for this error, especially when using docker-compose to run Drone on the same machine as Gogs or Gitea.
First, we should clear up some misconceptions
- Drone does not clone your code inside the agent or runner container. The fact that the agent or runner or server can communicate with Gogs or Gitea is irrelevant.
- The clone container is attached to a user-defined network. The fact that you can clone code inside a Docker container is irrelevant because that container is probably attached to the bridge network.
In order for the clone container to communicate with Gogs or Gitea you probably need to attach the Gogs or Gitea network to the clone container. You can attach additional networks to all pipeline containers using the following runner / agent setting:
https://docs.drone.io/runner/docker/configuration/reference/drone-runner-networks/