Proposal: add issue number to PR title

One problem is that the closingIssuesReferences field outputs the closing issue. I don’t think all PRs will close an issue.

Will there be some issues that cannot be directly closed by one PR, but need to pass multiple PRs before they can be closed?

I submitted a related PR, but the upstream reviewer will consider the issues about the increased API points.

@SunRunAway, @ichn-hu

I think it’s not a good way to use a bot to automatically determine which issue number should be filled in the commit message, even though GitHub provides the closingIssuesReferences field so that we can easily get the number of issues that will be closed by the PR, but in the actual situation, some PRs will be associated with an issue, but this issue may not be closed by it.

Another question is that can we use a pattern with less change to current style, see also:

… and just issue-x, issue-y: as pkg-a, pkg-b:. If someone still want pkg-a as issue-x: pkg-a: it is ok. But not required.

I think pkg: is intuitive and informative, issue-x requires more typing and is not intuitive, btw issue number is machine friendly, but never human friendly.

1 Like

if we really want the issue number in title, maybe

test: migrate test-infra to testify for types/etc_test.go; close #28002

is more eye friendly

I’m ok with either style. @Mini256 is there any technical blocker?

Will the issue number in commit message create an extra reverse link to the issue?

1 Like

May or may not depend on the format.

If #{number}, it will; if issue-number or other bare way, it will not.

I guess issue- would be a better idea.

I create another demo title.

@Mini256 please see whether we can implement checker with this format.

@disksing @ichn-hu please see whether it is in your style.

@SunRunAway for associate with multiple issues, one can use ; issue-1, issue-2 IMO.

If the length is a concern, we can shorten issue as TI or anything. We forbid cross repos mapping, just create a subtasks or mirror in the specific repo.

I think the use : and ; creates too many fields in the title and it is hard for me to interpret. I would personally prefer [issue-28076] or (issue-28076) or [28076] or (28076).

It would be nice to be able to accept documentation updates and without requiring an issue ahead of time. The logic would be to not validate if all files changed are markdown files.

Thanks for your comment. I agree that we can create exceptions later.

For TiDB / TiKV and other repositories except pingcap/docs*, there isn’t a significant percentage of such changes. Thus, let’s force every PR associated with issue(s). You can create an issue for tiny change, like . When we overcome the case now there are too many dangling PRs as well as release note sucks, we can bring this topic as an enhancement to our developers with better practices and behaviors.

For pingcap/docs, I’d delegate the decision to its maintainers.

Could you create a completed example? Actually I don’t have a strong feeling, but associated with an issue so that we don’t omit it.

Our PR number has already used (, ), so it is not recommended to use (, ) for the issue number.

In order to avoid ambiguity, I think it is necessary to add a prefix, whether it is issue-, #, or TI-.

pkg: fix something [123], after merged it becomes pkg: fix something [123] (#124)

Because PR numbers have prefix #, we can tell issue numbers from it. Anyway, I think add issue- or TI- prefix is also a good idea.

1 Like

So we are forced to fill issue number in PR body before, just like what other github projects do, now we are forced to also fill it in title? What’s wrong with the bot that all it needs have been written in the body and well formatted with template?

Now to get around the bot, we need to:

  1. tolerate ugly merge merge messages as it can’t handle PR content and signoff well
  2. we need to write issue number in title like no other github projects do to make it generate some messages helpful for git log.

Seriously, why not just let it parse PR body and generate good merge messages? Solve the problems for all instead of introducing another weird title format.

1 Like

How? I don’t see it now. Actually I’m ok with extracting from PR body, but it seems TiDE sucks on analyzing PR body and due to it hijacks the merge phase, we are stunk.

If it’s just for linking issues, I think we have a simpler way to do it. No need to introduce additional formats and tools.