Add Firefox Android Team Tag (FXDROID)

[cpeterso]

The Firefox Android team would like to set up JBI sync from Bugzilla to our FXDROID Jira project. The Android team will typically work in the Fenix, Focus, and GeckoView Bugzilla products, but it would be nice if we could also sync Bugzilla bugs in other products (such as Core).

Something like this untested code:

whiteboard_tag: fxdroid
  contact: cpeterson@mozilla.com
  description: Firefox Android Team Tag
  enabled: true
  parameters:
    jira_project_key: FXDROID
   steps:
      new:
      - create_issue
      - maybe_delete_duplicate
      - add_link_to_bugzilla
      - add_link_to_jira
      - maybe_assign_jira_user
      - maybe_update_issue_resolution
      - maybe_update_issue_status
      existing:
      - update_issue
      - maybe_assign_jira_user
      - maybe_update_issue_resolution
      - maybe_update_issue_status
    status_map:
      UNCONFIRMED: Backlog
      NEW: Backlog
      ASSIGNED: In Progress
      RESOLVED: Closed
      REOPENED: In Progress
      VERIFIED: Closed
    resolution_map:
      FIXED: Fixed
      INVALID: Won't Do
      WONTFIX: Won't Do
      INACTIVE: Won't Do
      DUPLICATE: Duplicate
      WORKSFORME: Cannot Reproduce
      INCOMPLETE: Won't Do
      MOVED: Duplicate

1. I think I may be trying to use Jira status and resolution incorrectly. IIUC, the FXDROID Jira project has separate Done and Cancelled status values, but maybe Cancelled is redundant and we should use the Done status with a resolution like "Won't Do" and "Duplicate"?

2. What are the default steps for new, existing, and comment? Do nothing?

3. Is it possible to set the Jira issue type based on the Bugzilla bug type (defect, enhancement, task)?

If it’s not possible, that’s OK; it's not a big deal. If it is possible, I’d like to map Bugzilla bug types to Jira issue types like this:

  defect: Bug
  enhancement: Task
  task: Task

[bsieber-mozilla]

1. I've requested the FXDROID project be duplicated, with the current configuration style, to the testing environment; that way the workflows/transitions can be tested and confirmed.
2. The defaults are listed below; they can also be found in the code here
   • Steps below refer to the python functions in this module
   • "new" will use the following steps, by default:
     • create_issue
     • maybe_delete_duplicate
     • add_link_to_bugzilla
     • add_link_to_jira
   • "existing" will use the following steps, by default:
     • update_issue
     • add_jira_comments_for_changes
   • "comment" will use the following step, by default:
     • create_comment
3. Currently it is not possible to set the Jira issue type based on the Bugzilla bug type; however, the map you provided aligns with the defaulted behavior; the map takes place in this method.

[cpeterso]

@bsieber-mozilla Thanks. I updated the yaml in the first comment to remove the incorrect usage of resolution_map. I think the yaml now correctly describes the config I'd like for FXDROID syncing.

[bsieber-mozilla]

@cpeterso that yaml is looking nearly perfect!

There's one thing that we may have to change, which is the whiteboard-tag

"-" are a special character used often in whiteboard-tags, however original usage intended the whiteboard-tag be of the form: [TAG-metadata]; where "-metadata" was used by PM's and other's but not the jbi system.

So JBI would look at any precursor to a "-" between bracketed as the routing/running component mapping to an action.

---

tldr;

currently "-" is reserved--explained more above;
do you have a preference between fxdroid_jira,fxdroid, or perhaps a different tag?

[cpeterso]

do you have a preference between fxdroid_jira,fxdroid, or perhaps a different tag?

I see. If we use fxdroid, does that meanfxdroid will match the substring within FOOfxdroidBAR? Or the bare word fxdroid without square brackets in foo fxdroid bar?

So the metadata doesn't need to be known by JBI? And tag-metadata will be added as a Jira label tag-metadata?

I was emulating the Add-ons team's use of [addons-jira] in the Bugzilla whiteboard, but I see now that their JBI tag defined in config.prod.yaml is actually just addons and jira is the metadata.

jira-bugzilla-integration/config/config.prod.yaml

Line 3 in 04240cf

- whiteboard_tag: addons

[cpeterso]

do you have a preference between fxdroid_jira,fxdroid, or perhaps a different tag?

@bsieber-mozilla: Let's use fxdroid. I updated the yaml in my first comment to use whiteboard_tag: fxdroid.

[cpeterso]

I also added a resolution_map to the first comment that maps Bugzilla resolutions to similar Jira resolutions.

[cpeterso]

@bsieber-mozilla I see PR #307 has been merged. How long until the new JBI config is live in production?

[bsieber-mozilla]

Hi @cpeterso, apologies for the delay, I've been on medical leave/ooo since Oct 30. I hope to be back at my desk later this week.

I've tried to push this forward since, but reaching out to @grahamalama or @leplatrem might expedite this.

In terms of your question; as long as you've tested the tag and it is as desired (in the bugzilla-dev and mozit-test Jira env) this will just require a git release.

[cpeterso]

In terms of your question; as long as you've tested the tag and it is as desired (in the bugzilla-dev and mozit-test Jira env) this will just require a git release.

@bsieber-mozilla: I don't know how to test bugzilla-dev and mozit-test Jira env. Do I need to do that before you can release this JBI change?

[bsieber-mozilla]

Hi @cpeterso, I attempted to test this workflow in non-prod and it failed due to limitations with the current permission scopes of the API key; we're working with Jira Support to ensure the correct permissions are applied to all environments.

Since our prior internal Jira Support agent is no longer with the company, new Jira Support have stepped in to assist. The permissions seem to be missing in the production instance as well (given the state of the heartbeat and powered_by_jbi pages.

[bsieber-mozilla]

Hi @cpeterso, Jira Support has updated the permissions in both the nonprod and prod environments.

I began to test some of the FXDROID steps in nonprod--but ran into an issue with the setup; it seems that resolutions were not set for the project (in non-prod) so I am unable to test the resolution map successfully. (As to why the "Done" status has yet to be sent in the issue test: the act of "Resolving" a bug sends a status and resolution, the bot attempts to set the resolution field before the status field and results in a failure, halting the workflow. )

You may notice some duplicates on the nonprod jira board that occurred when permissions were missing while tests were attempted at an earlier time.

One approach is: we remove the resolution_map, confirm this is working as expected, and then users can begin to use the [fxdroid] tag--without resolutions.

Another approach might be: work with Jira Support to add the expected resolution field to the Jira Project.

I believe the first approach can be done and applied to both environments to move this forward and allow for some testing and usage, while the second approach can be a future addition.

---

We make the call to update resolutions here:

jira-bugzilla-integration/jbi/services/jira.py

Line 398 in f7194e0

def update_issue_resolution(context: ActionContext, jira_resolution: str):

through the atlassian api client:
https://github.com/atlassian-api/atlassian-python-api/blob/0dfb78a99980f2d6a7e02ac5166197d99cfea359/atlassian/jira.py#L1079

which uses the jira api:
https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issues/#api-rest-api-2-issue-issueidorkey-put

[bsieber-mozilla]

(Also, Focus, Fenix, GeckoView and Core bugzilla product's webhooks are setup in both nonprod and prod to broadcast events to JBI.)

[bsieber-mozilla]

I opened this PR (#319 ) removing the resolution_map for the time being; we can merge this in if you're comfortable with the first approach.

[cpeterso]

I opened this PR (#319 ) removing the resolution_map for the time being; we can merge this in if you're comfortable with the first approach.

That sounds OK to me. The status_map is more important than the resolution_map, so let's not block on the resolution_map.