Hello,

please check this PR:

fix: error fetching sha for branch name with slash in it by sushdive · Pull Request #295 · jenkins-x/go-scm · GitHub

I remember fixing this issue for go-scm

Does not work for
/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}
 response 404:

{
    "type": "error",
    "error": {
        "message": "Resource not found",
        "detail": "There is no API hosted at this URL.\n\nFor information about our API's, please refer to the documentation at: https://developer.atlassian.com/bitbucket/api/2/reference/"
    }
}

Has there been any progress with this (src)? I'm running into this and it's a real pain. The only potential solution I came up with is to do a request ahead of time to get the commit hash and use that instead of the branch name that contains a slash.

Hello all,

Sorry that this has been such a long-standing bug. I don't blame anyone for getting upset!

I've been looking into this bug and want to point out a couple of things.

1. Branch names with '/' should work with any API or path where the branch name/revision is the last part of the path. This includes, but is not limited to, the following APIs. So the API specifically mentioned on this issue is working today. I'm not sure when (I can look that up) and I'm sorry that this issue was never updated. If you find an API where this is not the case, it can be easily fixed, relatively speaking
   1. /2.0/repositories/{workspace}/{repo}/commits/{revision}
   2. /2.0/repositories/{workspace}/{repo}/refs/{branch_name}
2. Branch names with a '/' will not work with any API where the revisions is not the last part of the path. src being probably the most notable
   1. /2.0/repositories/{workspace}/{repo}/src/{revision}/{path}

It's not to say that there isn't any solution, but any solution comes with trade offs and they're not all that great. Here are some solutions that have been brainstormed.

• escape branch names. URL escaping cannot work and the %2F will be re-written before even reaching the app as this is part of the WSGI spec. We'd need to pick a custom character (that is a character that is an illegal branch name character). `\` could work, but I've read that these can be treated as '/' on windows. If we chose to use an escaping solution it will be non-standard and unintuitive and I'm unsure how many people would know about it.
• New APIs. This is the most straight forward fix but also the most change and it could be inconsistent with our other URLs. Revisions can just become query params and the problem is solved.
• Branch lookups - this is possible but could entail a performance hit as we now have to keep track what all the current valid branch names are. Furthermore, this solution is even more difficult with the /src/ API because now we have 2 path arguments that both can contain a slash! We'd have to not only search for possible branch names, we'd have to search within files too. And we still wouldn't be able to eliminate all ambiguity.
• Some sort of a query parameter replacement. Replace the revision segment of the path with '{branch}' and add a query parameter ?branch= and we will substitute that query parameter into the branch name.

I hope you can see that none of the solutions are really that optimal. Please advise on which of these solutions makes sense to you.

As we are currently moving forward to grow our company this disregardful treatment of paying customers (not yet big enough to be heard by Atlassian) is exactly why we now move gradually away from Atlassian and search for more reliable partner which offer their software under a open-source license. Thankfully, I am now in a position to be able to make those decisions.

This bug was opened more than 6 (SIX) years ago and nothing was fixed. This is embarrassing!

2.5 years in and you're "dropping" the priority? How long do minor issues take to fix if higher priorities take this long?

As you can see, I've attempted a fix for this before, however it broke a number of APIs (Everything at https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/commit aside from the basic one) so it had to be reverted.

The way our APIs are structured, it will not be possible to add support to this endpoint for branch names until we release a new major revision because for v2, it will either shadow APIs or some branches won't be accessible.

However, there is a workaround which just involves one additional request to grab the commit hash then using that in any of the endpoints. https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/refs/branches/%7Bname%7D should work with branch names which contain slashes.

I'm leaving this open, but dropping the priority because our hands are tied and there is an existing workaround.

Sorry for the inconvenience.

Happy belated second birthday to this issue...

Hi Zach,

I apologize if my response seemed personally directed at you (it was not) but I hope you will also appreciate my source of frustration here. As you are no doubt well aware, this is one of (too) many Bitbucket issues that have remained in an unresolved state for multiple years now, with no comment or acknowledgment from Atlassian, despite multiple user votes, "+1"'s and requests for status updates. And to me this particular issue is more egregious in that it was (apparently) fixed but then just as quickly reverted with a terse explanation and no follow up despite the comment to the contrary.

So while I am certainly happy to see that some of these issues are getting some long overdue attention and definitely sympathetic to you as the unlucky dude who is tasked with plowing through this mess, I can't help but think that if Atlassian/Bitbucket had not proceeded to ignore them for such a long period of time that they would not be in this position now.

Thank you in advance for all your efforts and I would definitely appreciate it if you could reopen this issue so that hopefully someone can give it another look in the near future.

regards,
-steve

Hi Steve,

I am personally trying to reconcile the statuses of issues on our internal tracker with this issue tracker, on the order of slightly more than 14,000 issues, with the goal of narrowing down the list of open issues to ones that actually need attention. You are correct that I did not verify whether this was actually fixed or not, but I did verify that a pull request was merged and deployed which purported to fix this issue in July of 2014. Hopefully you can forgive me for not verifying each of the 14,000 issues individually. I'm happy to reopen this and the corresponding internal issue.

Cheers,
Zach

This most certainly is not fixed, I just tested it on one of our repos. For any branch with a slash in it, I get a "404 not found" response (even when using %2F to encode the slash).

It would be nice if you actually verified things as fixed instead of just closing them with "looks like it was fixed"...this is extremely frustrating to me as an end user!

Looks like this was fixed a while ago. Please let us know if you still see problems.

@"Roman Allenstein" We do not have this option with our hosted CI solution.

@SethMcLean You could use the rawnode-id instead of the branch-name. So your teams CI wouldnt be blocked.

I have fixed that for a mantis-bugtracker plugin. Here you can see the solution:

https://github.com/mantisbt-plugins/source-integration/commit/4492cc36caa02595a6b28f2681cb368b728ef236

This is a blocker for our teams CI.

Hi BB folks, any update on this? A lot of our customers are complaining that they need this...

Hi!
Any update on this? I am using git-flow which has the naming-convention of "feature/...." and trying to work the API. Unfortunately this ticket is still open.

+1 to fix this one.

This currently breaks Shippable (https://github.com/Shippable/support/issues/1205) where Github succeeds .

Getting the same issue. "Remote rejected" and "failed to write" errors using any branch name with a "/" , done locally. Invalid branch names through BitBucket.

The two tickets you marked as a dupe are about different url patterns. I guess that means this is a single bug affecting multiple url patterns?

Issue BCLOUD-10601 was marked as a duplicate of this issue.

Suspicion confirmed

Seems related to 10601. Seems to me like a general overhaul of url-encoding in the API is needed.

Hey folks,

Can I also get an update on this issue?

Dom

Hi,

Any updates on this issue?

I am from Semaphore CI and I am in charge for Bitbucket integration. This issue is hurting our users pretty bad and we are taking a lot of heat, since it is essential for their workflow...

Thanks in advance.

Best,
Rastko

Just a note: this will most likely be reverted at some point this week, as it breaks a current endpoint. We will revisit this issue at that point.

This has been fixed. Please reopen if you have any issues.