add test for bitbucket server

[paulirish]

@nwinkler outlined the requirements over here: #77 (comment)

I believe the patch here implements that, but it currently fails:

input	https://[email protected]/git/scm/ppp/rrr.git
expected output	https://mybb.domain.com/git/projects/ppp/repos/rrr
current output	https://[email protected]/git/projects/ppp/repos/rrr/browse/?at=refs%2Fheads%2Fmaster

Also @derimagia asks some questions about the convention about /git/scm at the root of the domain vs just /scm:

@nwinkler Your example doesn't have scm at the root (bb.org/git/scm instead of bb.org/scm/), why's that? Are you trying to get compatibility with non-root installed git repos?

---

@nwinkler will need your help on this one :)

[derimagia]

See #84 as well - allowing a check for all path arguments and keeping the basepath is pretty simple, Having it check the first argument and solving basepath elsewhere would also mitigate some of the conflicts "scm" being in the paths in non-bitbucket servers as well - although i'm sure this is pretty uncommon

[nwinkler]

Yeah, the git context is a bit weird, I know - but probably not uncommon for self-hosted services. The root URL (in our case something like https://shared.example.com/) is pointing to a load-balanced/failover-ready environment that hosts multiple services, with the git context pointing to the Bitbucket instance. Other root contexts (e.g. svn) point to other services.

This has the advantage of having one common root URL for all of the services (and just one sub-domain name, and one certificate for the load-balanced URL). Switching to the backup site in case of an outage can be done at this level with one IP/DNS change.

Like I said, it's probably not uncommon for hosted services. I'm sure that plenty of people run hosted Gitlab or GitHub Enterprise like this, too.

Does that make sense?

[paulirish]

@nwinkler can you look at the assertions here?

AFAIK this completely fails with the shipped version of git-open so i'm confused by what we "currently" support. :)

[nwinkler]

The working version was here: 9e9fee0#diff-21e611831fd54f9104bb1bb2abf161eeL89

elif grep -q "/scm/" <<<"$giturl"; then
  re='(.*)/scm/(.*)/(.*)\.git'
  if [[ $giturl =~ $re ]]; then
    giturl=${BASH_REMATCH[1]}/projects/${BASH_REMATCH[2]}/repos/${BASH_REMATCH[3]}
    providerUrlDifference=browse
    branch="?at=refs%2Fheads%2F${branch}"
  fi

This has been removed when @derimagia's changes were merged in.

[nwinkler]

Minor change required here. If the at parameter is provided to select a branch, the /browse part is required after the repo name.

https://mybb.domain.com/git/projects/ppp/repos/rrr/browse?at=develop

[nwinkler]

One additional assertion for private user repos on Bitbucket Server:

• Input: https://mybb.domain.com/git/scm/~first.last/rrr.git
• Output: https://mybb.domain.com/git/users/first.last/repos/rrr/browse?at=develop

Update: I tried this again with the current implementation, and it looks like it's generating this output from the above input:

Output: https://mybb.domain.com/git/projects/~first.last/repos/rrr/browse?at=develop

So essentially the same path as the other project URLs for Bitbucket Server, just keeping the ~first.last part in there instead of the project name. The Bitbucket Server instance understands both the users/first.last and projects/~first.last syntax and maps them to the same resource.

That means that there's no special handling of this case.

[derimagia]

Sounds like we should change the test to not include /git, sounds unrelated. My current instances for GHE and gitlab don't do this, but I don't see how it's related to bitbucket specifically. I'll see if I can make a config setting that solves all 3 remaining tasks: Protocol, Host, and Prefix Path

[nwinkler]

Yes, completely agree. The prefix/context is a decision at deployment time, and I assume it could be used in any kind of self-hosted solution.

[paulirish]

okay. tests updated.

• no more git/
• private user repos test added
• ../browse?at=.. pattern added.

Also I've allowed the tests to create 1 of a few acceptable URLs.

[paulirish]

seems like folks are happy here, so i'm merging.