Bundle size report 📦

Look at the Statoscope report for a full comparison between the commits 5b90793 and 3c0b695 or learn more.

I'm not sure if this approach is reliable.
In sourcegraph/sourcegraph repo pull request number is usually mentioned in the squash commit.
But other repositories may include GitHub/Jira/etc. issue number in the pull request name.
We are not sure whether the matching number in the commit message is a PR number, an issue number, or something totally unrelated.
For me, it seems better not to show the PR/issue link at all than to show the broken one.

Teams usually have contributing rules set on a repo basis (git workflow, PR names, etc.). What if we make rules for building the PR/issue/etc. links configurable on a repo basis? It may be a part of a code host configuration or something else. What do you think?

Thanks @taras-yemets!

So yeah, first of, this is NOT the same as finding the pull request. This is just about parsing the commit title and making links for issues. Finding the pull request is another problem that requires a third-party API and proper caching and lazy loading, etc.

But other repositories may include GitHub/Jira/etc. issue number in the pull request name.

Do you have an example of this? GitHub issues and GitHub PRs have interchangeable URLs. My code handles both (e.g. this PR is also available via https://github.com/sourcegraph/sourcegraph/issues/46409).

Do you have an example of the Jira issue number? Is it common to also highlight that with a hashtag in front? I’m using Linear and the issue numbers look like this C-123 where C is a project specific shortcut. This would not match my regex.

What if we make rules for building the PR/issue/etc. links configurable on a repo basis? It may be a part of a code host configuration or something else. What do you think?

I guess we could do this but it'd be tedious to set this up. Maybe a user setting instead that we enable on dotcom (since for open source GH repos this is a common pattern)?

I tagged a few more folks for review: All of you seem to have shown interested in this feature and I'd like to hear your ideas 🙂

GitHub issues and GitHub PRs have interchangeable URLs.

TIL 🙏🏻

❌ Problem: the label i-acknowledge-this-goes-into-the-release is absent.
👉 What to do: we're in the next Sourcegraph release code freeze period. If you are 100% sure your changes should get released or provide no risk to the release, add the label your PR with i-acknowledge-this-goes-into-the-release.

GitHub issues and GitHub PRs have interchangeable URLs. My code handles both (e.g. this PR is also available via https://github.com/sourcegraph/sourcegraph/pull/46409).

Yes, you're right, it should work for GitHub.

Do you have an example of the Jira issue number? Is it common to also highlight that with a hashtag in front? I’m using Linear and the issue numbers look like this C-123 where C is a project specific shortcut. This would not match my regex.

I've found a few and couldn't identify a specific naming pattern ([jira-123], ABC-123, etc.). We can probably assume that #1234 in the commit message may be a GitHub issue/PR.

Opening this up for review, why don't we test this on dot-com and/or S2 and see how it goes? Do you think this needs a feature flag (I don't think it's super invasive so I would keep it like this)