New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve integrations between Nitrate and bug tracking systems #185

Open
atodorov opened this Issue Apr 29, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@atodorov
Contributor

atodorov commented Apr 29, 2017

With the work done in #79 I have removed some bits which didn't make sense or need better implementation. With the introduction of arbitrary bug tracking systems we need a better way to figure out how to attach test cases to them, how to file bugs from Nitrate, etc.

So far I'm thinking about providing some common integrations for the most popular bug trackers and let the user configure them in the UI (DB preferably) when they define their bug tracker of choice.
Here are some notes:

  • In test case run, Add bug dialog, there was a Check to add test cases to BZ checkbox, see
    #79 (comment). This checkbox is controlled via the BUGZILLA_EXTERNAL_TRACKER setting:
    • The setting only disables actions, doesn't hide the checkbox from UI, needs to be fixed
    • tcms.integrations.bugzilla.signals.bugs.BZ_Externer_Track_Thread appears to be similar to tcms.integrations.bugzilla.tasks.bugzilla_external_track
    • bugzilla_external_track doesn't read the bugzilla URL from the DB but instead relies on settings. We can improve this by storing this info into the DB and make it easier to configure via the UI.
  • This task seems to require celery and I don't recall seeing a section about celery or how to run celery nodes in the documentation. Also not everyone wants to use Celery and add external messaging layer for it so think about providing a simple implementation running on localhost (or maybe even in synchronous mode)
  • In test case run, there is a "File" bug link, which is processed by testruns.views.bug and its internal class CaseRunBugActions. Currently this gives 500 ISE and needs to be reworked to support arbitrary bug trackers
  • Test run bugs report page used to show Bugzilla & JIRA links at the bottom of the screen. These were links which open all reported bugs with one click, see #79 (comment). This has been removed as part of #79 and needs to be added back but in a more clever way.

I will be working on this next, but filing here so I don't forget all the details.

NOTE - the integration functions I mention above need to have the same public interface and live in a single module so that they can be easily extended.

NOTE2 - unused settings like BUGZILLA_* and JIRA_URL need to be removed.

@tkdchen

This comment has been minimized.

Show comment
Hide comment
@tkdchen

tkdchen Apr 30, 2017

Member

I'd like to mention two points at this moment,

  • code in both UI and internal view and models should handle issue trackers from database. Ideally, in the end of this change improvement, all BUGZILLA_* and JIRA_* will not exist in settings.
    • for example, if only enable JIRA, only JIRA is listed in the UI, and the backend code in either view method or model should handle the selected issue tracker in UI, in this case it is JIRA. So, no hardcoded to get an issue tracker by whatever pk or name from database just like what Nitrate does now.
  • Celery can be enabled in production environment if someone wants to use it. However, by default, Nitrate changes bug information in a thread, IIRC which is also the way in development environment.
Member

tkdchen commented Apr 30, 2017

I'd like to mention two points at this moment,

  • code in both UI and internal view and models should handle issue trackers from database. Ideally, in the end of this change improvement, all BUGZILLA_* and JIRA_* will not exist in settings.
    • for example, if only enable JIRA, only JIRA is listed in the UI, and the backend code in either view method or model should handle the selected issue tracker in UI, in this case it is JIRA. So, no hardcoded to get an issue tracker by whatever pk or name from database just like what Nitrate does now.
  • Celery can be enabled in production environment if someone wants to use it. However, by default, Nitrate changes bug information in a thread, IIRC which is also the way in development environment.
@tkdchen

This comment has been minimized.

Show comment
Hide comment
@tkdchen

tkdchen Apr 30, 2017

Member

This would be a big change to Nitrate. I would suggest you could use a separate branch in your cloned repository for opening PR and even code review from that branch directly.

Member

tkdchen commented Apr 30, 2017

This would be a big change to Nitrate. I would suggest you could use a separate branch in your cloned repository for opening PR and even code review from that branch directly.

@tkdchen tkdchen added this to the 4.2 milestone Apr 30, 2017

@tkdchen

This comment has been minimized.

Show comment
Hide comment
@tkdchen

tkdchen Apr 30, 2017

Member

Additional thoughts

  • instead of using "bug tracking system", issuetracker is a better name for it, where "issue" is used generally in different systems.
  • all things related to issue tracker should go to a separate module directory, it is probably named issuetracker.
  • the database schema and code should be easier for extension to support other issue trackers as much as possible.
  • change issues in an external issue tracker would require authentication, like current Bugzilla support in Nitrate, so this should be cared about very carefully. Currently, only need to change bug in a Bugzilla, and not change a JIRA issue.
Member

tkdchen commented Apr 30, 2017

Additional thoughts

  • instead of using "bug tracking system", issuetracker is a better name for it, where "issue" is used generally in different systems.
  • all things related to issue tracker should go to a separate module directory, it is probably named issuetracker.
  • the database schema and code should be easier for extension to support other issue trackers as much as possible.
  • change issues in an external issue tracker would require authentication, like current Bugzilla support in Nitrate, so this should be cared about very carefully. Currently, only need to change bug in a Bugzilla, and not change a JIRA issue.
@tkdchen

This comment has been minimized.

Show comment
Hide comment
@tkdchen

tkdchen Apr 30, 2017

Member

If you like, you can fix relative issue #151 with this issue together.

Member

tkdchen commented Apr 30, 2017

If you like, you can fix relative issue #151 with this issue together.

@tkdchen

This comment has been minimized.

Show comment
Hide comment
@tkdchen

tkdchen Apr 30, 2017

Member

nitrate-issuetracker

Basically, issuetracker has this simple relationship. Issue should be a contenttype that can have relationship to either TestCase or TestCaseRun, but no need to store case_id or test_case_run_id in Issue that is what Nitrate does now and it's really bad.

Member

tkdchen commented Apr 30, 2017

nitrate-issuetracker

Basically, issuetracker has this simple relationship. Issue should be a contenttype that can have relationship to either TestCase or TestCaseRun, but no need to store case_id or test_case_run_id in Issue that is what Nitrate does now and it's really bad.

@atodorov

This comment has been minimized.

Show comment
Hide comment
@atodorov

atodorov Apr 30, 2017

Contributor

@tkdchen thanks for the comments, I will look at them. Do you mind merging #79 first so that I can base this new work on the existing changes ?

Contributor

atodorov commented Apr 30, 2017

@tkdchen thanks for the comments, I will look at them. Do you mind merging #79 first so that I can base this new work on the existing changes ?

atodorov added a commit to MrSenko/Nitrate that referenced this issue May 24, 2017

Introduce the IssueTrackerType integration classes
I modify the DB schema to allow more granular configuration of
each Issue tracker defined there. The new fields are:
- report_url
- tracker_type
- api_url
- api_username
- api_password

Then I also add a generic IssueTrackerType class which defines
the public interface all IT integrations must follow. The admin
form makes it easy to select what sort of integration we want.

I also add default implementations for Bugzilla and JIRA by copying
previously existing code.

NOTE: previous code doesn't implement
'Check to add test case to BZ' functionality for JIRA!

NOTE: I have deleted the integrations/bugzilla/ directory because
many of the files there were empty and becase not all the code was
used. In particular BZ_Externer_Track_Thread was never used, only
the bugzilla_external_track() task was used.

This means that by default Nitrate is using a Celery task
instead of spawning a separate thread which contradicts comment:
Nitrate#185 (comment)

I have taken care to isolate the Bugzilla RPC code and make sure to
run as Celery task only if Celery is available. Otherwise run as a
thread! This makes for a bit ugly code but does the job.
@tkdchen

This comment has been minimized.

Show comment
Hide comment
@tkdchen

tkdchen May 28, 2017

Member

Is d225198 ready for review or just WIP?

Member

tkdchen commented May 28, 2017

Is d225198 ready for review or just WIP?

@tkdchen tkdchen assigned tkdchen and unassigned atodorov May 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment