Inspirated

 
 

June 9, 2010

Summer of Code Progress: Unit testing and merge proposals

Filed under: Blog — krkhan @ 4:30 pm

Related Links

Summer of Code Archive Inspirated Code
Report Guidelines Ubuntu Wiki
Original Proposal Ubuntu Wiki

Time Spent

20 hours.

Highlights

The process of “presenting” my code to a giant project like Launchpad made me learn a lot about how to plan, execute and test modifications for large-scale open source projects. It’ll be fun to see the final outcome merged upstream.

I am also feeling more and more confident dealing with Launchpad development. It’s gratifying to know that if I need some API calls during the course of my SoC work which aren’t already there, I’ll be able to implement them on short notices.

Concerns

As per the discussion with Bryce, the approach for attachment search needs to be changed a bit. Instead of going through the “Product -> Bugs -> Attachments” route, we need to instead focus on the “Team -> Source Packages -> Bugs -> Attachments” alternate.

Waiting Items

None.

Stalled Items

None.

Accomplishments

  • Patch: Added unittest for bugs collection.
  • Patch: Added unittests for bugs.findAttachments.
  • Written merge proposal for project-bug-collection branch:

    Merge proposal for lp:~inspirated/launchpad/project-bug-collection

    Summary

    As part of my Google Summer of Code project, I had to implement attachment searching functionality in Arsenal. The end-product would allow user to specify a search string which would be searched in all the bug attachments for a project.

    Doing this efficiently required two modifications in Launchpad:

    • Exposing a bug collection for a particular product (this branch)
    • Implement an attachment search method for a particular bug
    Proposed fix

    Export a bugs CollectionField for IProductPublic.

    Pre-implementation Notes
    • The exported field should be read-only
    Implementation Details
    • Bug schema does not refer to Products directly. Therefore, a join was required to query BugTasks which point towards the Product in question and then query the Bugs related to that BugTask.
    Tests
    $ bin/test -vv -m lp.registry.tests.test_product -t test_bug_collection
    Demo and Q/A

    Create a Launchpad instance:

    	>>> from launchpadlib.launchpad import Launchpad
    	>>> launchpad = Launchpad.login_with('just testing', 'https://api.launchpad.dev/beta/')
    	The authorization page:
    	   (https://launchpad.dev/+authorize-token?oauth_token=ppd2bRZDnN6VX94lRqrq)
    	should be opening in your browser. After you have authorized
    	this program to access Launchpad on your behalf you should come
    	back here and press <Enter> to finish the authentication process.

    Load a project:

    	>>> project = launchpad.projects['firefox']
    	>>> project
    	<project at https://api.launchpad.dev/beta/firefox>
    	>>> project.bugs
    	<lazr.restfulclient.resource.Collection object at 0x925c04c>

    Use the bugs collection:

    	>>> for bug in project.bugs:
    	...     print bug.title
    	... 
    	Firefox does not support SVG
    	Reflow problems with complex page layouts
    	Firefox install instructions should be complete
    	Firefox crashes when Save As dialog for a nonexistent window is closed
    lint

    The changes are lint clean.

  • Written merge proposal for implement-Bug-findAttachments branch:

    Merge proposal for lp:~inspirated/launchpad/implement-Bug-findAttachments

    Summary

    As part of my Google Summer of Code project, I had to implement attachment searching functionality in Arsenal. The end-product would allow user to specify a search string which would be searched in all the bug attachments for a project.

    Doing this efficiently required two modifications in Launchpad:

    • Exposing a bug collection for a particular product
    • Implement a attachment search method for a particular bug (this branch)
    Proposed fix

    Export a read operation findAttachment in IBug which returns a collection of IBugAttachment.

    Pre-implementation Notes
    • The search operation is essentially a text-only grep.
    Implementation Details
    • Zope configuration had to be updated to export the method
    • Multi-line searches break the GET request with a “HTTP/1.1 400 Bad Request” response
    • The attachments are all opened as regular file objects and then searched for the target pattern.
    Tests
    bin/test -vv -m lp.bugs.tests.test_bug_find_attachment
    Demo and Q/A

    Open any Launchpad bug in a browser:

    	https://launchpad.dev/bugs/15

    Create an attachment and upload any text file containing the string ‘char buf’.

    Create a Launchpad instance:

    	>>> from launchpadlib.launchpad import Launchpad
    	>>> launchpad = Launchpad.login_with('just testing', 'https://api.launchpad.dev/beta/')
    	The authorization page:
    	   (https://launchpad.dev/+authorize-token?oauth_token=ppd2bRZDnN6VX94lRqrq)
    	should be opening in your browser. After you have authorized
    	this program to access Launchpad on your behalf you should come
    	back here and press <Enter> to finish the authentication process.

    Load the bug:

    	>>> bug = launchpad.bugs[15]

    Search for the attachment containing the string ‘char buf’:

    	>>> results = bug.findAttachments(text=u'char buf')
    	>>> for attachment in results:
    	...     print attachment.title
    	... 
    	Buffer Overflow Intro.txt
    lint

    The changes are lint clean.

Minor Tasks

Around 8 hours were spent trying to find out why on earth my API calls weren’t getting recognized by apidoc or launchpadlib. In the end, Leonard Richardson pointed out that I was missing a make clean for regenerating the WADL cache. Can’t say it feels great to know that overlooking a build command resulted in so many hours of thorough debugging.

I had another issue with Librarian not recognizing the attachment files created during unittests. Luckily it was resolved quickly when Tim Penhey suggested that I need to commit the local transaction in order for the Librarian to see it.

A minor bug with my previous commits was also fixed which resulted in TypeErrors since the arguments weren’t being sent as Unicode strings.

Actions for the Following Report

As outlined earlier on, “Team -> Source Packages -> Bugs -> Attachments” search is the next target.

Tags: , , , , , , , , ,

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

One small verification for man, one giant PITA for bots: