Auto-nominate for backport a pull request fixing a regression

[apiraino]

From #1184:

We should nominate PRs for backport if any of the following are true:

1. Description mentions a issue which is labeled as [regression]
2. Description mentions a issue which is milestoned with the beta version number

---

This patch implements point (1) and adds a check when a new PR is opened. The new backport.rs handler tries to figure to out if a PR should be nominated for backport.

This handler is enabled by adding a new [backport] config item. The format allows multiple instances of the config so teams can handle backports as they wish.

# "foo" is just to disambiguate multiple instances of this config
[backport.foo]
# The pull request MUST have one of these labels
required_pr_labels = ["T-compiler"]
# The regression MUST have this label
required_issue_labels = "regression-from-stable-to-beta"
# if the above conditions matches, the PR will receive these labels
add_labels = ["beta-nominated"]

[backport.bar]
required_pr_labels = ["T-compiler"]
required_issue_labels = "regression-from-stable-to-stable"
add_labels = ["beta-nominated", "stable-nominated"]

[backport.baz]
required_pr_labels = ["T-libs", "T-libs-api"]
required_issue_labels = "regression-from-stable-to-stable"
add_labels = ["stable-nominated"]

The workflow that models the decision to add the backport label is:

0. Someone files a regression #123, with a t-label (ex. "T-compiler")
1. Contributor opens PR #456, adds comment "Fixes #123"
2. triagebot receives the event "new PR"
3. triagebot parses the opening comment and retrieves originating regression(s)
   3a. checks if PR has the required team labels (reads from required_pr_labels), loads the appropriate config
   3b. checks if issue has a regression-from-* label (reads from required_issue_labels)
   3c. checks the P-label of the regression, discard P-low and P-medium regressions
4. triagebot adds backport label(s) to PR Implement the prioritize command #456 (reads from add_labels)

TODOs

Situations not yet handled where this handler should trigger as well:

• PR is opened without a T-label (can that happen? or is that automatically applied?), user adds a T-label to the PR later
• The regression receives a P-label when the PR fixing it already exists
• The expected marker text ("Fixes, resolves, etc.") is added later
• probably other cases ...

This work supersedes #1380 (Important: before merge this commit should be Co-authored¹)

r?

Footnotes

1. Not doing now to avoid spamming the original author with multiple forced git push 🙂 ↩

[Urgau]

Suggested change

	.expect("Failed to cast issue_num to string")
	.with_context(|| format!("failed to get issue_num from {caps:?}"))?

[apiraino]

Does this change actually compile for you? I can't make it compile and it seems to be a bit fiddly to make it work.

Details

error[E0277]: `?` couldn't convert the error to `std::string::String`
   --> src/handlers/backport.rs:106:79
    |
106 |             .with_context(|| format!("failed to get issue_num from {caps:?}"))?;
    |              -----------------------------------------------------------------^ the trait `From<anyhow::Error>` is not implemented for `std::string::String`
    |              |
    |              this can't be annotated with `?` because it has type `Result<_, anyhow::Error>`
    |
    = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait

[Urgau]

I didn't try it locally but I'm surprised it doesn't work.

Looking around, I think it's due to handle_input not returning anyhow::Result but std-Result.