Unable to unmount after work in VM is finished

[art-divin]

Hello,

thank you for such an amazing tool! It is really useful for CI setup.

One thing I am fighting with, is the fact that after the successful build phase, the cleanup fails every time. I wonder, why this code does not use -f option for umount command?

func unmountWorkingDirectoryHook(logger *echelon.Logger) remoteagent.WaitForAgentHook {
	return func(ctx context.Context, sshClient *ssh.Client) error {
		syncLogger := logger.Scoped("unmounting the working directory")

		command := fmt.Sprintf("umount %q", macOSAutomountDirectoryPath)

		syncLogger.Infof("running command: %s", command)

		sshSess, err := sshClient.NewSession()
		if err != nil {
			syncLogger.Finish(false)
			return err
		}

Because essentially, VM state is ephemeral, right? So why to fail if all of the changes will not be stored anyway after the VM is killed?

Error I am getting is not verbose enough, but lsof shows the following:

lsof | grep "$HOME/working-dir"
received log chunk of 639 bytes
cirrus     722 admin  cwd       DIR               53,2        832                   2 /Users/admin/working-dir/working-dir
bash       723 admin  cwd       DIR               53,2        832                   8 /Users/admin/working-dir/working-dir/<redacted>
DTService 3832 admin  cwd       DIR               53,2        832                   2 /Users/admin/working-dir/working-dir
lsof      3905 admin  cwd       DIR               53,2        832                   8 /Users/admin/working-dir/working-dir/<redacted>
grep      3906 admin  cwd       DIR               53,2        832                   8 /Users/admin/working-dir/working-dir/<redacted>

If I would open an MR adding API to forcefully unmount the $HOME/working-dir, would such PR be accepted?

Thank you for any guidance and help 🙏🏻

[fkorotkov]

I wonder if we should just not fail the hook and only log the error. But I also don't mind a forceful unmount. @edigaryev WDYT?

[edigaryev]

I'm not sure if we should simply use unmount -f here, because that could potentially not write some of the changes to project directory when using --dirty.

@art-divin

1. Have you considered not using --dirty?
2. Would you mind providing some minimally reproducible example of this behavior in the form or .cirrus.yml? I wonder if this behavior could be fixed in the task specification instead.