feat(bitbucket): support self-hosted instances

[dnaka91]

Atlassian has different APIs for the Cloud and Server (self-hosted)
version of Bitbucket. Therefore, a dedicated remote is needed to handle
the self-hosted version.

Description

Motivation and Context

closes #762

How Has This Been Tested?

Screenshots / Logs (if applicable)

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.
• I have formatted the code with rustfmt.
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 19.81132% with 85 lines in your changes missing coverage. Please review.

Project coverage is 38.64%. Comparing base (7415289) to head (969a74c).
Report is 21 commits behind head on main.

Files with missing lines	Patch %	Lines
git-cliff-core/src/remote/bitbucket/server.rs	0.00%	39 Missing ⚠️
git-cliff-core/src/remote/bitbucket/mod.rs	0.00%	25 Missing ⚠️
git-cliff-core/src/remote/bitbucket/cloud.rs	0.00%	10 Missing ⚠️
git-cliff-core/src/remote/gitea.rs	62.50%	3 Missing ⚠️
git-cliff-core/src/remote/github.rs	62.50%	3 Missing ⚠️
git-cliff-core/src/remote/gitlab.rs	66.67%	3 Missing ⚠️
git-cliff-core/src/remote/mod.rs	71.43%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #763      +/-   ##
==========================================
- Coverage   40.02%   38.64%   -1.37%     
==========================================
  Files          20       22       +2     
  Lines        1642     1703      +61     
==========================================
+ Hits          657      658       +1     
- Misses        985     1045      +60     

Flag	Coverage Δ
unit-tests	38.64% <19.82%> (-1.37%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[orhun]

LGTM overall, I'm thinking if we should merge this functionality with the bitbucket feature and use the cloud API whenever a custom bitbucket URL is provided. I think it will make things more clean, what do you think?

Also sorry for the delay. I'm totally happy to proceed with this PR and I hope you're planning to work on it 🐻

[dnaka91]

@orhun absolutely I'll continue on it. Just haven't have much time lately to continue on where I started.

I really like the idea of switching the implementation based on whether a custom URI was used. Felt really odd to have these two configs despite they pretty much achieving the same.

A few things are obviously still missing here and there. Especially testing is an issue I guess.

To have a self-hosted Bitbucket server running is easy as you can just grab the latest Docker image and run it, but then you need to get a 30-day license and so on. Way too many steps to verify the implementation.

As far as I understand the API isn't really evolving much (maybe the server variant gets the update to API v2 at some point eventually). So my idea is to record a few queries and save them in the repo, anonymized of course. Then we can see if we use a full blown HTTP mocking crate or simply deserialize the files into expected responses.
That way we can at least verify the implementation to some degree without having to run a full server every time. Might be a good solution for the other backends as well.

[orhun]

absolutely I'll continue on it. Just haven't have much time lately to continue on where I started.

Thanks for showing interest! Just an idea, maybe it makes sense to start this PR over since we won't have two separate functionalities for this :)

To have a self-hosted Bitbucket server running is easy as you can just grab the latest Docker image and run it, but then you need to get a 30-day license and so on. Way too many steps to verify the implementation.

Wow, that's really bad ;/

So my idea is to record a few queries and save them in the repo, anonymized of course. Then we can see if we use a full blown HTTP mocking crate or simply deserialize the files into expected responses. That way we can at least verify the implementation to some degree without having to run a full server every time. Might be a good solution for the other backends as well.

Loved this idea! This will also save us from spurious CI errors due to networking issues that happen occasionally with GitLab etc.

Would love to have this in!

[dnaka91]

No need to start it over, we can use the power of rebase and force pushes 😉. But it's basically somewhat of a start over, haha.

First step done, now the Bitbucket implementation picks the Cloud or Server variant based on whether a custom API URL is set.

Will get to add in some tests and finish up some missing docs (clippy will probably fail) next.

[orhun]

Perfect!

[orhun]

Just lmk when this is ready for review :)

[dnaka91]

Definitely! The basics are ready, just didn't get a chance to collect some API calls for some automated tests yet.

Once I feel it's ready I'll move it from a draft into a regular PR.

[dnaka91]

Just a small heads up, I didn't forget about the PR. Priorities are quite somewhere else at the moment, so I simply didn't get to pull over and sanitize those request/response samples.

But I'm sure I'll get to it sometime.

[orhun]

No worries, sounds good :)