Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59030

Include only the latest lines of log files (configurable)

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • support-core-plugin
    • None

      Implement a FileLatestContent that gets the latest lines of the log files to avoid adding too many bytes to the zip by default. The limit can be set by a System property, useful if the logs are not enough to diagnose the problem, then the admin can change that property and generate the bundle again.

      We have two types of logs:

      • The ones coming from LogRecordContent. They all are already limited in such a way or another. By RingBufferLogHandler or by SupportLogHandler.
      • The ones coming from FileContent that reads log files. Currently, it's not limited. Although the FileContent has a constructor to define the max size, it would return the first part of the file, therefore the older log records. So we need to implement a sort of +FileLatestConten+t that gets the latest lines of the file. As this class is intended to be used with filtering, it's because the content is textual. So we can limit the size by lines, instead of bytes. Good to have this limitation configurable by a system property. We can do that using the RandomAccessFile class directly. Although we can use some existing wrappers like org.apache.commons.io.input.ReversedLinesFileReader.

      Acceptance criteria

      • The support-core plugin is changed and the logs included in the bundle are limited by its number of lines
      • There is a system property to modify that
      • A test is created to assert that the log doesn't have more than the lines specified. We can add a pseudo-log file to the JUT
      • A test is created to assert that the system property is taking effect

       

          [JENKINS-59030] Include only the latest lines of log files (configurable)

          Jesse Glick added a comment -

          Certainly any component that reads files from disk needs to include some sort of cap on how much content it will load.

          The generic infrastructure in the plugin would also ideally have some hard limits timeouts applied to all components:

          • Attempts to write more than, say, 1Mb of content from a single component will be rejected, perhaps just by truncating the content.
          • Components which are taking more than, say, 5s to render will be interrupted, and if the interrupt is not honored within 1s, Thread.stop applied (on Java 8 only; gone from 11, alas).

          Jesse Glick added a comment - Certainly any component that reads files from disk needs to include some sort of cap on how much content it will load. The generic infrastructure in the plugin would also ideally have some hard limits timeouts applied to all components: Attempts to write more than, say, 1Mb of content from a single component will be rejected, perhaps just by truncating the content. Components which are taking more than, say, 5s to render will be interrupted, and if the interrupt is not honored within 1s, Thread.stop applied (on Java 8 only; gone from 11, alas).

            Unassigned Unassigned
            mramonleon Ramon Leon
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: