Also have one recheck.ignore per state

[roesslerj]

Since recheck.ignore is additive, we can also have one per state. This solves some immediate problems, e.g. where a XPath should only be ignored within a certain state.

[martin-v]

Where is the correct place to persist these ignore configurations?

[roesslerj]

I'd say we look in hierarchy. One inside the folder of the Golden Master, next to the retest.xml. Then we could even have a second one above, as for the whole suite.

[beatngu13]

To summarize:

${PROJECT_ROOT}
| - .retest/
|   | - recheck.ignore (level 1)
| - src/test/resources/retest/recheck/
    | - ${TEST_CLASS_NAME}
        | - recheck.ignore (level 2)
        | - ${TEST_CASE_NAME}.${STEP_NAME}.recheck
            | - recheck.ignore (level 3)
            | - retest.xml

As ignore/filter is additive, I assume we won't have conflicts and a more specific level will only add more things to ignore/filter?

[beatngu13]

From retest/recheck#193:

This pull request pertains to the first half of #182 :

The RetestImpl now loads a second, optional, suite-specific filter in addition to the already loaded global one.

The new suite filter is loaded from the suite's golden master directory. It is loaded with the same mechanism as the global filter (e.g., also allows for a rules file). One difference is that a missing suite filter is not logged as an error (but as a debug message).

The remaining part of issue 182 is adding the step-wise filters (called level 3 in issue 182)

So I think we still have to figure out how CLI and GUI deal with "local" recheck.ignore files. How are they presented to the user? Where to write to when ignoring specific changes?

[roesslerj]

I think as long as the changed are not "mixed" (i.e. that "local" ignores are persisted in the global ignore file) it is ok to have it like that. This is for experienced users and special use cases—we can later see how we put this into GUI and CLI. When ignoring changes, they should still end up in the "global" ignore file.