New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(bitbucket): Bitbucket Server platform support #2774
Conversation
addresses #2482 |
Is it just me, or bitbucket API for cloud and server diverge too much, to the point where we should consider it a different platform? |
It does start to seem like they could be separate platforms. I think the current approach to the PR is good - just change everything necessary and if we decide it’s not worth “unifying” them again then we can split into two platforms with a little shared code. |
yeah, basic concepts are the same, but might have new names, also set of endpoints is different a little |
we thought we would start with existing adapter to see how big are the moving parts |
@iamstarkov what do you think about using FYI here is the list of commands that can be supported via gitFs: renovate/lib/platform/git/storage.js Lines 18 to 30 in 9534e6a
So basically you could remove all the API equivalents of these and not have to worry about porting them to Bitbucket Server. |
Ricky Patel seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
ahaha, bitbucket server allows to delete endpoint only through non-documented api endpoint. Also if you want to reset the branch it will throw an exception because the file used to be in that branch already |
we are going to try gitFs |
Integrating it is a little tough, although of course you can follow the examples from GitHub and GitLab, which are already migrated. However if you can wait a little then @kayoub5 hopefully has time to submit a PR migrating BitBucket Cloud and you could rebase based on that (with some conflicts unfortunately, but unavoidable). |
@rarkins we setup gitFs for BB server now and it works a charm. This way we avoid migrating a lot of API calls to obscure BB Server equivalents :). I think we covered most of the happy path, tomorrow we'll focus on error handling + refactoring the server code into its own module. |
@kayoub5 not sure if you started on migrating BB Cloud to gitFs, but we should be able to cover that in this PR too if you haven't started. |
Amazing work @JCB-K ! I’m pretty sure @kayoub5 hasn’t started yet, so any work in this PR would be great. Does it work using the same token for both git as well as API? For GitLab we found it has a limitation of only supporting git write operations via SSH, which means you need both an SSH key as well as API token. I think we could even make both Bitbucket Cloud and Server “gitFs-only” if it simplifies maintenance. I still classified BB support in Renovate as “beta” until now so have no problem deprecating the API-based functions if you think that’s a good idea. |
For now we do git operations on http://username:password@host. BB Server allows you to generate tokens which then can be used as passwords (so "single-use password" would be a more correct term), so I don't think we'll need SSH keys.
Aren't all these API methods internal anyway? Or are some of them exposed to users? Don't mind spending some time adopting the functions that aren't available in gitFs to the Server API if they're useful. |
Yes, you could reasonably argue that, which is even more reason why making the change is not a big deal.
There should be no need to expose any. I have about 5% of the hosted GitHub App running on gitFs and 100% of the GitLab hosted app on gitFs so far. I think once we support gitFs on all platforms - includes VSTS/Azure DevOps - then I might drop non-git support in the next major release. |
OK cool, we'll remove methods in |
* Reordered imports * Removed unused variable * Removed unexpected console/logging statements * Temporarily suppressed async functions without await expressions (to be fixed properly when the underlying issue is addressed)
FYI, I have now refactored the existing Bitbucket Cloud platform code to use gitFs-only, like this PR. So we can align the codebases and tests a lot easier, I hope. |
} | ||
} | ||
async function mockedGet(path) { | ||
let body = responses[URL.parse(path).pathname] || { values: [] }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
URL.parse()
returns results in lower case while the fixtures file uses uppercase SOME
in its response keys
Test coverage is now up to 67% of this PR. Once we hit 100%, we can merge this to master. Can anyone help? |
@k2snowman69 @PixnBits we used api docs for v5.11.1 , URL is here https://docs.atlassian.com/bitbucket-server/rest/5.11.1/bitbucket-rest.html because that is the BB version we have in prod. With that said, Feel free to adjust the code for latest version available. |
Also, Ricky Patel please sign CLA =) is it you, @k2snowman69? |
Not sure what's going on here but I believe I signed the CLA request as k2snowman69 but it doesn't seem to sync up with my name. But yes that is me :-) |
Hi all, I'm planning to merge this PR as-is so that it is easier for everyone to test out locally as well as submit PRs against the master branch whenever you find something needing improvement. I've been testing it myself with a local Bitbucket Server instance running inside Docker and it onboards, creates and updates PRs, etc. |
🎉 This PR is included in version 14.12.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This is amazing news. @rarkins thank you very much for this |
Closes #2482