remote: add callback to resolve URLs before connecting#5056
remote: add callback to resolve URLs before connecting#5056eaigner wants to merge 13 commits intolibgit2:masterfrom eaigner:remote-urlresolve-callback
Conversation
Since libssh2 doesn't read host configuration from the config file, this callback can be used to hand over URL resolving to the client without touching the SSH implementation itself.
pks-t
left a comment
There was a problem hiding this comment.
Thanks for your amendments! One more thing, otherwise I'm good
|
somehow the build system does not automatically build at the moment |
|
/rebuild |
|
Okay, @pks-t, I started to rebuild this pull request as build #1839. |
|
Thanks for alerting, I didn't notice |
|
It looks like CI is building, but there's no status checks in our PRs anymore. @ethomson, got any clue why that is? |
Let me find out. |
|
/rebuild |
|
Okay, @pks-t, I started to rebuild this pull request as build #1847. |
|
Trying another rebuild, as I saw other PRs do have checks again. |
|
I don't 100% understand the checks architecture between GitHub and Azure Pipelines, but I think that there's only one-shot to get this hooked up. I think that GitHub notifies Azure Pipelines at PR creation and Azure Pipelines then sets itself up as a check. I think that one of those two deliveries failed, and so now this PR will forever not have checks from Azure Pipelines. Unfortunately that means we'll have to click through to the build manually. I'll raise an issue to see if we can investigate. |
|
Well https://dev.azure.com/libgit2/libgit2/_build/results?buildId=1847 says all checks have passed. Shouldn't that suffice? |
Absolutely. @tiennou what are you thinking here? |
|
Weeell, on one hand I have some concern about adding a "backend" (this word ^^)-specific function that's more or less a workaround, eg. if I were to add libssh to the party*, I'd had to handle this customization point on top of its On the other hand, I understand where this is coming from, the libssh2 project has limited bandwidth at the moment, and it really is a big chunk of actual missing functionality. Because of all this I'm reluctant to shot it down… * which I'm debating doing, just so I can finally stop worrying about baking libssh2-specific things in our 1.0 interface 😉. |
|
Indeed the impetus for this functionality came from the libssh2 limitation, however this does feel generally useful. It's basically programmatic |
tiennou
left a comment
There was a problem hiding this comment.
Hmm, okay, I think if we make it explicitly clear that this might not be the actual, final URL passed to the transport, I'm satisfied from a technical standpoint (ie. a libssh backend is by design allowed to re-substitute its own URL). This is the complexity I'm concerned about: this feels like a can of worm to me, like substituting the URL once, causing the lower layer to not recognize it anymore… Maybe I'm just too paranoid though 🤣.
I've reviewed this more closely, I think there's still a potential allocator mismatch lurking, but apart for that, if that's something we want and the specification is a little more fleshed out, I'm fine.
|
I'm happy with this I'm heads-down on the day job though so I'm very scattered, and I'd like to hold off just to make sure that I haven't missed anything before we 🚢 this. |
|
Sorry, to clarify, hold off for another core contributor to 👍 this in case I'm missing something. |
I tried to move the original PR to another branch on my fork, and Github auto-closed my PR.
This is a new one replacing #5028.
Sorry for the dupe.
Since libssh2 doesn't read host configuration from the config file,
this callback can be used to hand over URL resolving to the client
without touching the SSH implementation itself.
Example:
Remote
originhas URLThis would obviously fail with the current libgit2 implementation,
given the following SSH config:
The URL callback allows this to be rewritten to e.g.
by the client without much hassle.