Why do we need to create an empty file here?

The short answer is that syz-ci's image test checks that this file exists, and the image test fails if not. The contents of the file are not used by the test, so an empty file here is enough to get syz-ci working.

Sorry that I didn't look for a better solution here yet. I think there might be an unintended interaction between two methods involved in the image test, leading to an unnecessary(?) check for this file.

The sequence is:

• syz-ci's Manager.build() indirectly calls Manager.createTestConfig() with imageDir = tmpDir (which corresponds to the outputDir in this build script at the time of the initial build).
• Manager.createTestConfig() partially populates a mgrconfig.Config. (It does not populate the Image field.) Then, Manager.createTestConfig() calls instance.SetConfigImage() with the partially-populated struct and the imageDir string.
• instance.SetConfigImage() sets the mgrconfig.Config's Image field to "${tmpDir}/image", so that the Image field is no longer empty. The slightly-more-populated config struct is returned back to createTestConfig().
• Later, createTestConfig() calls mgrconfig.Complete() on the partially-populated config struct. That method does the following check:

if cfg.Image != "" {
		if !osutil.IsExist(cfg.Image) {
			return fmt.Errorf("bad config param image: can't find %v", cfg.Image)
		}
		cfg.Image = osutil.Abs(cfg.Image)
}

Since the config's Image field is not empty if it has come from createTestConfig(), we hit the existence check in that case.

My guess is that the right solution is to create the image path in instance.SetConfigImage() and check whether that file exists, and proceed without setting the config's Image field if not.

It will probably take significant work to make it work correctly, but it seems like we might eventually want to have the starnix binary available for doing e.g. coverage reports... does creating an empty file (or copying over the starnix_runner binary as-is) cause issues currently?

Yes, it would be better to create an empty file in "obj/", or copy real binary there.
syz-ci also knows about this layout and will upload the object file and provide in bug reports:

Thanks, this might be possible to do now -- I'm not 100% sure which file is the right one to use as the kernel obj here, but there are only a few options. I'll try to get more info and update soon.

I think it is out/x64/exe.unstripped/starnix_kernel