I waste a lot of time when running Xcode bots and I just want to see if I have it configured correctly. My test suite takes 5 minutes to run, so having to wait that amount of time each time I tweak a setting until I can see the results is not ideal. Is there any way I can see the logs as the bot is running?
An alternative approach would be some way to run just a single test, if that's possible. Obviously I could remove/comment all other tests, but I'm looking for a faster way.
This is a bit tricky to do, but possible.
Xcode Server stores bot log information in /Library/XcodeServer/IntegrationAssets/<bot_name_here>/.
Within this directory, you will find number folders for each integration (folders named 1/, 2/, 3/, etc), and within each of those folders you will find the following files (not necessarily limited to these but this is what I see):
buildService.log
sourceControl.log
trigger-before-0.log
...etc
However, this directory is only accessible if you are the root user. If you really want to take a look at logs while bots are running, you can assume root on your server machine with the following command (server password required):
sudo su -
then you can navigate to the above directory and observe the log files as they are being written.
Related
I approached our IT staff to restrict a top-level folder on a directory to prevent users from adding or modifying anything in the root level, but to allow read/write/modify access to all sub-folders. There are several hundred gigabytes and probably over a million files and folders. I was told:
"The way the current permission structure is set on this volumes make what you ask very hard to do. The volume has the one permission structure that is inherited all the way down – Everyone FULL rights to everything – therefore making any changed at the top would have to propagate to every single file in the entire volume and would take days to complete. "
Does this make sense? I get it would take days to perform, but why does that matter? Is he saying the system would be bogged down for days? What are the alternatives to lock down the root? Any help would be appreciated.
If you're using a windows file server, that's not necessarily the case. There is the option of only changing the permissions of a single directory vs. propagating everything down. However, if you want to propagate everything down (generally an IT decision), it will bog down and your file share will probably not be accessible with any acceptable level of performance
https://social.technet.microsoft.com/Forums/ie/en-US/76e50b7d-40b2-4198-a2e2-23cf26f08761/permissions-not-propagating-properly?forum=winserverDS
I am using MS Access 2010 on Windows 7, in a moderately locked down corporate environment. I have developed a report that calls several subreports, and one subform, which in turn has several embedded graphs. The various subentities pull data from multiple queries that build on other queries, some of which are parameterized. The two parameters (Year and Month values) are taken from a single form that includes buttons to preview and print the report. All data tables are local to the .accdb file; there is no server back end.
I developed the file locally, then copied it to a shared network folder and tested. Everything works as expected for me -- the report takes a few seconds to run, as the data work is admittedly a bit clunky, but it still displays in a timely fashion. I am in California, the shared folder is somewhere in the Midwest or South, and my coworker is in Texas. I asked coworker to open the file, enter values in the form, and run the report. He got a warning saying the file was read-only, but the form still ran, but the report locked up. Specifically, the report starts to run, the progress bar moves to about 1/3rd or 2/5ths across, then just stops. There is no error message given.
I had coworker force-close Access, deleted the lock file, gave coworker full permissions on the file, and had him try again. Same results, minus the read-only error. Entering values in the form and running the report directly, rather than using the buttons, gives the same result. I had him go through the other database objects, and all of the tables, base queries, subreports, and subform open "instantly", with the expected data and record counts. For some reason, though, bringing it all together just crashes Access every time.
Coworker was doing a screen share for the initial tests, so I know he was following directions correctly. We tried it without, in case the bandwidth was an issue, with no improvement.
I've tried searching variations on "ms access report locks/freezes/hangs" via Google and SO, and got a bunch of stuff about record-locking, which I think is not the issue here. If anyone can suggest better search terms, I'm game to try them.
The data used is confidential, so I'm reluctant to post code, but can work on sanitized versions if that's necessary for a solution.
Since the file is locked in Read-Only, any calculations that are done which in any way write data to a table are not going to work. I suggest you double check the security permissions the user has to the network folder. That includes both the NTFS security and the shared folder security.
He needs write permission to the entire network folder (not just the database file) because Access will try to create the laccdb file and write to it within the network folder. If he does not have write permissions on that folder access will not be able to edit the laccd file.
I have a problem when I detect accessing folder on Mac in python programming.
I use Pyinotify, watchdog, fsevent to monitor files change, it's very good, but now I need to detect when I access into a folder. I want to know when someone opens up the Finder at a folder so I can check for changes to that folder only
Ex: I'm currently in here folder/
and when I go to folder/folder_children , my python program can know that.
Anyone know how to detect it?
You may want to use Watchman. We provide a (not currently very well documented) python client and it works on Linux and Mac (and Solaris and FreeBSD)
https://facebook.github.io/watchman/
For your use case, the following aspects of Watchman are pertinent:
Watchman builds a time ordered index of file changes
Each logical change has an associated "clock" value
You can query Watchman for the list of files that changed since a clock value
For convenience you can ask Watchman to track a clock value with a symbolic name; we call these named cursors
For example:
When I run watchman since /path/to/dir n:myclient the first time, I get a complete list of files in /path/to/dir. When I run it the second and subsequent times it returns the list of files that changed since the last time it was run.
You can construct more sophisticated queries than since to match certain files; pertinent docs:
https://facebook.github.io/watchman/docs/cmd/since.html
https://facebook.github.io/watchman/docs/cmd/query.html
Architecturally:
On the remote side, run the Watchman service and ask it to monitor the root of the filesystem tree that you're syncing. Watchman always watches recursively.
On the client side, you can periodically (or via whatever heuristic you use to figure out when is appropriate) call up to the server
When polled by the client, the server issues a since query to Watchman using a cursor name
Your server only needs to re-examine the files in that list
You can use a separate cursor name per discrete client if you have multiple clients to synchronize.
I am working on a WinForm application, that allows working to work with "projects" (think about the application as Visual Studio, and projects as VS Solutions).
My question is - where should the application keep its logging files?
Some requirements include:
the application might not be running as an administrator (so saving in the %ProgramFiles% installation folder is not a good option)
The logs should be accessible to end-users (either for review, or for sending to the support team). (This means that hard to find folders, like %AppData%\Company\Application\Version\ProjectName... are not a good solution either)
The application might generate logs even when there are no open projects (so saving the logs in the project's folder is good only when there's a project, but not a final solution).
I was thinking of creating a "working folder" when the application is installed - something along the lines of C:\Application\, and then save the logs in a subfolder, like %WorkingFolder%\Logs\ProjectName
Thanks for the input.
Somewhere in the user's directory is actually the correct place to store them if they are specific to the current running user.
Some programs create folders at the top level of the User's directory, next to Documents and Desktop, others do it in Documents.
Creating it in C:\ might cause issues if the user doesn't have write access to the root directory. You can pretty much guarantee the user will have write access to the Home directory.
The other option is to look for an environment variable, and if its set use the value as the location, if not default to the User's home directory.
If the logs are user only you should store them at %AppData%\Company\Application Name.
If the logs are shared (any user can see any log) you should store them at:
%ProgramData%\Company\Application Name (for Vista+)
or
%AllUsersProfile%\Application Data\Company\Application Name (for XP-)
As for user access, you can add a shortcut to the start menu to the appropriate location or have a link within the program.
Another option in Vista+ is the Public folder (%Public%) which has links throughout Explorer for easy access to.
Where should I write program data instead of Program Files is a good blog entry by Chris Jackson from Microsoft. While it isn't an "official stance" it holds some excellent information.
You can always ask the user to configure this. Set a default path, maybe the application directory. During installation or while setting up the application you may prompt the user to input the path they want to use for logs. That's fair, right. If they're advanced enough to use logs they're good enough to configure a path too.
What do you plan to do with the logs. Are they technical, of for financial/security audits?
The EventLog is a nice place for technical logs, because you can access it remotely (within the Domain) and it is cleaned up automatically.
The %AppData% is also a good place for technical logs, specially if you are unable to connect to the eventlog. You can find the log files, and you can direct the end-user to them, but they are not "in the face" of the end-user. You can include a "send log to the maker" button to receive them.
For logs that needs be accessed by end-users, the My Documents (or a subfolder) looks good.
You can just to add button / menu item to easy open folder with logs.
Best place fo logs are %AppData%\AppName or %temp%\AppName.
Never use %MyDocs% or %Program Files%.
I'd suggest adding that question to the installer so that the user that installs the software can decide where best to put the logs. Though C:\[AppName\ sounds like a reasonable default for your requirements.
Edit: Just thought off, it would probably be worth warning the user if the select a bad location (in Program Files or in the root of the system drive etc) and if they choose to create a new directory, automatically give that directory correct permissions during the installation.
I think %APPDATA%\YourCompanyName\YourAppName is the preferred location. To overcome your stated objection of this location being hard to find, you could pretty easily and quickly implement a simple support screen in your app to allow the end user the ability to access and email these logs without too much trouble, so that the user will not have to remember or manually navigate to the long path name to get to the logs.
I don't really like the idea of the user being able to set this location via the installer because of possible naming and permission issues.
If the app needs to maintain the log only for the users current logged in timespan, then you could keep it in c:/temp.
Most of my winapps, i leave it there, so automatically it gets deleted once the user logs off..
Ofcourse, this primarily depends on your requirement.
Where would be the best "standard" place to put an application's debug log file in a Windows user environment?
In this particular case, it is an application that is run once and could go wrong. It will be run by system administrator types who may need to inspect the log after the application is run. Everytime the application is run, a new log file is created.
Options that have been floated so far include:
The program directory
The user's desktop
The user's local Application Data directory.
I have my favourite, but I wondered what the SO consensus was.
Note: this is similar to this question, but we're dealing with an application that's only likely to be run once by one user.
The Application Data directory would seem to be the perfect place, but it's an area that is nearly invisible. You need to give your users an easy way to get to it.
Have your installation script create a Log folder in the Application Data area for your program, and include a link to the folder in your Start menu.
In the organization I work for we use the (%TEMP% or %TMP%)\CompanyOrProductName\Logs directory
Using %APPDATA% may be problematic with roaming profiles if the logs are numerous or huge : it slows their login process ...
1.The program directory <- not good. Ideally you will only have RX permissions on this folder.
2.The user's desktop <- technically can be done, but I don't like this idea. Polluting desktop... I, as a user, don't like it.
3.The user's local Application Data directory. <- better
My preference is a subdirectory under the program directory (with a clear name like "DebugLog" or something similar). Permissions on that subdirectory should allow creating and writing files ("Change" will be fine)
The "standard" place for the log would be the AppData directory. However, really its up to you where you want to store them. As they are administrator (power users) then there should be no problems storing the logs in the same directory as the application being run. Even in the MyDocuments of the user would be a good shout.
If you EXPECT something to go wrong put it in the user's local Application Data directory.
If you don't and just want to log anyways I might think about really using the temp directory. The reasoning for this is simple. If the application is only run once you will leave trash in the Application Data directory otherwise that nobody will ever need again. In the temp you have at least the CHANCE that it's going to be cleaned up later.
BTW: IMHO the best would be not not create the log AS A FILE at all (log to memory) until something goes wrong. Then you can still offer a dialog where the user selects where to save the log.
Windows Temp Folder
Assuming you want to keep log files around a significant amount of time and they are intended to be used, read I would put the log file in a sub-folder of the user's local application data folder, accessible from windows explorer by typing %localappdata%.
If they are temporary log files, only to be used in the event of system diagnostics then you should put them in the temporary folder, accessible from windows explorer %temp%.