Open yiannistri opened 1 year ago
Its interpreted over here https://github.com/weaveworks/weave-gitops/blob/b67d16c260707b345d0e22dacf7838e2b7da7b38/pkg/gitproviders/repo_url.go#L29-L30
(untested), I would guess that GIT_HOST_TYPES: git.example.com=bitbucket-server,ssh.example.com=bitbucket-server
would work.
But I think we only use it to choose the gitprovider (https) though. Are we thinking of adding some ssh stuff?
@foot does that mean that we don't support selecting an SSH URL (in the dropdown where we list all Git repositories) that we can then authenticate against?
Result of setting
GIT_HOST_TYPES=stash.stashtestserver.link:7990=bitbucket-server,stash.stashtestserver.link:7999=bitbucket-server
(7990 HTTP, 7999 SSH)
HTTPS
SSH
Does dropping the port in GIT_HOST_TYPES=stash.stashtestserver.link:7990=bitbucket-server,stash.stashtestserver.link:7999=bitbucket-server
work? We might not be supporting that properly.
I can try that (using a single host?) but I believe the port is needed because the key used is u.Host
From https://pkg.go.dev/net/url#URL
Host string // host or host:port
Using GIT_HOST_TYPES=stash.stashtestserver.link=bitbucket-server
https://github.com/weaveworks/weave-gitops/pull/3430
Seems to be okay there 😕
Where are you setting the GIT_HOST_TYPES
?
@foot so during testing I discovered https://github.com/weaveworks/weave-gitops-enterprise/issues/2432 which needs fixing.
I wasn't aware about this override when I opened this issue so I thought we could solve it by providing multiple comma separated values in GIT_HOST_TYPES. However we don't parse those correctly which is what prompted the original investigation.
Your tests run fine but they're not using multiple comma separated values in the environment variable. I don't expect many customers to be using multiple custom providers but if they do, they have no way of specifying all of them correctly.
Where are you setting the GIT_HOST_TYPES ?
I'm setting them in the git-provider-credentials
secret which is optional and gets mounted to the pod if present.
This story is currently blocked/waiting for #2432. Once that has a fix we'll make sure that it works with BitBucket Server.
Pesto has fixed the bug and we’re now using the annotation value as described in the docs. This fix should be included in the next WGE release v0.18.0. Strangely, although the API does not parse the BitBucket repo URL correctly (the owner value returned includes scm/ prefix) the OAuth flow works correctly and the PR gets created successfully.
Is this still an issue? It's hard to understand where this is standing because it feels the conversation went to a different direction. BitBucket URL parsing issues are not (at least shouldn't) part of this issue, more like a "found during working on this".
Last relevant bit I see:
they have no way of specifying all of them correctly
I had to configure multiple GIT_HOST_TYPES
recently and it's actually space separated, not comma separated, to make it work at all.
In terms of port parsing etc I'm not sure if thats still an issue.
Then I think the expected outcome of this issue is:
Document how to configure multiple custom providers
(and file follow-up issues for any surfaced problems)
Someone needs to go through, test, document
Addresses unlikely situation.
In WGE, there's an environment variable
GIT_HOST_TYPES
that is used to map a custom host address to the type of git provider running in that address. For example, if we setthen any GitRepository URLs that reference
git.example.com
are assumed to be BitBucket Server repositories.In BitBucket Server we may have to set both HTTPS and SSH URLs in this variable, which is not currently supported.