Support scheme definition for GitLab remotes #2392
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. [^1]: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html [^2]: https://datatracker.ietf.org/doc/html/rfc3986#section-3.1
|
What do you think about doing this via an optional kwarg to Although, I am also wondering, under what circumstances will you not have your self-hosted GitLab instance behind TLS, while still hosting docs? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 providedhostshould 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_URLpredefined variable within GitLab CI environments1.According to RFC39862, 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.
Footnotes
https://docs.gitlab.com/ee/ci/variables/predefined_variables.html ↩
https://datatracker.ietf.org/doc/html/rfc3986#section-3.1 ↩