Summer of Code Progress: Unit testing and merge proposals
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
bugscollection. - Patch: Added unittests for
bugs.findAttachments. - Written merge proposal for project-bug-collection branch:
Merge proposal for
lp:~inspirated/launchpad/project-bug-collectionSummary
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-findAttachmentsSummary
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: API, Arsenal, Code, GSoC, Launchpad, Open Source, Python, REST, Ubuntu, Unit Testing