Repository navigation
[Bug][gitextractor] Bitbucket connection fails on Git clone #8627
Copy link
Copy link
Closed
Labels
component/pydevlakeRelates to the Python framework and/or plugin.Relates to the Python framework and/or plugin.priority/highThis issue is very importantThis issue is very importantseverity/p0This bug blocks key user journey and functionThis bug blocks key user journey and functiontype/bugThis issue is a bugThis issue is a bug
Description
Search before asking
- I had searched in the issues and found no similar issues.
What happened
Issue Description
Bitbucket connection authentication works inconsistently between API calls and Git clone operations.
Steps to Reproduce
- Create Bitbucket connection using email address + API token with proper scopes (as required by the UI)
- Add a Bitbucket repository to a blueprint
- Run the blueprint
Actual Behavior
- First run: Clone fails because DevLake uses email address for Git clone, but Bitbucket requires username
- Workaround attempt: Update
_devlake_blueprintstable to set mode='ADVANCED', then edit blueprint JSON to replace email with username in the git URL - Result: Clone succeeds once, then fails on subsequent syncs
Alternative Approach Tried: SSH
Configured privateKey in advanced blueprint mode with SSH URL format.
- First run: Works
- Subsequent runs: Fails with error:
Identity file /tmp/gitext-pk* not accessible: No such file or directory
The temporary SSH key file gets created but then becomes inaccessible, causing permission denied errors.
Environment
- DevLake version: v1.0.3-beta7
- Connection type: Bitbucket Cloud
- Authentication: API token with proper scopes
Expected Fix
DevLake should either:
- Allow specifying both email (for API) and username (for Git) in Bitbucket connection settings, OR
- Automatically resolve username from email via Bitbucket API, OR
- Fix SSH privateKey handling to persist properly across multiple runs
What do you expect to happen
Connection should work for both API calls and Git clone operations using the same credentials.
How to reproduce
Steps to Reproduce
- Create Bitbucket connection using email address + API token with proper scopes (as required by the UI)
- Add a Bitbucket repository to a blueprint
- Run the blueprint
Anything else
No response
Version
v1.0.3-beta7
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
component/pydevlakeRelates to the Python framework and/or plugin.Relates to the Python framework and/or plugin.priority/highThis issue is very importantThis issue is very importantseverity/p0This bug blocks key user journey and functionThis bug blocks key user journey and functiontype/bugThis issue is a bugThis issue is a bug
Activity
dosubot commentedon Oct 31, 2025
Hi @oguzgu! I'm Dosu and I’m helping the incubator-devlake team.
You're running into two distinct issues with Bitbucket Cloud connections in DevLake:
Email vs. Username for Git Clone: DevLake currently uses a single credential field for both API and Git clone operations. Bitbucket Cloud requires your Atlassian account email for API calls, but your Bitbucket username for Git clone. The code does not distinguish between these or automatically resolve the username from the email, so after manual edits, it reverts to using the email, causing clone failures. This is a known limitation in the credential handling logic (source, source).
SSH Key Persistence: For SSH authentication, DevLake creates a temporary private key file for each run and deletes it immediately after use. This means the key file is not available for subsequent syncs, leading to "Identity file ... not accessible" errors (source, discussion).
Current workarounds:
Recent changes:
A recent PR added support for Bitbucket API tokens and clarified the credential requirements, but did not address the dual credential issue or SSH key persistence (source).
What’s needed for a robust fix:
DevLake would need to support specifying both email (for API) and username (for Git) in the Bitbucket connection settings, or automatically resolve the username from the email via the Bitbucket API. For SSH, the private key handling logic would need to persist the key file across runs or reliably recreate it each time.
Let me know if you want more details on the code paths or configuration options!
To reply, just mention @dosu.
Docs are dead. Just use Dosu.