git-open-pr does not appear to support SSH URLs

[ewanleaver]

Checklist

• I've searched the issue queue to verify this is not a duplicate bug report.
• I've included steps to reproduce the bug.
• I've pasted the output of kargo version.
• I've pasted logs, if applicable.

Description

I am attempting to use the git-open-pr promotion step to interact with a repo on a GHE instance. I am using the SSH URL for the repo. However git-open-pr fails and throws the error: invalid git-open-pr config: repoURL: Does not match format 'uri'.

Some searching online appears to suggest that this is potentially an issue from an underlying HTTP library, and it appears that git-open-pr makes the assumption that the repo URL is formatted as a HTTP URL rather than an SSH URL.

Notably the git-clone step is able to interact with the repo using the same URL, which suggests that implementations between the two steps may be differing. I suspect that as git-open-pr currently only has support for GitHub and GitLab providers (and not explicitly GHE), that some assumptions are being made in the logic and thus support for SSH authentication is perhaps not implemented here.

Note that the repo is hosted on GHE and not public Github, and it is a requirement that I use the SSH URL rather than the HTTP URL for the repo.

Screenshots

Steps to Reproduce

• Attempt to use git-open-pr with an SSH URL as input to repoURL

Version

v1.2.3

Logs

`invalid git-open-pr config: repoURL: Does not match format 'uri'`.

[hiddeco]

As a workaround, I think it would work if you define the SSH URL for cloning while providing a HTTPS URL for the PR creation step (as it is used to construct the GitHub API client).

[ewanleaver]

Unfortunately I don't believe that this is valid workaround for me, as I can only authenticate with SSH keys and not with the username/password required for using the HTTPS URL.

[hiddeco]

I do not believe GitHub Enterprise supports authentication to their REST API using SSH keys, and I am not sure how we could support pull requests without having access to a valid API token and/or username and password.

[ewanleaver]

I am ignorant on this topic, but what differentiates pull requests from any other interaction with GHE? I'm a little baffled that other actions work with SSH keys but pull requests require use of a different API that doesn't support the same authentication options 🤔

[hiddeco]

The non-PR-related steps use git to clone, checkout, commit, and push information to a Git repository (in this case, hosted via GHE). This makes use of the Git protocols, and thus supports HTTP/S and SSH.

Pull requests, however, are Git provider-specific and not a builtin feature of Git itself. Because of this, pull requests work through the provider-specific APIs like GitHub (Enterprise)'s pull request API or GitLab's merge request API. Because these are REST APIs, they do not support authentication through SSH keys and work with a different model in general than simple communication with the repository itself.

[hiddeco]

Based on the current code, even if the validation would allow defining an SSH URL, a user would still have to supply both an SSH key (for the Git clone operation) and a token (for the REST API) for the SSH URL.

As this can potentially be confusing, we should probably somehow find the HTTP/S credentials for the Git provider even if an SSH URL is provided for cloning — but I deem this of relatively low priority at present.

[krancour]

we should probably somehow find the HTTP/S credentials for the Git provider even if an SSH URL is provided for cloning

There's an edge case dependent on the underlying infrastructure where git@git.example.com:example/repo.git and https://git.example.com/example/repo.git don't point to the same place.

I vaguely recall having gone down this road perhaps two years ago and avoiding it at that time because of this.

But I suppose that technically, even for a repo in GitHub, and even without SSH in the picture at all, https://git.example.com/example/repo.git could resolve differently for controllers in different shards. i.e. We wouldn't exactly be introducing a new problem by doing the SSH/HTTPS translation.

Perhaps this edge case is an outlier to the degree we ought to ignore it.

At any rate, agree on low priority.