Bug tracker import code (moved): Difference between revisions
Content added Content deleted
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
Here's what you need to know: |
Here's what you need to know: |
||
* Each ''style'' (like "Bugzilla", "Roundup", and so forth) of bug tracker has its code in mysite/customs/bugtrackers/'' |
* 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. |
* 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 |
||
** This class's __init__() is built so that an instance has enough data that a call to grab() will start downloading bug data. |
** This class's __init__() is built so that an instance has enough data that a call to grab() will start downloading bug data. |
||
Revision as of 23:46, 23 August 2010
Here's what you need to know:
- Each style (like "Bugzilla", "Roundup", and so forth) of bug tracker has its code in mysite/customs/bugtrackers/Template: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
- 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 .
So if you want to add a new Roundup-based bug tracker, add a new subclass to that file, and submit a patch.
(Wondering how to submit a patch? Read how we handle patches.)