iver-wharf / wharf-provider-gitlab

Import Wharf projects from GitLab repositories
MIT License
2 stars 0 forks source link

Add custom SSH URL mapping #16

Closed applejag closed 3 years ago

applejag commented 3 years ago

Context

We have a customer that hosts their GitLab and Wharf instance in the same Kubernetes cluster. Because of techincal difficulties with the firewalls and other services, they cannot talk to each other via the internet. They can only talk to each other in the internal kubernetes network.

Currently the Git SSH URL is taken from the ssh_url_to_repo property (GitLab docs: https://docs.gitlab.com/ce/api/projects.html#get-single-project), as can be seen here:

https://github.com/iver-wharf/wharf-provider-gitlab/blob/413c450167f12fc9978c6fe75b192b7e993f891a/mapper.go#L20-L29

Suggested implementation

Add optional config flag, ex WHARF_GIT_URL_TEMPLATE, that does a basic search and replace on the SSH key using some different fields.

We could use the text/template Go package for this.

Example usage

  env:
    - name: WHARF_GIT_URL_TEMPLATE
      value: "ssh://gitlab.default.svc.cluster.local:2222/{{ .path_with_namespace }}.git"

Or if we want to use the Project type directly:

  env:
    - name: WHARF_GIT_URL_TEMPLATE
      value: "ssh://gitlab.default.svc.cluster.local:2222/{{ .PathWithNamespace }}.git"

(https://pkg.go.dev/github.com/xanzy/go-gitlab#Project)

Considerations

This needs to be well documented as soon as it's implemented.

How do we make sure we're not colliding with Wharf's own variable syntax? We have been experimenting with the idea of changing the variable syntax, as can be seen here: https://iver-wharf.github.io/wharf-notes/different-variable-syntaxes Do we want to change Wharf's variable substitution to use Go's text/template package instead, or do we stick with a custom templating system?

This should also be implemented in our other providers, so picking a stupid-simple variable substitution syntax is key.

Needs an RFC for this.

applejag commented 3 years ago

On second thought, this should probably be stored in the database and not inside the provider's config. Better to let users configure it via the web or REST interface

applejag commented 3 years ago

This was fixed in wharf-api v5.0.0 (https://github.com/iver-wharf/wharf-api/issues/114)