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

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

 

---
Originally reported by mramonleon, imported from: Include only the latest lines of log files (configurable)

• status: Open
  
• priority: Major
  
• component(s): support-core-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 3
  
• imported: 20251212-090250
  

Raw content of original issue

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



 

Start by locating FileContent, LogRecordContent, and the support-core bundle code; review how log files are currently included. Check RandomAccessFile or the mentioned ReversedLinesFileReader as possible reading approaches. Done means logs are limited by line count, a system property changes that limit, and tests using a pseudo-log verify both behaviors.

Written by the indexing model from the issue text.