Split logs into multiple files

[czechboy0]

Right now logs keep getting appended to one file, which grows to GBs. We need to automatically split into a new file when we go over certain size.

[joelekstrom]

I'm considering stealing this issue, but I'm thinking if we should maybe use CocoaLumberJack for logging then? It has this functionality built in + logging to different places, nice colors etc. I could migrate everything to that. What do you think?

[czechboy0]

Sounds good - currently we're using a tiny class I wrote in BuildaUtils for this. I'm not positive we need to bring in a large dependency like Lumberjack yet. So if you could take a look at the state of it and evaluate what additional feature we'd get, that would definitely be super helpful.

Yes, the splitting of log files is nice, but we can write that ourselves easily. So again, I'm happy to bring in CL as long as there are enough benefits.

[joelekstrom]

I have looked a bit at it. The health of the project is very good, with many contributors and is being used in a a lot of other projects. However, the Swift 2.0 support is currently in beta, but since it's a pretty small project I image there isn't much that will go wrong.

The pros of CocoaLumberjack for Buildasaur (in my opinion):

• Splits log files
• Deletes old files (why keep gigabytes of data)?
• Log levels - let the user decide how verbose Builda is in console/file etc (which allows us to add a lot of more info logging that is easily turned off)

Also there's colored console output, which is mostly just because I personally like when it's easy to distinguish warns/errors from info output 😄 not really required for Buildasaur.

The cons:

• Well, like you said it's a another dependency
• Arguably, all of the points above are relatively easily added to your current class

In the end, It's up to you to choose. I can't argue that CL is needed. It's a fun project for sure but definitely not revolutionary for Buildasaur.

[czechboy0]

Okay, go for it and replace the guts of the current Log class in
BuildaUtils - so that we don't actually have to change the calls, just call
lumberjack under the hood.

Thanks for taking the time!
On Thu, Oct 15, 2015 at 7:46 AM Joel Ekström notifications@github.com
wrote:

I have looked a bit at it. The health of the project is very good, with
many contributors and is being used in a a lot of other projects. However,
the Swift 2.0 support is currently in beta, but since it's a pretty small
project I image there isn't much that will go wrong.
The pros of CocoaLumberjack for Buildasaur (in my opinion):

• Splits log files
• Deletes old files (why keep gigabytes of data)?
• Log levels - let the user decide how verbose Builda is in
  console/file etc (which allows us to add a lot of more info logging that is
  easily turned off)

Also there's colored console output, which is mostly just because I
personally like when it's easy to distinguish warns/errors from info output [image:
😄] not really required for Buildasaur.
The cons:

• Well, like you said it's a another dependency
• Arguably, all of the points above are relatively easily added to
  your current class

In the end, It's up to you to choose. I can't argue that CL is needed.
It's a fun project for sure but definitely not revolutionary for Buildasaur.

—
Reply to this email directly or view it on GitHub
#142 (comment)
.

[joelekstrom]

I have now implemented this at https://github.com/accatyyc/Buildasaur/tree/lumberjack.

In my opinion there's not much value in proxying through the current log system, since it was already 99% similar to CocoaLumberjack. The result is that all that remains is this:

public class Log {
    public class func verbose(message: String) {
        DDLogVerbose(message)
    }

    public class func info(message: String) {
        DDLogInfo(message)
    }

    public class func error(error: ErrorType) {
        self.error("\(error)")
    }

    public class func error(message: String) {
        DDLogError(message)
    }

    public class func untouched(message: String) {
        DDLogInfo(message)
    }
}

It should probably contain a function here for warn as well since it's supported by CL, but it feels like this class is not really needed anymore. What do you think?

[czechboy0]

Yeah I've used CL before, so I modeled the API very similarly on purpose. But the reason why I really like proxying through the current class is that we don't need to import CocoaLumberjack all over XcodeServerSDK and Buildasaur. Especially if we eventually change the underlying logging implementation, constantly requiring clients of BuildaUtils to change the API is unnecessary. So mostly

1. no need for an extra import
2. hiding away the implementation detail of using CL, they'll only be able to tell once they run pod install, because it will become a dependency.

[czechboy0]

Also, this is the class where you should plug in CocoaLumberjack. It needs to live in BuildaUtils, because it's shared between Buildasaur and XcodeServerSDK.

The class you changed just sets up the Logging class from BuildaUtils, but technically that shouldn't need to change at all (because all the details of how we log should live in BuildaUtils).

Let me know if you need any help with this 👍

[joelekstrom]

Yeah, it's the class I changed :) I also just changed the classes names during setup in that other place. I can add back the previous subclasses if you want but they didn't need any methods so it felt unnecessary.

[joelekstrom]

Oh wait, never mind that. Didn't realise there were two of the same. Will take a look at it!

[czechboy0]

Yeah there are two classes with the same name, sorry.

[czechboy0]

Hey @accatyyc, have you ever finished this one? :)

[joelekstrom]

Actually, I have totally forgotten about it 😄

It shouldn't be much work to finish it if you've decided that the Lumberjack-dependency is OK. Any other thoughts than the previous discussion?

[czechboy0]

Well, I'd prefer if we could just re-implement the bit that splits the log files when they get large. I would prefer to NOT pull in the whole CL project, because it will be a dependency of BuildaUtils, which is also a dep for XcodeServerSDK. Maybe we could just look at how CL does it and use a simplified version.

[joelekstrom]

Ok! I can take a look at a simple file-split implementation!

[czechboy0]

👍 Thanks. I don't want people to end up with multi-GB log files and then be mad 😊

[joelekstrom]

Implemented in buildasaurs/BuildaUtils#11

[czechboy0]

Once I merge the PR in BuildaUtils, I'll release a new version right away so that you can finish up the integration in Buildasaur. 👍

[czechboy0]

@accatyyc ok, I released https://github.com/czechboy0/BuildaUtils/releases/tag/v0.2.5 , so feel free to update it here in Buildasaur and integrate with the defaults we talked about.