Ah ok, thanks for clarifying. That would be easier to implement.

I feel the source code URLs should be generated by RepositoryBrowser (javadoc) implementations, because those already need to know about the URL format of the software that serves the files to Web browsers. Whether that is a version-control system like GitHub or separate code-review software.

If Jenkins built a pull request merge, then it may be impossible to generate URLs for the merged files. Even if the code-review software supports such URLs, it might not merge the versions in exactly the same way. The RepositoryBrowser implementation should be told about the merge so that it can decide whether it wants to try constructing a URL or just give up.

SCMRevision (javadoc) seems the obvious type to use for this, as you could then use ChangeRequestSCMRevision (javadoc) to represent the merge. However, these types are in scm-api-plugin while RepositoryBrowser is in core, so one cannot just add an Optional<URL> getFileLineLink(SCMRevision revision, String path, int startLine, int endLine) method to RepositoryBrowser. Instead, scm-api-plugin could define an interface with such a method, and individual RepositoryBrowser implementations could then implement that interface.

The SCM API does not really provide a good API for such use cases. A couple of weeks ago I failed to add simple hyperlinks to Git commits in my plugin, so I needed to extend the Git plugin. The same needs to be done here...

I guess you mean https://github.com/jenkinsci/git-plugin/pull/1034 and https://github.com/jenkinsci/git-forensics-plugin/pull/241. For the source line links though, I don't think the API should be specific to Git. There are RepositoryBrowser implementations for other version-control systems, and at least some of them could implement the source line link API.

For example, the RhodeCode software apparently supports https://try.rhodecode.com/ci-notify/files/3ad87bf0c7e571c685989e843936f16e945a899c/notify.py#L6 in a Mercurial repository. https://try.rhodecode.com/ci-notify/files/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md however seems problematic because it renders the Markdown to HTML and does not output anchors for line numbers. https://try.rhodecode.com/ci-notify/raw/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md outputs the original Markdown but that's text/plain and so has no anchors at all. Perhaps the hyperlink would have to use https://try.rhodecode.com/ci-notify/annotate/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md.

My scenario is that we have binary files in version control (using Git LFS), and build steps sometimes output warnings about these files. In such cases, Warnings NG copies the files to the controller and displays them as text, which is not helpful at all. The Jenkinsfile in that project might be considered a bit incorrect, as it specifies sourceCodeEncoding: 'UTF-8' in the recordIssues step and that then applies to the binary files too; but well, there is no option to exclude file patterns from this encoding claim.