This is a good idea, but idk if I'd address it in this way. In general, we want more (much more) traceability from Kargo back to PRs, commits, diffs, etc., and there are quite a number of issues open relating to that. I think the best UX here, probably, is to improve the various implementations of gitprovider.Interface with an intrinsic understanding of how to construct various sorts of URLs for their given platform. I'd much prefer Kargo just knowing how to do that than having to specify linkPathFormat in every Warehouse.

Makes sense, so would each interface have to support links to commits and Pull Requests? Or are Pull requests links already supported as part of the PR promotion steps?

Yes. The interfaces would need to be expanded with methods that construct these URLs. For any PR URLs that are currently constructed, it's happening way down the stack in the libraries that the provider implementations use to talk to their corresponding services.

I'd be happy to take this and give it a go

Thanks @BenHesketh21! That would be much appreciated!

I think adding the relevant methods to each provider will end up being the easy part. Actually surfacing that information in a meaningful way is something I haven't even thought about yet. My initial thought is that this is could be surfaced in the output from the commit step, but I really haven't thought that all the way through yet. Feel free to hit me up to discuss that aspect of this further.

I'll also volunteer @Marvin9 in case you need any guidance on how to then surface these new details in the UI. I myself am no good with UI stuff. 😂

This will be covered as part of revamping freight timeline and overall pipeline view

@krancour I'm making a start on this now and I can see that the URL for a pull request is already returned from the GetPullRequest, ListPullRequests and CreatePullRequest methods in the gitprovider.interface. With the view of being consistent should we add a GetCommit method that passes on the SHA, commit message and URL back from the hosting provider? Or do you still there is value on methods that accept a repoURL and sha (or PR number) and just build the URL?

@BenHesketh21 great question, and it's leading me to clarify something I wasn't previously consciously aware of enough to have mentioned... but which you may already have figured out...

Don't assume there's any pull request involved here. There may not have been. Writes back to a Git repo, especially in non-prod environments, are often just a push directly to some branch.

So while the providers are currently used only to facilitate opening and checking the status of pull requests, I think we're talking about entirely new use for them here.

A method named something like GetCommitURL() or BuildCommitURL() seems it would be appropriate. It would use provider-specific knowledge to construct the URL as a function of two arguments -- repo URL and commit ID.

Actually surfacing that information in a meaningful way is something I haven't even thought about yet. My initial thought is that this is could be surfaced in the output from the commit step, but I really haven't thought that all the way through yet.

Having thought about this more now, it should be output of the push step, because unless/until a commit is pushed to the remote repository, any URL we build would yield a 404 when requested.