Self-hosted Windows Runner builds intermittently get stuck during the repository clone on the build setup
Platform Notice: Cloud Only - This article only applies to Atlassian products on the cloud platform.
Summary
In certain scenarios, builds utilizing Bitbucket Pipelines Self-hosted Windows Runners may experience intermittent delays during the execution of the git clone command within the build setup process.
When such a situation arises, the build will remain in a running state for a duration of 120 minutes before ultimately timing out.
Environment
Bitbucket Pipelines Self-hosted Windows Runners
Diagnosis
To ascertain whether you are impacted by this issue, it is essential to verify if you are utilizing Git Credential Manager, as its credential caching is the primary source of the problem.
On the host machine used for setting up the Runner, execute the following Git commands in a Command Line or PowerShell session:
1
2
git config --global --list
git config --system --list
⚠️ If the output includes terms such as "manager", "manager-core", "wincred", or "manager-core", this indicates that a credential helper is configured, suggesting that you are likely affected by the issue outlined on this page.
Conversely, if such output is absent, your issue may not be related to the concerns discussed here. For further assistance, please contact Atlassian support or consult the Atlassian community.
Cause
The issue arises from the Git Credential Manager provided by Windows, which has the potential to cache expired credentials on the host system. This caching behavior can lead to complications when attempting to clone a repository, thereby hindering the build process from commencing successfully.
Solution
To address this issue, one can instruct the Git Credential Manager (GCM) to discard cached credentials. This can be accomplished by executing the following command in a new Command Line or PowerShell session:
1
git credential reject
Upon executing this command, GCM will prompt you to input your username and password the next time you engage with a Git repository that necessitates authentication. This action will effectively remove the cached credentials.
ℹ️ It is advisable to attempt cloning a repository on the host machine prior to utilizing Runners again, in order to refresh the cached credentials.
If the problem persists, you may consider disabling the Git Credential Manager entirely by running the following command:
1
git config --global --unset credential.helper
Should the issue continue even after disabling the Git Credential Manager, it is recommended to contact Atlassian support or consult the Atlassian community for additional assistance.
Was this helpful?