[github.d] don't mention bugzilla for phobos PRs #305
Conversation
| @@ -51,6 +51,11 @@ string markdownEscape(string desc) | |||
| return app.data; | |||
| } | |||
|
|
|||
| bool usesGitHubIssues(in ref PullRequest pr) | |||
There was a problem hiding this comment.
normally I would do usesBugzillaIssues but I don't know what the full set of repos that use it are.
There was a problem hiding this comment.
Were you looking for this?
dlang-bot/source/dlangbot/bugzilla.d
Lines 8 to 10 in fddfa35
|
This doesn't look like the right fix. Wouldn't we want to simply encourage people to create GitHub issues instead of Bugzilla issues for these repositories? We do want to keep the policy that a PR references an issue, right? Otherwise that pulls in questions such as what to list in the changelog. |
I would expect that the move to github would just change which issues we're referencing. So, instead of something like |
|
We technically don't need the bot to support GitHub issues, since GitHub takes care of the duties that the bot performed on Bugzilla (linking PRs in issues when one is created to address it, and closing issues that fix PRs). I think the only thing that may need changing is the warning that is shown if a PR doesn't reference any issues at all. |
Well, if github manages it automatically somehow, then great. But presumably we then need the instructions on PRs to tell you whatever it is that you need to put into the commit message instead of what we've been doing so that github will pick it up properly in addition to not mentioning bugzilla any longer. And either way, we'll likely need to change the changelog generator so that it understands the change and provides links to github where appropriate instead of bugzilla (though that's obviously separate from these changes). |
| @@ -51,6 +51,11 @@ string markdownEscape(string desc) | |||
| return app.data; | |||
| } | |||
|
|
|||
| bool usesGitHubIssues(in ref PullRequest pr) | |||
| { | |||
| return pr.repoSlug.among("dlang/phobos"); | |||
There was a problem hiding this comment.
It looks like this needs to be compared against 0, since among returns 0 if it's not found and a one-based index of which one was found if one is found.
No description provided.