Skip to content

Fix order dependencies in some specs

What does this MR do?

Remove some unnecessary hard-coded project paths in specs. They were causing order-dependent spec failures.

Are there points in the code the reviewer needs to double check?

It's feasible that all our test sequences are vulnerable to this kind of collision, but I've only checked project paths for now.

Why was this MR needed?

Our automatically-generated project paths are of the form project<N>. If a spec manually specifies a project path of that form, it may conflict with the automatically-generated paths in some circumstances.

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Closes #43296 (closed)

Merge request reports