Add .gitignore file for CISupport, especially for various buildbot related services we host from that directory.
Created attachment 433884 [details] [fast-cq] Patch
Is it possible to NOT have these files in a checkout? This seems like papering over the issue.
These log files are generated on the server hosting the applications (not on individual user's machines). They pollute the 'git status' command on those servers. Those log files are part of the intended functionality (e.g.: twistd.log for buildbot)
I understand, it's just unclear to me why they have to be here even on the server. It seems like it can only add trouble because of potentially conflicting access restrictions, and/or be bad for security to mix source code and runtime data.
(In reply to Alexey Proskuryakov from comment #4) > I understand, it's just unclear to me why they have to be here even on the > server. It seems like it can only add trouble because of potentially > conflicting access restrictions, and/or be bad for security to mix source > code and runtime data. If this is the concern, I think we need to change how we have buildbot services running. Given that the current instructions for running our buildbot instances (both locally and on the production servers) has them running out of Tools/CISupport/<host>, this is the right change. Even if we change where we're running our production servers, this is still applicable for local instances, and our other services (even those cloud hosted) tend to run "in place"
<rdar://problem/81172638>
Committed r280362 (240009@main): <https://commits.webkit.org/240009@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 433884 [details].
> If this is the concern, I think we need to change how we have buildbot > services running. Given that the current instructions for running our > buildbot instances (both locally and on the production servers) has them > running out of Tools/CISupport/<host>, this is the right change. Even if we > change where we're running our production servers, this is still applicable > for local instances, and our other services (even those cloud hosted) tend > to run "in place" I don't think that you understood my comment. Running from a checkout is completely orthogonal to having write access to the checkout and messing it up! Neither local nor cloud nor any other deployments have to write to write to the directory where the code is in. This is like saying that Apache logs must be in /usr/sbin, because that's where the httpd binary is.
(In reply to Alexey Proskuryakov from comment #8) > > If this is the concern, I think we need to change how we have buildbot > > services running. Given that the current instructions for running our > > buildbot instances (both locally and on the production servers) has them > > running out of Tools/CISupport/<host>, this is the right change. Even if we > > change where we're running our production servers, this is still applicable > > for local instances, and our other services (even those cloud hosted) tend > > to run "in place" > > I don't think that you understood my comment. > > Running from a checkout is completely orthogonal to having write access to > the checkout and messing it up! Neither local nor cloud nor any other > deployments have to write to write to the directory where the code is in. > > This is like saying that Apache logs must be in /usr/sbin, because that's > where the httpd binary is. Ah, I see the point. Seems like we would want a "log" directory inside the checkout, in that case. Sort of like what we do for autoinstall and WebKitBuild?
I'd say somewhere in /var/log, not inside the checkout? Perhaps I'm missing something too.