The patch conflicts plugin would only operate on file tests.

After applying a patch file (the patch under test) to a test drupal environment, the plugin would then cycle through all other RTBC patches for that same project, and perform a 'git apply [patch]' on each.

If the patch applies successfully, it is removed and the next patch applied.

If the patch is not applied successfully, a 'patch conflict' assertion is created, and the process moves on to the next patch.

Thus, for each test, the "test assertion summary" message could be identify how many other current patches the item conflicts with; and the "test assertion details" could be used to identify the specific conflicting patches.

Comments

catch’s picture

catch
he/him
Primary language English
commented

Subscribing.

I was thinking that a queue that only tries to apply patches to HEAD and marks them CNW if they don't apply (same as now without actually trying to run the full test suite) would help to cut down the 1,000 issue long CNR queue for 8.x without requiring too much extra processing overall.

This is a bit more advanced but presumably the initial apply step could also trigger an explicit fail.

jthorson’s picture

jthorson commented
Issue summary: View changes

fixed typo