This commit switches the order of calling _run_step() and _migrate_overlay* so that the overlay migration always happens *before* the default step behavior. This is the desired behavior, but the previous code had a corner-case when a part has content coming from both 'build' and 'overlay', like this: ```yaml parts: p1: override-build: | mkdir ${CRAFT_PART_INSTALL}/my-dir override-overlay: | mkdir my-dir touch my-dir/my-file ``` ... in this situation, the previous code would *first* stage the `my-dir`directory coming from `override-build` and *then* migrate `my-dir` and `my-dir/my-file` from the overlay to stage. Because of the way the migration happens, the `my-dir` dir coming from build would "shadow" the `my-dir` dir coming from stage, which meant the migrate state would *not* record `my-dir` as coming from the overlay. This is a bug in and of itself but it was usually harmless. A failure happens if another, separate part gets primed *before* `p1`. In that case, we would try to do the migration of overlay contents from stage to prime, which in this case meant migrating the `my-dir/my-file` file but **not** the `my-dir` dir because it did not get recorded. Then, the migration of `my-dir/my-file` would *maybe* work: - if `my-file` is a regular file, the code would follow a path that recreates the directory structure to hardlink the file (to save storage); - if `my-file` is a special file like a symlink the code would try to copy it to `${prime}/my-dir/`, which doesn't exist. Then a failure happens with a cryptic message that suggests that `${stage}/my-dir/my-file` doesn't exist, but this is just bad formatting of the error message. In my view the main cause of this bug is the fact that overlay files are not correctly recorded in the state file - I added a test to check this scenario and I think it's sufficient to validate this particular bugfix. ---