[JIRA] (JENKINS-54128) Deprecated calls to Run.getLogFile

50 views
Skip to first unread message

jglick@cloudbees.com (JIRA)

unread,
Nov 6, 2018, 12:41:03 PM11/6/18
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Jenkins / Bug JENKINS-54128
Deprecated calls to Run.getLogFile
Change By: Jesse Glick
Summary: Timestamper causes lots of WARNING messages in the log ( Deprecated calls to Run. getLogFile call)
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

jglick@cloudbees.com (JIRA)

unread,
Nov 6, 2018, 12:41:03 PM11/6/18
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
Change By: Jesse Glick
Component/s: groovy-postbuild-plugin
Component/s: timestamper-plugin
Component/s: warnings-plugin
Component/s: workflow-job-plugin

jglick@cloudbees.com (JIRA)

unread,
Nov 6, 2018, 12:41:04 PM11/6/18
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Stefan Wolf
Change By: Jesse Glick
Assignee: Steven G Brown Stefan Wolf

jglick@cloudbees.com (JIRA)

unread,
Nov 6, 2018, 12:42:01 PM11/6/18
to jenkinsc...@googlegroups.com
Jesse Glick commented on Bug JENKINS-54128
 
Re: Deprecated calls to Run.getLogFile

As are calls from GroovyPostbuildRecorder.

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 6, 2018, 2:45:02 PM11/6/18
to jenkinsc...@googlegroups.com

Jesse Glick I don't quite understand the comment where you said:

The call from WarningsPublisher.parseConsoleLog is unrelated.

As are calls from GroovyPostbuildRecorder.

I believe I'm using the GroovyPostbuildRecorder when I use the manage object provided by the groovy post build plugin to call logContains(). Should I be using something else, or just accept the extra message in the Jenkins log and hope for a fix from the groovy post build plugin?

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 6, 2018, 2:45:04 PM11/6/18
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-54128
[~jglick] I don't quite understand the comment where you said:

bq. The call from WarningsPublisher.parseConsoleLog is unrelated.
bq.
bq. As are calls from GroovyPostbuildRecorder.

I believe I'm using the GroovyPostbuildRecorder when I use the manage object provided by the groovy post build plugin to call [logContains()|https://github.com/MarkEWaite/jenkins-pipeline-utils/blob/fa3266f738f735e40581abfd9b6a226b3dac0ab6/src/com/markwaite/Assert.groovy#L13].  Should I be using something else, or just accept the extra message in the Jenkins log and hope for a fix from the groovy post build plugin?

jglick@cloudbees.com (JIRA)

unread,
Nov 6, 2018, 2:49:02 PM11/6/18
to jenkinsc...@googlegroups.com

just accept the extra message in the Jenkins log and hope for a fix from the groovy post build plugin

This.

medianick@gmail.com (JIRA)

unread,
Nov 7, 2018, 7:08:01 PM11/7/18
to jenkinsc...@googlegroups.com
Nick Jones updated an issue
Change By: Nick Jones
Component/s: linenumbers-plugin

medianick@gmail.com (JIRA)

unread,
Nov 7, 2018, 7:18:02 PM11/7/18
to jenkinsc...@googlegroups.com

I've added the linenumbers-plugin here, as it too has this issue now that workflow-job 2.26 is released. In my case, it seems to generate hundreds to thousands of copies of the original log file, all named with "deprecated" (e.g., deprecated5973622952721928030.log). I haven't figured out what causes the particular quantity of these files (I've seen over 6000 created by a single build), but it seems perhaps related to how the build was executed – triggering a build directly generates 1, but triggering a build from another build (in my case, a Pipeline build that spawns a number of builds to do a regression test) generates hundreds to thousands of copies. These all coincide with log messages in the Jenkins log like:

java.lang.UnsupportedOperationException
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.getLogFile(WorkflowRun.java:1082)
	at org.jenkinsci.plugins.linenumbers.LineNumbersAnnotator.annotate(LineNumbersAnnotator.java:54)
	at hudson.console.ConsoleAnnotator$1Aggregator.annotate(ConsoleAnnotator.java:114)
	at hudson.console.ConsoleAnnotationOutputStream.eol(ConsoleAnnotationOutputStream.java:145)
	at hudson.console.LineTransformationOutputStream.eol(LineTransformationOutputStream.java:60)
	at hudson.console.LineTransformationOutputStream.write(LineTransformationOutputStream.java:56)
	at java.io.FilterOutputStream.write(FilterOutputStream.java:77)

Given the impact to the master node to store this number of files (6000 files = 14GB for a single build, in my case), and unless I know it's something other than this bug that causes it, I'd think it makes sense to raise to Major (if not Blocker), if the affected plugins don't have their own issues tracking this problem.

medianick@gmail.com (JIRA)

unread,
Nov 7, 2018, 8:02:02 PM11/7/18
to jenkinsc...@googlegroups.com

Sure enough, uninstalling the linenumbers-plugin and rerunning my problematic build generated just 1 "deprecated*.log" file, and I have only one "Avoid calling getLogFile" error in the logs, which comes from hudson.plugins.warnings.WarningsPublisher.parseConsoleLog.

jglick@cloudbees.com (JIRA)

unread,
Nov 7, 2018, 9:56:03 PM11/7/18
to jenkinsc...@googlegroups.com

That one could be solved with a simple s/getLogFile/getLogText/ I think.

 I can look at having WorkflowRun avoid creating multiple temp files like this.

svanoort@cloudbees.com (JIRA)

unread,
Nov 8, 2018, 3:14:02 PM11/8/18
to jenkinsc...@googlegroups.com
Sam Van Oort updated an issue
Change By: Sam Van Oort
Labels: jep-210-regression regression

dnusbaum@cloudbees.com (JIRA)

unread,
Nov 9, 2018, 2:42:02 PM11/9/18
to jenkinsc...@googlegroups.com

Pipeline Job Plugin version 2.29 was just released with a fix that prevents a new temporary file from being created each time WorkflowRun#getLogFile is called.

dnusbaum@cloudbees.com (JIRA)

unread,
Nov 9, 2018, 2:43:02 PM11/9/18
to jenkinsc...@googlegroups.com
Devin Nusbaum updated an issue
Change By: Devin Nusbaum
Released As: workflow-job 2.29

dnusbaum@cloudbees.com (JIRA)

unread,
Nov 9, 2018, 2:46:43 PM11/9/18
to jenkinsc...@googlegroups.com
Devin Nusbaum edited a comment on Bug JENKINS-54128
Pipeline Job Plugin version 2.29 was just released with a fix that prevents a new temporary file from being created each time {{WorkflowRun#getLogFile}} is called. The warning in the logs will need to be fixed by the plugins that are calling {{Run#getLogFile}} themselves, likely by switching to using {{Run#getLogText}} instead..

dnusbaum@cloudbees.com (JIRA)

unread,
Nov 9, 2018, 2:46:44 PM11/9/18
to jenkinsc...@googlegroups.com
Devin Nusbaum resolved as Fixed
Change By: Devin Nusbaum
Status: Open Resolved
Resolution: Fixed

jglick@cloudbees.com (JIRA)

unread,
Nov 9, 2018, 3:04:04 PM11/9/18
to jenkinsc...@googlegroups.com
Jesse Glick reopened an issue
 

Best to leave this open at least until distinct issues are filed for such plugins.
Change By: Jesse Glick
Resolution: Fixed
Status: Resolved Reopened
Assignee: Stefan Wolf

ullrich.hafner@gmail.com (JIRA)

unread,
Nov 15, 2018, 6:02:06 PM11/15/18
to jenkinsc...@googlegroups.com

Should Run#getLogText be used for pipelines and freestyle jobs? Or just for pipelines?

Are there some recommendation on how to process the AnnotatedLargeText }} instance? In the warnings plugin I need to scan the log line by line with a parser. One way I see is to use {{writeLogTo and write the output stream to a intermediate file. Or is this not recommended?

ullrich.hafner@gmail.com (JIRA)

unread,
Nov 15, 2018, 6:02:07 PM11/15/18
to jenkinsc...@googlegroups.com
Ulli Hafner edited a comment on Bug JENKINS-54128

ullrich.hafner@gmail.com (JIRA)

unread,
Nov 15, 2018, 6:03:02 PM11/15/18
to jenkinsc...@googlegroups.com
Ulli Hafner edited a comment on Bug JENKINS-54128
Should {{Run#getLogText}} be used for pipelines and freestyle jobs? Or just for pipelines?

Are there some recommendation on how to process the {{AnnotatedLargeText}} instance? In the warnings plugin I need to scan the log line by line with a parser. One way I see is to use {{writeLogTo}} and write the output stream to a an intermediate file. Or is this not recommended?

jglick@cloudbees.com (JIRA)

unread,
Nov 15, 2018, 9:50:02 PM11/15/18
to jenkinsc...@googlegroups.com

You may use Run.getLogText, or really anything besides getLogFile, on any build, Pipeline or freestyle. In your case the simplest fix looks to be to just call Run.getLogReader rather than using ParserRegistry.createReader(File).

ullrich.hafner@gmail.com (JIRA)

unread,
Nov 22, 2018, 3:31:02 PM11/22/18
to jenkinsc...@googlegroups.com

I see, that looks quite easy. Is there a direct way to access the log on the agent? The I could run all warnings parsers on the agent.

jglick@cloudbees.com (JIRA)

unread,
Nov 26, 2018, 3:24:03 PM11/26/18
to jenkinsc...@googlegroups.com

Is there a direct way to access the log on the agent?

No. If you want to run warning parsers on the agent side, what you would rather want is a block-scoped step (perhaps via SimpleBuildWrapper) that uses a ConsoleLogFilter to track warnings as they are emitted, rather than parsing them later. (This would also be far more efficient in conjunction with cloud log storage.) But it is a significant rewrite to do that, and of course requires a different kind of project configuration as well.

ullrich.hafner@gmail.com (JIRA)

unread,
Dec 6, 2018, 10:03:02 AM12/6/18
to jenkinsc...@googlegroups.com
Ulli Hafner updated an issue
 
Deprecated calls to Run.getLogFile

I removed the component 'warnings' since I fixed it in the beta of the warnings-ng plugin now.
Change By: Ulli Hafner
Component/s: warnings-plugin

vincent@massol.net (JIRA)

unread,
May 21, 2019, 4:44:03 AM5/21/19
to jenkinsc...@googlegroups.com

FTR we're having this issue on XWiki. Every day we get 1TB (yes, terabyte not gigabyte!) of jenkins.log files because of the following filling the logs:

May 21, 2019 8:09:53 AM org.jenkinsci.plugins.workflow.job.WorkflowRun getLogFile
WARNING: Avoid calling getLogFile on XWiki/xwiki-platform/master #1822
java.lang.UnsupportedOperationException
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.getLogFile(WorkflowRun.java:1087)
	at org.jvnet.hudson.plugins.groovypostbuild.GroovyPostbuildRecorder$BadgeManager.logContains(GroovyPostbuildRecorder.java:257)

I'll try replace our call to logContains() and reimplement it using Run.getLogText or Run.getLogReader in the meantime.

vincent@massol.net (JIRA)

unread,
May 21, 2019, 5:09:04 AM5/21/19
to jenkinsc...@googlegroups.com

Any idea why the following pipeline:

node() {
    echo "test"
    def reader = currentBuild.rawBuild.getLogReader()
    reader.eachLine() { line ->
        echo "Line: ${line}"
        if (line.matches(".*test.*")) {
            echo "got it!"
        }
    }
}

Only prints the first log line:

Started by user Vincent Massol
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in /var/jenkins_home/workspace/Test
[Pipeline] {
[Pipeline] echo
test
[Pipeline] echo
Line: Started by user Vincent Massol
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS

?

Thanks

vincent@massol.net (JIRA)

unread,
May 21, 2019, 10:02:05 AM5/21/19
to jenkinsc...@googlegroups.com
Vincent Massol edited a comment on Bug JENKINS-54128
Any idea why the following pipeline:

{code}

node() {
    echo "test"
    def reader = currentBuild.rawBuild.getLogReader()
    reader.eachLine() { line ->
        echo "Line: ${line}"
        if (line.matches(".*test.*")) {
            echo "got it!"
        }
    }
}
{code}


Only prints the first log line:

{noformat}

Started by user Vincent Massol
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in /var/jenkins_home/workspace/Test
[Pipeline] {
[Pipeline] echo
test
[Pipeline] echo
Line: Started by user Vincent Massol
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
{noformat}

?

Thanks

EDIT: see https://gitter.im/jenkinsci/jenkins?at=5ce3c760ad024978c6026d6f Seems it could be related to https://issues.jenkins-ci.org/browse/ JENKINS-46988

vincent@massol.net (JIRA)

unread,
May 21, 2019, 10:02:05 AM5/21/19
to jenkinsc...@googlegroups.com

vincent@massol.net (JIRA)

unread,
May 21, 2019, 12:11:02 PM5/21/19
to jenkinsc...@googlegroups.com

ok works with:

    new BufferedReader(currentBuild.rawBuild.getLogReader()).with { br ->
        def line = null
        line = br.readLine()
        while (line != null) {
            ...
            line = br.readLine()
        }
    }

vincent@massol.net (JIRA)

unread,
May 24, 2019, 2:32:03 AM5/24/19
to jenkinsc...@googlegroups.com

Jesse Glick I'd love your help on this. I reimplemented BadgeManager#logContains() since it calls Run#getLogFile() which emits the warnings in the jenkins logs. The only change I did was to use Run#getLogReader() as in:

private def logContains(regexp)
{
    return contains(currentBuild.rawBuild.getLogReader(), regexp)
}

private def contains(reader, regexp)
{
    def matcher = getMatcher(reader, regexp)
    return (matcher != null) && matcher.matches()
}

private def getMatcher(reader, regexp)
{
    def matcher = null
    new BufferedReader(reader).with { br ->
        def pattern = Pattern.compile(regexp)
        def line = null
        line = br.readLine()
        while (line != null
) {
            def m = pattern.matcher(line);
            if (m.matches()) {
                matcher = m
                break
            }
            line = br.readLine()
        }
    }
    return matcher
}

Source here: https://github.com/xwiki/xwiki-jenkins-pipeline/blob/63df1a4a1a4f75e47b97803da614f7fc9db88c39/vars/checkForFalsePositives.groov

However, when we execute it, it's extra slow.... as the log grows in size, it takes substantially more and more time (we run 24 maven builds in a single pipeline job). On the 24th Maven build, it takes 24mn to execute whereas it was taking 28s with BadgeManager#logContains(). I can't figure out why that speed change. Could it be simply because the code logic was moved from Java to Groovy? Or is there something that makes Run#getLogReader() slow?

Thanks a lot for any help on this, I'm struggling to find a workaround (see my other message above, the warnings fills out logs at a rate of over 1TB of logs every day...).

vincent@massol.net (JIRA)

unread,
May 24, 2019, 2:33:04 AM5/24/19
to jenkinsc...@googlegroups.com
Vincent Massol edited a comment on Bug JENKINS-54128
[~jglick] I'd love your help on this. I reimplemented BadgeManager#logContains() in our pipeline library in Groovy, since it BadgeManager#logContains() calls Run#getLogFile() which emits the warnings in the jenkins logs. The only change I did was to use Run#getLogReader() as in:

{code}

private def logContains(regexp)
{
    return contains(currentBuild.rawBuild.getLogReader(), regexp)
}

private def contains(reader, regexp)
{
    def matcher = getMatcher(reader, regexp)
    return (matcher != null) && matcher.matches()
}

private def getMatcher(reader, regexp)
{
    def matcher = null
    new BufferedReader(reader).with { br ->
        def pattern = Pattern.compile(regexp)
        def line = null
        line = br.readLine()
        while (line != null) {
            def m = pattern.matcher(line);
            if (m.matches()) {
                matcher = m
                break
            }
            line = br.readLine()
        }
    }
    return matcher
}
{code}


Source here: https://github.com/xwiki/xwiki-jenkins-pipeline/blob/63df1a4a1a4f75e47b97803da614f7fc9db88c39/vars/checkForFalsePositives.groov

However, when we execute it, it's extra slow.... as the log grows in size, it takes substantially more and more time (we run 24 maven builds in a single pipeline job). On the 24th Maven build, it takes 24mn to execute whereas it was taking 28s with BadgeManager#logContains(). I can't figure out why that speed change. Could it be simply because the code logic was moved from Java to Groovy? Or is there something that makes Run#getLogReader() slow?

Thanks a lot for any help on this, I'm struggling to find a workaround (see my other message above, the warnings fills out logs at a rate of over 1TB of logs every day...).

vincent@massol.net (JIRA)

unread,
May 24, 2019, 2:33:04 AM5/24/19
to jenkinsc...@googlegroups.com
Vincent Massol edited a comment on Bug JENKINS-54128
[~jglick] I'd love your help on this. I reimplemented BadgeManager#logContains() in our pipeline library in Groovy, since BadgeManager#logContains() calls Run#getLogFile() which emits the warnings in the jenkins logs. The only change I did was to use Run#getLogReader() as in:


{code}
private def logContains(regexp)
{
    return contains(currentBuild.rawBuild.getLogReader(), regexp)
}

private def contains(reader, regexp)
{
    def matcher = getMatcher(reader, regexp)
    return (matcher != null) && matcher.matches()
}

private def getMatcher(reader, regexp)
{
    def matcher = null
    new BufferedReader(reader).with { br ->
        def pattern = Pattern.compile(regexp)
        def line = null
        line = br.readLine()
        while (line != null) {
            def m = pattern.matcher(line);
            if (m.matches()) {
                matcher = m
                break
            }
            line = br.readLine()
        }
    }
    return matcher
}
{code}

Source here: https://github.com/xwiki/xwiki-jenkins-pipeline/blob/63df1a4a1a4f75e47b97803da614f7fc9db88c39/vars/checkForFalsePositives.groov

However, when we execute it, it's extra slow.... as the log grows in size, it takes substantially more and more time (we run 24 maven builds in a single pipeline job). On the 24th Maven build, it takes 24mn to execute (so 300mn = 5 hours in total) whereas it was taking 28s with BadgeManager#logContains(). I can't figure out why that speed change. Could it be simply because the code logic was moved from Java to Groovy? Or is there something that makes Run#getLogReader() slow?


Thanks a lot for any help on this, I'm struggling to find a workaround (see my other message above, the warnings fills out logs at a rate of over 1TB of logs every day...).

jglick@cloudbees.com (JIRA)

unread,
Jun 3, 2019, 2:24:02 PM6/3/19
to jenkinsc...@googlegroups.com

All of these methods ought to be marked @NonCPS.

vincent@massol.net (JIRA)

unread,
Jun 3, 2019, 3:31:04 PM6/3/19
to jenkinsc...@googlegroups.com

All of these methods ought to be marked @NonCPS.

Jesse Glick hmm, are you saying that the performance issues I see are actually caused by the fact that I didn't mark them @NonCPS? Indeed, didn't think of this. I'm surprised it would make such a difference but maybe that's the case.

jglick@cloudbees.com (JIRA)

unread,
Jun 4, 2019, 3:40:03 PM6/4/19
to jenkinsc...@googlegroups.com

I'm surprised it would make such a difference

Orders of magnitude. CPS-transformed code is intended for “glue”: a handful of if-statements and the like. Not actual programming.

devld@ikedam.jp (JIRA)

unread,
Jun 24, 2019, 2:18:03 AM6/24/19
to jenkinsc...@googlegroups.com
ikedam updated an issue

The issue in groovy-postbuild is fixed in groovy-postbuild-2.5.
(Removed groovy-postbuild from component/s)
It will be available in the update center in a day.
Please try that.
Change By: ikedam
Component/s: groovy-postbuild-plugin
Released As: workflow-job 2.29 groovy-postbuild-2.5

vincent@massol.net (JIRA)

unread,
Jun 24, 2019, 2:22:02 AM6/24/19
to jenkinsc...@googlegroups.com

Awesome, thanks for both of you Jesse Glick and ikedam!

mark.earl.waite@gmail.com (JIRA)

unread,
Jun 24, 2019, 9:10:02 AM6/24/19
to jenkinsc...@googlegroups.com

Thanks very much ikedam and Jesse Glick. I'm now using the groovy-postbuild plugin 2.5 and am not seeing any log messages for my use of the groovy post build plugin to assert that specific strings are detected in the log file of the current build.

cosbug@gmail.com (JIRA)

unread,
Oct 24, 2019, 3:51:03 PM10/24/19
to jenkinsc...@googlegroups.com

Getting similar exceptions in the log:

 

Oct 24, 2019 8:32:17 PM WARNING org.jenkinsci.plugins.workflow.job.WorkflowRun getLogFileAvoid calling getLogFile on build-packer #8
java.lang.UnsupportedOperationException
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.getLogFile(WorkflowRun.java:1088)
	at org.jenkinsci.plugins.compressbuildlog.BuildLogCompressor$CompressBuildlogRunListener.onFinalized(BuildLogCompressor.java:85)
	at hudson.model.listeners.RunListener.fireFinalized(RunListener.java:255)
	at hudson.model.Run.onEndBuilding(Run.java:2000)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.finish(WorkflowRun.java:612)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.access$800(WorkflowRun.java:133)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun$GraphL.onNewHead(WorkflowRun.java:999)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.notifyListeners(CpsFlowExecution.java:1463)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$3.run(CpsThreadGroup.java:458)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$1.run(CpsVmExecutorService.java:37)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Oct 24, 2019 8:34:35 PM INFO hudson.model.AsyncPeriodicWork$1 run

 

 

Jenkins version: 2.201

I don't have groovy-postbuild plugin installed.

Plugin versions.

 

docker-workflow  1.21
workflow-aggregator 2.6
workflow-api 2.37
workflow-basic-steps 2.18
workflow-cps 2.74
workflow-cps-global-lib 2.15
workflow-durable-task-step 2.34
workflow-job 2.35
workflow-multibranch 2.21
workflow-remote-loader 1.5
workflow-scm-step 2.9
workflow-step-api 2.20
workflow-support 3.3

Any help would much appreciated.

 

 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 24, 2019, 5:23:06 PM10/24/19
to jenkinsc...@googlegroups.com

Constantin Bugneac that seems to be a call reading the log file from org.jenkinsci.plugins.compressbuildlog, the compress build log plugin, probably at line 85. You're welcome to submit a pull request to that repository proposing to correct that plugin. Alternately, you could disable build log compression in your job definitions.

cosbug@gmail.com (JIRA)

unread,
Oct 24, 2019, 6:02:03 PM10/24/19
to jenkinsc...@googlegroups.com

Thank you Mark.

tobias-jenkins@23.gs (JIRA)

unread,
Jan 27, 2020, 10:42:03 AM1/27/20
to jenkinsc...@googlegroups.com

Is there a fix for timestamper-plugin? Since LogFileReader.nextLine() is called for every line when downloading logs from Jenkins, the log is flooded with bogus errors. I took a look at https://github.com/jenkinsci/timestamper-plugin/blob/master/src/main/java/hudson/plugins/timestamper/io/LogFileReader.java#L157 but am at a loss on how to keep the contract of that method while avoiding the call to getLogFile. (Would be nice if Run had a method hasLog()...)

me@basilcrow.com (JIRA)

unread,
Feb 25, 2020, 7:24:05 PM2/25/20
to jenkinsc...@googlegroups.com

Tobias Gruetzmacher, I have a rough draft of a fix for Timestamper. I plan to post a PR soon and release the fix in the forthcoming Timestamper 1.11.1 release. To help me test this new functionality, would you mind posting the stack trace that you are seeing with the call to getLogFile?

me@basilcrow.com (JIRA)

unread,
Feb 25, 2020, 9:18:03 PM2/25/20
to jenkinsc...@googlegroups.com

I posted jenkinsci/timestamper-plugin#52, which eliminates the last call to the last call to Run#getLogFile in Timestamper and replaces it with a call to Run#getLogReader.

me@basilcrow.com (JIRA)

unread,
Mar 3, 2020, 11:05:03 AM3/3/20
to jenkinsc...@googlegroups.com
Basil Crow updated an issue
Change By: Basil Crow
Component/s: timestamper-plugin
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

me@basilcrow.com (JIRA)

unread,
Mar 3, 2020, 11:19:04 AM3/3/20
to jenkinsc...@googlegroups.com
Basil Crow updated an issue
Change By: Basil Crow
Component/s: google-storage-plugin
Component/s: sauce-ondemand-plugin
Component/s: stoplightio-report-plugin
Component/s: token-macro-plugin

me@basilcrow.com (JIRA)

unread,
Mar 3, 2020, 11:19:08 AM3/3/20
to jenkinsc...@googlegroups.com

I removed the timestamper-plugin component from this issue, since a fix has been released in Timestamper 1.11.1.

FYI, the usage-in-plugins job shows that there are still 16 plugins with calls to the deprecated Run#getLogFile method. Most of these plugins haven't been updated in over a year, but I noticed that google-storage, sauce-ondemand, stoplightio-report, and token-macro have all had recent updates, so I added them to this issue's component list.

slide.o.mix@gmail.com (JIRA)

unread,
Mar 4, 2020, 7:42:05 AM3/4/20
to jenkinsc...@googlegroups.com
Alex Earl updated an issue
Change By: Alex Earl
Component/s: token-macro-plugin

slide.o.mix@gmail.com (JIRA)

unread,
Mar 4, 2020, 7:42:06 AM3/4/20
to jenkinsc...@googlegroups.com

I removed token macro since the PR was merged and released.
Reply all
Reply to author
Forward
0 new messages