Current working directory is incorrectly copied into dSYM zip file

[connor-alphero]

Description

I have a project (running Xcode 10.2.x, macOS 10.14 (Mojave) stack) that uses the xcode-archive and deploy to bitrise steps to export the app's desymbolication files as a zip file. The zip file ends up being ~300MB and contains a collection of dSYMs + a copy of the project source code. I would expect the dsym zip to contain just the dsym files.

Fault

I have identified the problematic code that spans two files

https://github.com/bitrise-io/go-xcode/blob/51984334e0fb83bf66588acf87f09c5ac624874b/xcarchive/ios.go#L329-L350

FindDSYMs() defaults to an empty string if it cannot find a file ending with .app.dsym
The fact it returns an empty string if it cannot location a .app.dsym causes an issue in the xcode archive step.

steps-xcode-archive/main.go

Lines 903 to 940 in 95e00f3

	appDSYM, frameworkDSYMs, err := archive.FindDSYMs()
	if err != nil {
	if err.Error() == "no dsym found" {
	log.Warnf("no app nor framework dsyms found")
	} else {
	fail("Failed to export dsyms, error: %s", err)
	}
	}
	if err == nil {
	dsymDir, err := pathutil.NormalizedOSTempDirPath("__dsyms__")
	if err != nil {
	fail("Failed to create tmp dir, error: %s", err)
	}
	if err := command.CopyDir(appDSYM, dsymDir, false); err != nil {
	fail("Failed to copy (%s) -> (%s), error: %s", appDSYM, dsymDir, err)
	}
	if cfg.ExportAllDsyms == "yes" {
	for _, dsym := range frameworkDSYMs {
	if err := command.CopyDir(dsym, dsymDir, false); err != nil {
	fail("Failed to copy (%s) -> (%s), error: %s", dsym, dsymDir, err)
	}
	}
	}
	if err := utils.ExportOutputDir(dsymDir, dsymDir, bitriseDSYMDirPthEnvKey); err != nil {
	fail("Failed to export %s, error: %s", bitriseDSYMDirPthEnvKey, err)
	}
	log.Donef("The dSYM dir path is now available in the Environment Variable: %s (value: %s)", bitriseDSYMDirPthEnvKey, dsymDir)
	if err := utils.ExportOutputDirAsZip(dsymDir, dsymZipPath, bitriseDSYMPthEnvKey); err != nil {
	fail("Failed to export %s, error: %s", bitriseDSYMPthEnvKey, err)
	}
	log.Donef("The dSYM zip path is now available in the Environment Variable: %s (value: %s)", bitriseDSYMPthEnvKey, dsymZipPath)
	}

On line 903, FindDSYMs() is called to locate the dsym files for the app and frameworks. The app's dsym path is held in appDSYM.
On line 917, the appDSYM is copied into dsymDir. If appDSYM is an empty string, like it can be if there isn't a .app.dsym file, it copies the entire current working directory.

Ideally, there would be a check on the appDSYM before it performs the copy to make sure it does not copy the current working directory.

[connor-alphero]

I have discovered why my project is not generating a .app.dsym. The Debug Information Format was set to just 'DWARF' rather than 'DWARF with dSYM File'. After changing this setting the an .app.dsym file was detected and to dsym zip contained just dsyms.

It feels as though a warning or fail should occur in the event an .app.dsym file was not located before it copies the whole project.

[fehersanyi-bitrise]

Hy @connor-alphero
I'm glad to hear you found the solution!🎉
also thanks for the heads up, we will check out the possibilities of emitting a warning in this case. 🙃

[lszucs]

Hi @connor-alphero,

Thanks for the report! Can you please tell me which version of the step you use and whether the issue persist with the latest version?

[github-actions]

Hello there, I'm a bot. On behalf of the community I thank you for opening this issue.

To help our human contributors focus on the most relevant reports, I check up on old issues to see if they're still relevant.
This issue has had no activity for 90 days, so I marked it as stale.

The community would appreciate if you could check if the issue still persists. If it isn't, please close it.
If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me".

If no comment left within 21 days, this issue will be closed.

[github-actions]

I'll close this issue as it doesn't seem to be relevant anymore.
We believe an old issue probably has a bunch of context that's no longer relevant, therefore, if the problem still persists, please open a new issue.