Bug tracker import code (moved): Difference between revisions
Content added Content deleted
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= Disambiguation = |
|||
Here's what you need to know |
|||
Which do you want to read about? |
|||
== One file per style of bug tracker == |
|||
* The [[Bug tracker import code/architecture|architecture of bug tracker import code]], or |
|||
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. |
|||
* [[Bug tracker import code/adding a bug tracker|a step-by-step guide on adding a bug tracker]] |
|||
Up to you. |
|||
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 <code>mysite/customs/management/commands/customs_daily_tasks.py</code> 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]].) |
|||
| ⚫ | |||
Revision as of 15:03, 26 August 2010
Disambiguation
Which do you want to read about?
Up to you.