Bug tracker import code (moved): Difference between revisions

Content added Content deleted

Inline

Revision as of 23:50, 23 August 2010

Here's what you need to know

One file per style of bug tracker

Each style (like "Bugzilla", "Roundup", and so forth) of bug tracker has its code in mysite/customs/bugtrackers/style.py. We write tests in mysite/customs/tests.py for each bug tracker type.

The Roundup code is instructive. Look at that in your favorite editor. You'll see class RoundupTracker. Take a look -- the class's __init__() is built so that an instance has enough data that a call to grab() will start downloading bug data.

The rest of that file is trivial subclasses that pre-fill the data to __init__(). We have one subclass per bug tracker we pull data from.

Then, once a day

We have a cron job on the server that calls the code in mysite/customs/management/commands/customs_daily_tasks.py every night.

How to add a new bug tracker

That means that if you want to add code pull data from a bug tracker we already support, you just have to write a very simple subclass. For Roundup, for example, add a few lines to the end of mysite/customs/bugtrackers/roundup.py. Then submit a patch.

If you want to write support for an entirely new type of bug tracker, you'll have to write a new class. Before we merge it, we'll need some tests, but we can help you write the tests. Submit your patches as you go, and we can review/merge quickly!

(Wondering how to submit a patch? Read how we handle patches.)

@@ Line 1: / Line 1: @@
-Here's what you need to know:
+Here's what you need to know
+== One file per style of bug tracker ==
-* Each ''style'' (like "Bugzilla", "Roundup", and so forth) of bug tracker has its code in mysite/customs/bugtrackers/''style''.py.
-* We write tests in mysite/customs/tests.py for each bug tracker type.
+Each ''style'' (like "Bugzilla", "Roundup", and so forth) of bug tracker has its code in mysite/customs/bugtrackers/''style''.py. We write tests in mysite/customs/tests.py for each bug tracker type.
-The Roundup code is instructive. Look at that in your favorite editor. You'll see:
+The Roundup code is instructive. Look at that in your favorite editor. You'll see ''class RoundupTracker''. Take a look -- the class's __init__() is built so that an instance has enough data that a call to grab() will start downloading bug data.
-* class RoundupTracker
-** This class's __init__() is built so that an instance has enough data that a call to grab() will start downloading bug data.
-The rest of that file is trivial subclasses that pre-fill the data to __init__(). That way, they can be called once a day by the mysite/customs/management/commands/customs_daily_tasks.py .
+The rest of that file is trivial subclasses that pre-fill the data to __init__(). We have one subclass per bug tracker we pull data from.
+== Then, once a day ==
-So if you want to add a new Roundup-based bug tracker, add a new subclass to that file, and submit a patch.
+We have a cron job on the server that calls the code in <code>mysite/customs/management/commands/customs_daily_tasks.py</code> every night.
-(Wondering how to submit a patch? Read [[how we handle patches]].)
+== How to add a new bug tracker ==
+That means that if you want to add code pull data from a bug tracker we already support, you just have to write a very simple subclass. For Roundup, for example, add a few lines to the end of mysite/customs/bugtrackers/roundup.py. Then submit a patch.
+If you want to write support for an entirely new type of bug tracker, you'll have to write a new class. Before we merge it, we'll need some tests, but we can help you write the tests. Submit your patches as you go, and we can review/merge quickly!
+(Wondering how to submit a patch? Read [[how we handle patches]].)
 [[Category:Hacking OpenHatch]]