Marrying bugzilla issues with git pull requests

[Andrew Edwards via Digitalmars-d]

Currently a mention of a bugzilla issue number on a git pull request
triggers an automatic update of the issue when then pull gets merged.
There is also a trend of placing a link an applicable pull in the
comments section of the issue. I would like to request a formal location
in the header of the ticket to identify store this like instead. This
could be easily accomplished by appropriating and renaming the seldom
(if ever) used URL field and ensuring it accepts multiple urls (similar
to See Also). Or, if that is not possible, by adding a Pulls filed below
See Also.

This would provide a uniformed location to see if a pull exists for a
specific issue and allow for the automatic query of such information.

I currently need this functionality in a script i am writing to prepare
the update information for the beta release wiki pages. Since this
information is usually stored on the ticket it should be simple to
retrieve it but I am not sure how to do so from the comments. If the the
information was placed in a standard location in the header, it would
make things much simpler.

In it's current form the script looks like this:

<CODE>
import std.csv;
import std.net.curl : get;
import std.string;
import std.stdio;
import std.typecons;

pragma(lib, "curl");

void main()
{
// designate query url
auto front = "https://issues.dlang.org/buglist.cgi?bug_severity=";
auto back =
"&order=bug_id&query_format=advanced&resolution=---&ctype=csv&human=1";
auto regressions = front ~ "regression" ~ back;
auto blockers = front ~ "blocker" ~ back;

auto result = get(regressions).idup.splitLines[1 .. $];
printIssues("Regressions", result);

result = get(blockers).idup.splitLines[1 .. $];
printIssues("Blockers", result);
}

void printIssues(string issues, string[] result)
{
alias format = Tuple!(string, string, string, string, string, string,
string, string);

auto color = "orange";
if (issues == "Blockers")
color = "red";

writeln(`== <font color=` ~ color ~ `>'''Known ` ~ issues ~ `'''</font>
==`);
writeln(`{| class="wikitable sortable" border="1"`);
writeln(`|-`);
writeln(`! scope="col" | Issue`);
writeln(`! scope="col" | Repo`);
writeln(`! scope="col" class="unsortable" | Summary`);
writeln(`! scope="col" | Pull`);
writeln(`! scope="col" | Status`);

foreach (ndx, line; result) {
foreach (record; csvReader!(format)(line))
{
writeln("|-");
writeln("| [https://issues.dlang.org/show_bug.cgi?id="~record[0] ~"
"~ record[0]~"]");
writeln(" || ");
writeln(" || " ~ record[6]);
writeln(" || ");
writeln(" || ");
}
}
writeln("|}");
}
</CODE>


If there is a better way, I would appreciate guidance toward that
direction also.

Thanks,
Andrew

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 25 September 2014 at 13:53:15 UTC, Andrew Edwards

Post by Andrew Edwards via Digitalmars-d
This would provide a uniformed location to see if a pull exists
for a specific issue

For the record, for this particular problem we use the "pull"
keyword. Posting a fixing pull URL as a comment by itself is also
prevalently common, perhaps it would be easier to standardize
that instead.

Post by Andrew Edwards via Digitalmars-d
If there is a better way, I would appreciate guidance toward
that direction also.

Well, ideally, it would be better to use an API instead of
parsing HTML.

The current Bugzilla does not expose an API (I understand it's
planned for the next major Bugzilla version). The blessed way to
programmatically query a Bugzilla instance seems to be to use
BzAPI, which works like a proxy - exposing an API while talking
to a slighty-patched Bugzilla instance:

https://wiki.mozilla.org/Bugzilla:BzAPI#Your_Own_Installation

However, I don't think we'll be able to convince Brad to patch
D's Bugzilla installation to support BzAPI, since he declined
previous similar requests.

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 25 September 2014 at 14:11:58 UTC, Vladimir

Post by Andrew Edwards via Digitalmars-d
If there is a better way, I would appreciate guidance toward
that direction also.

BTW, for a similar project[1] I parse DFeed's local cache of the
digitalmars.D.bugs emails. It mostly works, but some issue change
notifications are not sent to the group for some reason, so the
data is a little incomplete.

[1]: https://github.com/CyberShadow/DBugTests

[Andrew Edwards via Digitalmars-d]

Post by Vladimir Panteleev via Digitalmars-d

Post by Andrew Edwards via Digitalmars-d
If there is a better way, I would appreciate guidance toward that
direction also.

BTW, for a similar project[1] I parse DFeed's local cache of the
digitalmars.D.bugs emails. It mostly works, but some issue change
notifications are not sent to the group for some reason, so the data is
a little incomplete.
[1]: https://github.com/CyberShadow/DBugTests

Thanks for the link. Will take a look.

[Andrew Edwards via Digitalmars-d]

Post by Andrew Edwards via Digitalmars-d
This would provide a uniformed location to see if a pull exists for a
specific issue

For the record, for this particular problem we use the "pull" keyword.
Posting a fixing pull URL as a comment by itself is also prevalently
common, perhaps it would be easier to standardize that instead.

Understood, but there is no way for me to actually identify THE pull
request(s) that fix(es) an issue among the comments, even if pulls are
placed in their own comments. There is always a chance that a linked
comment is incorrect or that the pull didn't actually address the issue
and was closed in favor of a better implemented solution (or simply
closed with no alternative provided). At those times there are multiple
links, and only some (or one) of them may actually apply.

Since the comment cannot be deleted or modified once posted, it is not
the best place to put such information. Better to have a modifiable
field where errors can be corrected, additional information can be
added, and irrelevant information removed.

Post by Andrew Edwards via Digitalmars-d
If there is a better way, I would appreciate guidance toward that
direction also.

Well, ideally, it would be better to use an API instead of parsing HTML.
The current Bugzilla does not expose an API (I understand it's planned
for the next major Bugzilla version). The blessed way to
programmatically query a Bugzilla instance seems to be to use BzAPI,
which works like a proxy - exposing an API while talking to a
https://wiki.mozilla.org/Bugzilla:BzAPI#Your_Own_Installation
However, I don't think we'll be able to convince Brad to patch D's
Bugzilla installation to support BzAPI, since he declined previous
similar requests.

Noted... but since I am relying on the implementation that Brad uses,
this will do very little to aid my current situation.

[Daniel Murphy via Digitalmars-d]

Post by Andrew Edwards via Digitalmars-d
Understood, but there is no way for me to actually identify THE pull
request(s) that fix(es) an issue among the comments, even if pulls are
placed in their own comments. There is always a chance that a linked
comment is incorrect or that the pull didn't actually address the issue
and was closed in favor of a better implemented solution (or simply closed
with no alternative provided). At those times there are multiple links,
and only some (or one) of them may actually apply.

Does the query have to be fast? Once you have the potential pull request
url, you could query github and look for the "fixes issue NNNN" etc in the
commit messages that github greps for. If they link back to the same
bugzilla issue, chances are the link was correct. Most pull requests will
also have a link to the bugzilla issue in the description.