I've tried to follow the documentation from http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#performing-automated-runtime-testing in order to setup a Intel NUC with core-image-testmaster, and then use bitbake -c testimage core-image-sato in order to run the tests.

I didn't understand how to use the installer parts of core-image-testmaster-initrd, so I deployed it manually by setting up the partition scheme according to the docs and manually creating /etc/masterimage.

But when I then run 'bitbake -c testimage core-image-sato' it fails with the following error:

core-image-sato-1.0-r0 do_testimage: core-image-sato - deploying image on target
ERROR: core-image-sato-1.0-r0 do_testimage: Failed deploying test image: Command '['ssh', '-l', 'root', '-o', 'UserKnownHostsFile=/dev/null', '-o', 'StrictHostKeyChecking=no', '-o', 'LogLevel=ERROR', '172.31.173.107', 'export PATH=/usr/sbin:/sbin:/usr/bin:/bin; cp ~/test-kernel /boot']' returned non-zero exit status 1:
cp: cannot stat '/home/root/test-kernel': No such file or directory

Looking at the core-image-testmaster instance I see that deploy step has managed to create some symlinks, but never actually copied the actual artifacts those symlinks points to:

lrwxrwxrwx 1 root root 80 May 18 05:57 test-kernel -> bzImage--4.8.17+git0+bb6984f46b_9bcb4ea3fa-r0-intel-corei7-64-20170517060056.bin
lrwxrwxrwx 1 root root 60 May 18 05:57 test-rootfs.tar.gz -> core-image-sato-intel-corei7-64-20170517133030.rootfs.tar.gz

Inspecting the code I found this definition of copy_to in lib/oeqa/utils/sshcontrol.py:

    def copy_to(self, localpath, remotepath):
        if os.path.islink(localpath):
            link = os.readlink(localpath)
            dst_dir, dst_base = os.path.split(remotepath)
            return self.run("cd %s; ln -s %s %s" % (dst_dir, link, dst_base))
        else:
            command = self.scp + [localpath, '%s@%s:%s' % (self.user, self.ip, remotepath)]
            return self._internal_run(command, ignore_status=False)

Since the arguments passed to this is functions are symlinks (in my case tmp/deploy/images/intel-corei7-64/core-image-sato-intel-corei7-64.tar.gz which is a symlink to tmp/deploy/images/intel-corei7-64/core-image-sato-intel-corei7-64-20170517133030.rootfs.tar.gz) it just created a dead symlink instead of scp:ing the file. 

Why is this if/else needed? Does it matter that the input is a symlink? The scp command can still be executed with the symlink as input.

I would be happy to work on a patch if I can get in contact with someone who can review it so I don't miss the "big picture".