Documenter.jl icon indicating copy to clipboard operation
Documenter.jl copied to clipboard

Support scheme definition for GitLab remotes

Open bauglir opened this issue 1 year ago • 1 comments

GitLab is fairly easy to self-host. Although best practice, this also means that the scheme over which GitLab is served is not guaranteed to be https. For this reason, the provided host should be allowed to define what scheme the GitLab instance is being hosted under and respect that in generated links.

The same applies to ports and potentially paths, but those are already supported given the current mechanism (provided no trailing slash is included in the host).

One benefit of this approach is that it also allows a full "base" URL to be provided as the host, e.g. the CI_SERVER_URL predefined variable within GitLab CI environments^1.

According to RFC3986^2, URI schemes should be matched case-insensitively, which this approach does. It also prescribes that only lowercase schemes should be produced, which this chooses to not do to keep the implementation simpler. If this is something that should be changed, I do have the implementation ready to go locally and can easily amend this PR.

bauglir avatar Jan 06 '24 13:01 bauglir

What do you think about doing this via an optional kwarg to GitLab (e.g. GitLab(host, user, repo; scheme="https")) instead? Feels a bit simpler than trying to parse the URL?

Although, I am also wondering, under what circumstances will you not have your self-hosted GitLab instance behind TLS, while still hosting docs?

mortenpi avatar Jan 15 '24 00:01 mortenpi