BMO/Integration Best Practice: Difference between revisions

From MozillaWiki
< BMO
Jump to navigation Jump to search
No edit summary
Line 22: Line 22:


* When searching among all closed or all open bugs, don't explicitly enumerate the states, as states may be added or removed. For open bugs, you can use "resolution=---" or "bug_status=__open__" (status=__open__ for BzAPI). For closed bugs, you can use "bug_status=__closed__".
* When searching among all closed or all open bugs, don't explicitly enumerate the states, as states may be added or removed. For open bugs, you can use "resolution=---" or "bug_status=__open__" (status=__open__ for BzAPI). For closed bugs, you can use "bug_status=__closed__".
* Similarly, when searching for bugs which were not fixed, don't enumerate all of the not-fixed resolutions. Instead do a boolean chart "is not string" search.
* Similarly, when searching for bugs which were not fixed, don't enumerate all of the not-fixed resolutions. Instead do a custom search using the "is not empty" operator.

Revision as of 14:04, 2 September 2013

If you are writing tools to integrate with bugzilla.mozilla.org (BMO), you want to make sure they keep working as intended as Bugzilla changes, and they avoid placing strain on the Bugzila infrastructure. Here are some tips and suggestions:

Guidelines

  • Do not poll more frequently than every 5 minutes
    • Seriously, you don't need to poll every minute
  • Ask for bugs updated since your last poll, or track a bug's last modified date
    • If your system is polling for bugs, you should ask BMO for bugs updated since your last poll.
    • The chfieldfrom argument will accept times as well as dates (eg. "2012-10-08 00:00")
    • Search results generally return a bug's last-modified date; there's no need to re-request the bug if it hasn't been modified since the last time you saw it
  • Only request the fields that you are interested in
    • By default all APIs return more information than you probably require - use the include_fields parameter to specify the exact fields you need (BzAPI)(XMLRPC/JSONRPC)
    • When searching with BzAPI, avoid specifying non-bold columns if you can avoid it, because it'll be slower and user server-side resources
  • Coalesce queries where possible
    • If you have multiple bugs, components, etc to query, it can be more efficient issue a single request rather than iterating over your list and issuing multiple requests

API

BzAPI (the REST API proxy) has an API stability commitment. Bugzilla's own direct XML-RPC and JSON-RPC APIs have stability commitments within a major version of Bugzilla, as long as the call in question is not marked as experimental (see the API docs for the version in question). Other more ad-hoc ways of integrating, such as buglists-as-CSV and bugs-as-XML, don't have such commitments. Pick a stable API to use.

Searching

  • When searching among all closed or all open bugs, don't explicitly enumerate the states, as states may be added or removed. For open bugs, you can use "resolution=---" or "bug_status=__open__" (status=__open__ for BzAPI). For closed bugs, you can use "bug_status=__closed__".
  • Similarly, when searching for bugs which were not fixed, don't enumerate all of the not-fixed resolutions. Instead do a custom search using the "is not empty" operator.
Retrieved from "https://wiki.mozilla.org/index.php?title=BMO/Integration_Best_Practice&oldid=702136"