Use unique repos for artifacts repair tests

[vsedmik]

Problem Statement

For the artifacts repair test we need to identify the particular artifacts to repair. For yum and file repos we do so through published files/urls, but for docker and AC repos we do so based on the artifact creation time, which must be newer than the repo sync time. And since all repos from all organizations on a Satellite share the artifacts based on their checksum (their actual content), we need to ensure that the artifacts were synced for the very first time in that test, not earlier by another test.

My previous assumption was that the module-scoped module_target_sat would provide a brand new Satellite for the module with no repos previously synced, but the recent failures prove the assumption was wrong and the repos were synced somewhere else before:

tests/foreman/cli/test_artifacts.py:131: in test_positive_artifact_repair
    assert len(artifacts) > 0, 'No NEW artifacts found'
E   AssertionError: No NEW artifacts found

Solution

There are three approaches we could take that comes to my mind:

1. Use @pytest.mark.destructive to ensure spin up of a new SAT. But that would mean 24 SATs spinned up, one for every parametrization - definitely not a nice way.
2. Add a new module_local_sat fixture to spin up a new module-scoped SAT, but that would block me from using existing fixtures which act against the original module_target_sat.
3. Just use unique repos for this test case so that they are not pre-synced in another test.

In the end I decided to go with 3.

PRT test Cases example

trigger: test-robottelo
pytest: tests/foreman/cli/test_artifacts.py -k repair

[vsedmik]

trigger: test-robottelo
pytest: tests/foreman/cli/test_artifacts.py -k repair

[Satellite-QE]

PRT Result

Build Number: 7696
Build Status: SUCCESS
PRT Comment: pytest tests/foreman/cli/test_artifacts.py -k repair --external-logging
Test Result : ================ 24 passed, 197 warnings in 1069.19s (0:17:49) =================

[sambible]

I think this is an acceptable solution to this problem, and the likelyhood that someone else will randomly choose to use this specific repo seems very small. ACK