| Summary: | Bug Janitor Suggestion: Add comment if merge request description is edited with a new "BUG:" keyword | ||
|---|---|---|---|
| Product: | [Websites] bugs.kde.org | Reporter: | Luke Horwell <code> |
| Component: | general | Assignee: | KDE sysadmins <sysadmin> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | bcooksley, duha.bugs, nate, sheedy, sitter |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
You need the colon, so only "BUG: 123" works. I'm not sure if it's possible to do this based on MR description editing. And if it is, it may increase server load in an unacceptable way. I'll let others answer those questions, though (CCd). Not sure that's worth the engineering time TBH. When it didn't work it's fairly obvious and you can just post a manual message on the bug. Solving this via automation does require a fair amount of testing to not have negative side effects. docs are at https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages Server load wise the Gitlab webhook that is used to advise the integration component receives notifications of updates to merge requests already so this wouldn't impose any additional load on Gitlab. The issue though is the engineering challenge as Harald has noted - as you wouldn't want to spam notifications on Bugzilla just because someone tweaks a description. I'd therefore expect it to do more harm than good. See https://invent.kde.org/sysadmin/gitlab-react/-/blob/master/Triager/WebEvents.py?ref_type=heads for the code that drives this. Thank you for the feedback and information. On reflection, it seems like it's not worth it. The current "static" approach (once, on open, on close) will be more reliable then risking a "dynamic" aspect. I was thinking it would enumerate the Bugzilla comments (authored by bot) before commenting, but I hadn't dug deeper into these APIs. There's always the risk of breakage if the string changed in future, as well as increased maintenance if/when an API or library changes. Completely missed that area of the wiki, my bad. My searches and entry points yesterday kept me within the "Get Involved" areas. Didn't spot any links towards the "Policies" area. The previews when searching the wiki wasn't as obvious: - https://community.kde.org/index.php?search=%22BUG%3A%22&title=Special%3ASearch&profile=default&fulltext=1 [Yesterday] - https://community.kde.org/index.php?search=%22BUG%3A%22+keywords&title=Special%3ASearch&profile=default&fulltext=1 [Today] I see now it is also mentioned in: https://community.kde.org/Infrastructure/GitLab#Write_a_good_commit_message and https://community.kde.org/Infrastructure/Git/Hooks#Keywords too. Thanks again for considering the suggestion! |
SUMMARY The bug janitor adds a comment "A possibly relevant merge request was started @ " when a merge request is opened with the "BUG:" keyword on a line. However, I typically can't remember what is valid syntax for this to work ("BUG 123" or "BUG: 123"? Does "Bug 123" work too?). In particular, by editing the MR description, nothing happens. I struggled to find any documentation or code (https://invent.kde.org/sysadmin/bugzilla-bot) that directly uses this string, so I'm not sure where/how it works. I'd guess it's some kind of webhook in GitLab. As a suggestion, please could: * The documentation/wiki describe the optional keywords like "BUG:" or "CCBUG:" when a creating a merge request that directly fixes a bug. Perhaps include whether the janitor runs on a timer (e.g. every hour) or only at time of the MR being opened. * Add a mechanism/hook into GitLab so: - When a merge request description is edited, summon bot. - Bot reads Bugzilla comments. If "A possibly relevant..." comment was found for bug, skip. Otherwise, add comment. STEPS TO REPRODUCE 1. Open a merge request that fixes a bug, but don't add "BUG: XXX" 2. Edit the description in the merge request and add "BUG: XXXX" (XXX = bug report number) OBSERVED RESULT Bug janitor doesn't inform the bug report. Developer unsure if janitor will ever come back. EXPECTED RESULT Bug janitor posts "A possibly relevant merge request was started" if the description is updated with new bug references.