Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instruments Trace Complete #160

Closed
bootstraponline opened this issue Feb 12, 2013 · 10 comments
Closed

Instruments Trace Complete #160

bootstraponline opened this issue Feb 12, 2013 · 10 comments
Assignees
Labels

Comments

@bootstraponline
Copy link
Member

Is there some way to stop the instrumentscli.trace files from being created? After testing for a bit, there are quite a few .trace files.

@jlipps
Copy link
Member

jlipps commented Feb 12, 2013

If appium closes instruments successfully, it will delete the .trace directories by default. If instruments crashes, they won't be deleted. Alternatives are:

  • have appium delete extraneous directories on startup too
  • create a "grunt cleanup" command that makes it easy to clean things up

@bootstraponline
Copy link
Member Author

It'd be nice if they were deleted on startup and when @driver.quit is called.

@jlipps
Copy link
Member

jlipps commented Feb 12, 2013

They are deleted in every case that appium itself doesn't crash due to an error or we can't get the name of the tracedir for some reason. So when you call @driver.quit, appium shuts down instruments and retrieves the name of the tracedir which instruments created (which we can always get except maybe in some rare instruments crash cases). It then (by default) removes this tracedir. So if you run a clean test, you should see no tracedirs in your appium directory afterward. Is this not your experience?

If what you're asking about is "how do we get rid of these even when something goes wrong and we can't know that a tracedir was created", then we'll have to resort to some kind of rm -rf *.trace that just gets called at some point in the flow---and even this won't be guaranteed to run if we crash beforehand.

I'm more inclined to (a) try to figure out why these crashes are happening and exit gracefully instead, perhaps removing tracedirs that we detect in another way and (b) adding a "cleanup" script which gets rid of these along with the instruments socket and any other tempfiles that appium might have created. This could be run with grunt clean or something similar.

@bootstraponline
Copy link
Member Author

So if you run a clean test, you should see no tracedirs in your appium directory afterward. Is this not your experience?

Appium frequently crashes and I'm left with tons of instrumentscli0.trace folders. I'd rather not have to manually run a cleanup script. Couldn't @driver.quit remove all .trace folders instead of just the most recent one? I don't see why it'd be helpful to retain them.

@jlipps
Copy link
Member

jlipps commented Feb 12, 2013

It could, but for some people those tracedirs contain valuable diagnostic information (or so I have been told). I'm fine blowing them all away if a flag is set, though. Another issue with this particular suggestion is that if Appium itself crashes, we can't do anything at all on @driver.quit, since the server is no longer even listening. We could also do it on server startup, which doesn't guarantee no tracedirs ever, but at least keeps things more clean. Anyway, I'll go ahead and implement something that will delete these dirs more often.

@bootstraponline
Copy link
Member Author

I guess the real solution is fixing the crash issues then it won't be a problem. A flag would be nice.

execute_script 'mobile: setRemoveAllTraceOnQuit', 1

@jlipps
Copy link
Member

jlipps commented Feb 12, 2013

The flag I'm thinking of already exists, it's --remove and on by default when starting the appium server itself (I think this is something for the server to know about, not the client---the client could be on a completely different machine, after all).

@ghost ghost assigned jlipps Feb 12, 2013
@bootstraponline
Copy link
Member Author

Sounds good.

@jlipps
Copy link
Member

jlipps commented Feb 12, 2013

let me know if this doesn't delete things often enough for you.

@jlipps jlipps closed this as completed Feb 12, 2013
sebv pushed a commit to sebv/appium that referenced this issue May 9, 2014
dpgraham pushed a commit to dpgraham/appium that referenced this issue Oct 1, 2018
Add showXcodeLog cap and functionality
dpgraham pushed a commit to dpgraham/appium that referenced this issue Nov 7, 2018
Add showXcodeLog cap and functionality
@lock
Copy link

lock bot commented May 4, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators May 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants