www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Marrying bugzilla issues with git pull requests

reply Andrew Edwards <ridimz yahoo.com> writes:
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
Sep 25 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 25 September 2014 at 13:53:15 UTC, Andrew Edwards 
wrote:

 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.


 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.
Sep 25 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 25 September 2014 at 14:11:58 UTC, Vladimir 
Panteleev wrote:

 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
Sep 25 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
On 9/25/14, 11:14 PM, Vladimir Panteleev wrote:

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

 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.
Sep 25 2014
prev sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 9/25/14, 11:11 PM, Vladimir Panteleev wrote:

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

 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.


 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.


Noted... but since I am relying on the implementation that Brad uses, 
this will do very little to aid my current situation.
Sep 25 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrew Edwards"  wrote in message news:m019d3$1tuj$1 digitalmars.com...


 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.
Sep 25 2014