Remove Robozilla dependency on skip_if_bug_open decorator

[rochacbruno]

For now to be applied only on master branch.

PR 1: #7346

• Explicitly mark wontfixed test cases with @pytest.mark.deselect without calling Bugzilla and remove all the calls for bugzilla in the test collection phase. we want to keep the tests in codebase for historical reasons.
• Identify tests that can run (passing tests) and remove the blocker.
• Replace @skip_if_bug_open with explicit @pytest.mark.skip(reason="BZ:123456")
• Remove direct dependency on Robozilla for decorators and remove bugzilla calls.

PR 2: Done! https://gitlab.{internal-url}/satelliteqe/nagger_bz

• Crate a nagger script that parses that BZ numbers and notifies component owners if a test is skipped by an already closed BZ and ask for update.

PR3: IN progress: https://gitlab.{internal_url}/satelliteqe/nagger_bz/blob/master/DOCS.md

• Update the documentation on how to use the decorators and strategies for BZ based workarounds.

[rochacbruno]

@pgagne @flatfender @jyejare @sghai @Mirzal

This is the plan and I am in progress on the item 2, so I'll send the first PR soon.

If you have any comment.

[mirekdlugosz]

• Crate a nagger script that parses that BZ numbers and notifies component owners if a test is skipped by an already closed BZ and ask for update.

I understand it would take BZ number from new decorator (@pytest.mark.skip(reason="BZ:123456")), is that correct?

The script will send emails based on

• last person that made changes on that line?
• component owner mapping?
• CODEOWNERS file
• BZ qa-contact?
• A single email to the list

I'm undecided between "component owner mapping" and "BZ qa-contact".
On one hand, component owners should own their component, which sometimes mean they need to take care of bugzillas created by other QE. On the other hand, BZ qa-contact is the best person to make any decisions regarding specific bz and any automation around it. Most of the time component owner and BZ qa-contact will be the same person, and if they differ, then probably there is a good reason for that.

But then, there might be rare cases when BZ qa-contact is unresponsive (left the team or something), while component owners are always up-to-date.

Perhaps we can do both?

Either way, I vote for one single email to list, possibly CC-ing specific people (these that have cases with resolved bzs). This way it will be more visible and if anyone has free time, they can take offload someone with a lot of bzs.

[rochacbruno]

I'm undecided between "component owner mapping" and "BZ qa-contact".

@Mirzal I think we can do both, my next question is: "Where do I find the component owners mapping?" do we have a file that maps stuff like:

{
    "pulp": ["kersommoura", "rochacbruno", "bherring"],
    "Repositories": ["user1", "user2"],
    ...
}

We need to build a mapping like that for the script, internally on gitlab.

[mirekdlugosz]

@rochacbruno there won't be mapping file on gitlab, as this approach doesn't fit some of management workflows.

Instead, we have Python library responsible for gathering component owners data from bugzilla and Mojo, and thin command line wrapper that creates YAML file for further processing. At the moment they live only in my private forks and are not integrated with CI. Since your nagger script will be one of the consumers here, I welcome all suggestions on design of such integration.

Library: $SAT_GITLAB/satelliteqe/satreportinglibs/tree/master/satreportinglibs/componentowners
CLI wrapper: $SAT_GITLAB/mzalewsk/satellite6-reporting/blob/rework-extract-libs/component-owners/component-owners-manager

Wrapper will produce YAML file with content like that:

API - Content:
    full-name: API - Content
    primary: jyejare
    secondary: mzalewsk
    slug: api-content
Activation Keys:
    full-name: Activation Keys
    primary: pgagne
    secondary: swadeley
    slug: activationkeys

However, I am not yet sure how we will transfer it between jobs.

You can also import library to get dict with the same data, like that:

from satreportinglibs.componentowners import ComponentOwners
mapping = ComponentOwners.as_dict()

For this to work, you need environment variables with Mojo username and password, or run your script on the same machine that first created YAML - thanks to request response caching, you will get the same data without knowing Mojo credentials.

[jyejare]

@rochacbruno, The plan in phases is a good idea. you++ :)

I have some questions:

1. Are you planning to merge all phases once or sequential?
2. We are OK with nagger script but can we un-skip the test if BZ is verified(just like we do it now) else the skipped test has to wait until the component owner removes the skip explicitly.

We wanted to implement this functionality just to save the calling time from test to Bugzilla. The solution should not impact the existing way of skipping/running test based on Bug Status.

We can manipulate pytest.mark.deselect(instead of skip) based on the function(we need to implement) that returns True / False wrt bug status.

[rochacbruno]

Are you planning to merge all phases once or sequential?

Sequential, #7346 is the 1/3 I am addressing the requested changes right now and hopefully we can run a CI against it and merge soon

We are OK with nagger script but can we un-skip the test if BZ is verified(just like we do it now) else the skipped test has to wait until the component owner removes the skip explicitly.

To un-skip the test the component owner has to remove the .skip or the .deselect mark, only after this is done and PR merged the test will run again.

We wanted to implement this functionality just to save the calling time from test to Bugzilla. The solution should not impact the existing way of skipping/running test based on Bug Status.

Not sure I understood this statement, we are keeping the deselection of wontfix marked tests, that before was done on pre-selection and now is explicit using .deselect and the skip will be the same but now it is explicit and no more conditional by BZ.

We can manipulate pytest.mark.deselect(instead of skip) based on the function(we need to implement) that returns True / False wrt bug status.

This PR already manipulates the .deselect mark to remove from test collection, you are suggesting we capture the skip mark instead? and then do it conditional based on what data?

NOTE: deselect is to remove tests from collection, they don't even count on the report, the .skip is to explicitly skip and count on reports.