Bug tracker import code/adding a bug tracker (moved): Difference between revisions

no edit summary
No edit summary
imported>Pythonian4000
No edit summary
Line 21:
=== Edit the right file ===
 
Each file has twoseveral parts...
 
* '''One simple bit of code per project bug tracker we download data from''': This is what you want. It's usually toward the end of the file. This is usually a five-line Python class.
* '''The raw code that goes out to the network and fetches data''': This is probably not what you want.
* '''A general Python class for all project bug trackers of a particular type''': Also probably not what you want. This contains all the methods that every project bug tracker requires, to simplify the code structure.
* '''One simple bit of code per project bug tracker we download data from''': This is what you want. It's usuallya towardPython class that sub-classes the endgeneral ofone and contains the file.bits Thisof iscode usuallyspecific ato five-lineeach Pythonproject classbug tracker (such as the project name).
 
To add a new bug tracker, takego anto existingthe bugvery tracker'send shortof codethe snippetfile for the correct tracker ''type'' and copy-paste the generic class. Paste it, adjustingjust whatabove youand needthen toedit as adjustnecessary. You'llThere are several things that you will definitely need to change in the project nameclass, andlike you'llthe probablyproject needname toand providethe URLs for fetching a list of bugs to import, and there are a few things that are optional - read the comments, and look at other project bug trackers in the file, to understand what each bit does.
 
=== Make sure it works ===
Line 35 ⟶ 36:
 
you should trigger your code. In your local version of OpenHatch, you'll see the new volunteer opportunities listed at http://127.0.0.1:8000/search/.
 
You can monitor diagnostics about the bug importer in two ways. A quick interface for checking the number of stale bugs (bugs older than one or two days) is the diagnostic page at http://127.0.0.1:8000/+meta/.
 
For more in-depth analysis you can use the customs debugger, which contains several handy methods for managing Bug objects - useful if, for example, you always end up with ten stale bugs at the end of an import and want to find out what they are. Just run:
 
$ ./bin/mysite customs_debugger help
 
to see available options.
 
If your new bug tracker code doesn't get called, make sure you set ''enabled = True'' in the subclass.