Annotation app.openshift.io/vcs-ref is not working for BitBucket repositories

[beloyar777]

Can be repoduced in console of OpenShift 4.6.20.

Having the following annotations:

app.openshift.io/vcs-uri: https://company.com/projects/XYZ/repos/foo-project/browse 
app.openshift.io/vcs-ref: feature/x-111

Topology view shows/generates the following link:
https://company.com/projects/XYZ/repos/foo-project/browse/tree/feature/x-111

But the expected/correct BitBucket link is:
https://company.com/projects/XYZ/repos/foo-project/browse?at=refs%2Fheads%2Ffeature%2Fx-111

I have tried the following annotations:

app.openshift.io/vcs-uri: https://company.com/projects/XYZ/repos/foo-project/browse 
app.openshift.io/vcs-ref: "?at=refs%2Fheads%2Ffeature%2Fx-111"

Topology view still appends '/tree' to the link:
https://company.com/projects/XYZ/repos/foo-project/browse/tree?at=refs%2Fheads%2Ffeature%2Fx-111

Please, provide annotation type for BitBucket repository.

[spadgett]

cc @christianvogt @andrewballantyne

[christianvogt]

Note there is a long outstanding issue with bitbucket URLs with branch names containing forward slash: https://jira.atlassian.com/browse/BCLOUD-9969

[christianvogt]

@beloyar777 please have a look at this PR #9111

It seems that in order to create a valid branch link in your case, we need the commit sha as well. This is because the branch name contains a /. Using the base url along with the branch is not sufficient to create a valid branch repo url.

[beloyar777]

@christianvogt as far as I can see there is a missunderstanding...

You have referenced an issue of the BitBucket API usage:
https://jira.atlassian.com/browse/BCLOUD-9969

And we are talking about the URI for the frontend of the BitBucket.
So, your PR #9111 is not fixing, but producing an additional issue. Please revert it! )

There are 2 issues in my use case currently:

1. How do you know, that you have to deal with BitBucket URI if
   app.openshift.io/vcs-uri: https://company.com/projects/XYZ/repos/foo-project/browse
   doesn't contain any occurance of bitbucket?

Just parsing app.openshift.io/vcs-uri value for bitbucket is not sufficient in my case:

if (gitUrl.resource.includes('bitbucket')) {
    return `${baseUrl}/src/${branch}`; 
 }

Maybe an additional annotation app.openshift.io/vcs-type: bitbucket could help in this case?

Currently the topology view appends unexpected /tree to the link:
https://company.com/projects/XYZ/repos/foo-project/browse/tree?at=refs%2Fheads%2Ffeature%2Fx-111

2. And if app.openshift.io/vcs-uri would contain any occurence of 'bitbucket', then /src would be added to the URI (as if it would be a master branch), but this is again wrong in my case. The expected/correct BitBucket link for a non-master branch is:
   https://company.com/projects/XYZ/repos/foo-project/browse?at=refs%2Fheads%2Ffeature%2Fx-111

It seems, that BitBucket has some differences in the link schema for master and non-master branches which should be correctly addressed by the topology view.

Maybe you it would be better to take over the full URI if it's annotated as custom type like this for example?

app.openshift.io/vcs-uri: "https://company.com/projects/XYZ/repos/foo-project/browse?at=refs%2Fheads%2Ffeature%2Fx-111" 
app.openshift.io/vcs-type: "custom"

What do you think?

[rottencandy]

Hi @beloyar777,
#9111 is one half of the fix, please also see https://github.com/openshift/console/pull/9088/files#diff-cce7ec36a6079ecd87e2fc89043657f9b9538b26df0f717ae48557bff91a39d7

We currently default to not using vcs-ref in the URL if the domain does not have github/bitbucket/gitlab.

The URL is formatted according to bitbucket's documentation: https://support.atlassian.com/bitbucket-cloud/docs/hyperlink-to-source-code-in-bitbucket/

[christianvogt]

The topology editor decorator can also be overridden by supplying a custom edit URL using annotation: app.openshift.io/edit-url

If you have Code Ready Workspace installed and want the edit URL in topology to open your workspace, then you do want to use app.openshift.io/vcs-uri along with app.openshift.io/vcs-ref. However in your case with a custom domain we cannot detect the git provide and therefore will default to omitting the branch details. That being said you can set app.openshift.io/vcs-uri to be the specific branch URL you want without using vcs-ref.

You say that the correct url you need is https://company.com/projects/XYZ/repos/foo-project/browse?at=refs%2Fheads%2Ffeature%2Fx-111 however in testing it seems like you need to include the branch hash value as follows.
eg. https://company.com/<org-name>/<project-name>/src/<hash value>/?at=<branch name containing /> I couldn't reach a page on BitBucket for a branch which contains a /` without including the hash.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[christianvogt]

@beloyar777 we could consider supporting your suggested annotation app.openshift.io/vcs-type because otherwise we cannot do any detection with a custom domain.
It's been a while since I've looked at this issue but IIRC there's still a problem with constructing a bitbucket URL for your project without having the hash value.

Is this issue still a concern for you?

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.