--up is broken: open secrets.yml: no such file or directory

[SpectreVert]

Summary

Using --up should find a secrets.yml file up the directory hierarchy. In v0.10.0 and v0.10.1 the flag is broken when running summon from any subdirectory.

Steps to Reproduce

1. Inside a directory (some-repo) setup a secrets.yml and a subdirectory.

some-repo/
├── secrets.yml
└── subdirectory

1 directory, 1 file

2. The contents of secret.yml could be as follows:

secrets.yml

BIG_SECRET: !var SomeStore/MyBigSecret

3. Store placeholder secret in your store: (go)pass insert SomeStore/MyBigSecret

4. Navigate to some-repo/subdirectory

5. Run summon --up -- sh -c 'echo $BIG_SECRET'

Expected Results

In the previous summon v0.9.6 the example above works and displays the secret.

Actual Results

Starting with v0.10.0 the example above fails with :

open secrets.yml: no such file or directory

Reproducible

• Always
• Sometimes
• Non-Reproducible

Version/Tag number

All binaries downloaded from https://github.com/cyberark/summon/releases summon-linux-amd64.tar.gz
Correct: v0.9.6-8de0e79
Offending: v0.10.0-129fb57, v0.10.1-29ebeaa

Environment setup

Linux 6.8.9-49-generic
Ubuntu 22.04.5 LTS 64-bit

Additional Information

Add any other context about the problem here.

[SpectreVert]

FYI @marco-m

[marco-m]

I had a look at the code. I believe that the bug has been introduced in ef71de5. The --up feature has been introduced in #144, in function findInParentTree, which was called by function runAction.

It turns out that function runAction has been renamed to RunSubprocess and moved to file pkg/summon/summon.go. In the process, this snippet has been deleted by mistake:

	if ac.RecurseUp {
		currentDir, err := os.Getwd()
		ac.Filepath, err = findInParentTree(ac.Filepath, currentDir)
		if err != nil {
			return err
		}
	}

Ironically, this has not been detected by the tests, because the tests exercise function findInParentTree, which still exists in the source code, although it is now not called by anything except the tests...

[marco-m]

@SpectreVert could you please check #255 ?