Closed n00levoy closed 1 month ago
Hmm, I'll check it. DevCleaner basically checks on boot, whether it was started from a command line or from GUI - it's a one binary, apparently when running in a headless mode, or a part of a script, it doesn't work as suppose to 🤔
@vashpan Hi i have the same problem. There is a solution?
In launchd jobs (~/Library/LaunchAgents), when calling /Applications/DevCleaner.app/Contents/Resources/dev-cleaner.sh clean all
, it outputs
2021-12-06 10:23:34.216 DevCleaner[99096:2389249] ⚠️ XcodeFiles: No version for device support: .DS_Store, skipping
2021-12-06 10:23:34.216 DevCleaner[99096:2389249] ⚠️ XcodeFiles: Cannot check contents of '/Users/achim/Library/Developer/Xcode/tvOS DeviceSupport', skipping
2021-12-06 10:23:34.217 DevCleaner[99096:2389249] ⚠️ XcodeFiles: Cannot check contents of '/Users/achim/Library/Developer/Xcode/macOS DeviceSupport', skipping
and opens DevCleaner.
Back to this issue...
This is what DevCleaner is checking whether or not it was run from Finder, or command line/headless.
(there's more checks but those are for DEBUG only)
Does anyone know if there's a better way of doing that?
I closed that one by mistake, as there indeed might be some issues with accessing command line tool via remote connections
Hi, I'm trying to set DC to run as part of a launchd job and running into the same issue.
Perhaps instead of checking for isTTY
, we should just check if any valid command line argument is used (i.e. info
, clean
, etc.) and if so, treat as a CLI?
Alternatively, perhaps we just provide an additional flag like -headless
, -noinput
or similar?
@vashpan can you offer a suggestion for what might be the best option here? I'm happy to contribute a PR if you can offer some guidance.
Thanks!
I'll be looking into this in future update.
@edwellbrook If you would like to look yourself first, it would be ideally to have a better way to recognize whether the app is launched by the user from macOS UI, or via command line (regardless if this will be an interactive session, or headless one).
If that won't be possible or reliable, then indeed some extra param could help 🤔
You can start looking at this function: https://github.com/vashpan/xcode-dev-cleaner/blob/27fe6ce415b8793d9fd0df5bea85313a0d384244/DevCleaner/Base/main.swift#L34
I think the most straight forward way to detect GUI/command line is by making use of dev-cleaner.sh
. The CLI docs suggest that we launch DC using this script for scripting and we know that GUI mode will never launch using this script.
We could alter the script to include an env var, or additional flag which signals headless/GUI. If the flag is present, we know that the script was involved and should run as CLI. If the flag is missing the script was not involved and user wants UI.
Thoughts?
Opened a PR that implements the idea in my last comment: https://github.com/vashpan/xcode-dev-cleaner/pull/44
Please give it a read, and share any thoughts. I'm happy to make adjustments or changes.
I figure it'd make sense to get /something/ that works in a PR that we can then try out, read and edit as needed.
Thanks!
I am Also, having this problem and would +1 for a solution. Identical problem with the GUI opening when run in a github action, but not when I run the CLI in the terminal on the mac. Very challenging, and prevents automated tools from running the script
I have up on using the app for automated tools, and switched to a simple shell script.
Subscribing to this one, as I'm also experiencing the same issue 😅
Actually, I did just notice the 2.6.0 release, which includes the note:
Command line tool can now run from headless environments, like SSH or CI, YOU NEED TO REINSTALL IT FOR THIS TO WORK!
Accordingly, I just finished reinstalling/updating my DevCleaner to 2.6.0, and re-run my CI/CD config (in TeamCity) to clean my build machine. One thing I noticed on that first run (with the updated DevCleaner), is that the command seemed to be hanging. I remoted into my build machine, and noticed that the DevCleaner desktop app was open, and prompting for access to the Xcode dev folders.
However, after I allowed that folder access once (on the remote desktop), I've since been able to run the CI/CD clean command successfully, without issue. That might be an issue for some folks, so I wanted to note it here.
Anyway, I suppose that means that this bug is mostly addressed!
As of the issue with folder permissions: unfortunately this might not be addressable on AppStore build 😢 I might try though, to at least print some information about it on CLI tool 🤔
One thing I noticed on that first run (with the updated DevCleaner), is that the command seemed to be hanging. I remoted into my build machine, and noticed that the DevCleaner desktop app was open, and prompting for access to the Xcode dev folders.
I'll close this issue for now though, adding this improvement for my TODO list for this year update for DevCleaner
I've tried to setup a Jenkins job that cleans some old builds on a local build server. Command line tool works correctly in terminal, but if I use it as a part of the Jenkins job, it starts in the GUI-mode instead of the command line one.
For example, the Jenkins pipeline step looks like this:
sh "dev-cleaner info"
but the job execution output is the following lines:
and on the build machine there is just an opened DevCleaner app window.
Maybe there is explicit argument that defines the CLI usage? If not, adding it might be very helpful.