chore(ci): reject uncanonicalized issue link in commits

[weihanglo]

What does this PR try to resolve?

This is needed if we want to turn cargo submodule into a subtree in
the rust-lang/rust repository (#15882), because
commits are cherry-picked with their messages left as-is, and the magic keyword
like fixes #99999 may unintentionally close issues in rust-lang/rust
while it was intended only for rust-lang/cargo issues.

Unlike check-commits = false, instead of rejecting any issue links
in commit messages, the "uncanonicalized" option still allows issues
in a canonicalized form, such as

• https://github.com/rust-lang/cargo/issues/15882
• rust-lang/cargo#15882

but the bare issue number like #15882 will be warned by triagebot
in a PR comment.

Drawbacks

It is bad because contributors will be forced to write commit messages
in a specific style. Worse if we decide not to be a subtree and then
this change puts unnecessary works on contributors.

Is it the last step towards #15882?

Personally I consider not. Because merge commit still contains
the PR number in the uncanonicalized form, as we use GitHub merge queue
and it hasn't yet support merge commit template.

However, this change on its own makes issue link more obvious and
less ambiguous, especially when reading from outside GitHub web UI.
It also stops us from adding more uncanonicalized issue links in the
future, which we already have too many in the past commits 2

There are some other concerns in #15882 (comment) and #15882 (comment). Until we resolve them and feel this is the only thing left, we might not want to merge this.

For discussions, see

• https://forge.rust-lang.org/triagebot/issue-links.html
• https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Turning.20cargo.20into.20a.20subtree/near/537951273
• Turning cargo into a git subtree in rust-lang/rust #15882

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[weihanglo]

cc @epage and @ehuss as you are both in the review rotation:

cargo/triagebot.toml

Lines 52 to 53 in a9e120f

	[assign.owners]
	"*" = ["@ehuss", "@epage", "@weihanglo"]

[epage]

The triagebot documentation doesn't make it clear why we are using this setting and the other two links have a lot of content in them for other topics.

Could you update the PR description with the motivation for this, summarizing the relevant parts of those conversations?

Also, how close are we for being ready for subtrees? Should this be one of the later things we do so we don't take on costs when we aren't getting the benefits?

[weihanglo]

Updated. Let me know if it is still unclear.

[epage]

The part related to the motivation that remained unclear was I didn't know that subtrees cherry pick all commits. That seems noisy for rustc but oh well, thats the choice they make.