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

Timestamps missing for agent-based steps in Pipeline Job 2.26

    XMLWordPrintable

    Details

    • Similar Issues:
    • Released As:
      1.9

      Description

      After upgrading to Pipeline Job 2.26 earlier today, in the Console Log for pipeline builds, I only appear to have timestamps for the operations performed by the master node (i.e., the initial git checkout), but all remaining build steps that are performed on agent nodes lack timestamps entirely. The job properly recognizes that timestamps were enabled in the first place, so provides the typical "System clock time" vs., "Elapsed time" options on the left, but these only have an effect for the master node-occurring timestamps; timestamps for steps taking place on agent nodes are missing regardless.

        Attachments

          Issue Links

            Activity

            medianick Nick Jones created issue -
            vivek Vivek Pandey made changes -
            Field Original Value New Value
            Assignee Jesse Glick [ jglick ]
            Hide
            vivek Vivek Pandey added a comment -

            Jesse Glick another possible regression or this change in functionality is intentional? Looks like legit complain to me. PTAL.

            Show
            vivek Vivek Pandey added a comment - Jesse Glick another possible regression or this change in functionality is intentional? Looks like legit complain to me. PTAL.
            Hide
            medianick Nick Jones added a comment -

            I would hope it’s not intended; all our builds occur on agents (not the master) and — in case this is a factor — must run on Windows due to our tooling (e.g., Visual Studio). Running builds on the master or on non-Windows agents would not be an option for us. Thanks for looking into it!

            Show
            medianick Nick Jones added a comment - I would hope it’s not intended; all our builds occur on agents (not the master) and — in case this is a factor — must run on Windows due to our tooling (e.g., Visual Studio). Running builds on the master or on non-Windows agents would not be an option for us. Thanks for looking into it!
            Hide
            vivek Vivek Pandey added a comment -

            Nick Jones Right, most users run their builds on agent so its probably a regression.

            Show
            vivek Vivek Pandey added a comment - Nick Jones Right, most users run their builds on agent so its probably a regression.
            jglick Jesse Glick made changes -
            Labels regression
            Hide
            jglick Jesse Glick added a comment -

            Logs are now generated on the agent where applicable. I am not sure offhand why this would break the timestamper plugin, though. Do you have a sample Jenkinsfile? Anyway please note that the proposed JENKINS-48344 would make timestamp usage from Jenkins much more efficient (and it is tested with agent-based sh steps).

            Show
            jglick Jesse Glick added a comment - Logs are now generated on the agent where applicable. I am not sure offhand why this would break the timestamper plugin, though. Do you have a sample Jenkinsfile ? Anyway please note that the proposed JENKINS-48344 would make timestamp usage from Jenkins much more efficient (and it is tested with agent-based sh steps).
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-48344 [ JENKINS-48344 ]
            jglick Jesse Glick made changes -
            Component/s timestamper-plugin [ 15749 ]
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-38381 [ JENKINS-38381 ]
            Hide
            medianick Nick Jones added a comment -

            Ah, I may see the difference now – and reading through the comments on JENKINS-48344 made me realize it. The timestamps appear to have gone from being output on every line, like this:

            19:34:54 [veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A] Running batch script
            19:34:54 
            19:34:54 C:\Jenkins\workspace\veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A>C:\PROGRA~2\MSBuild\12.0\Bin\amd64\MSBuild.exe Build.proj /t:OpenCover /p:CoverageHistory=True 
            19:34:54 Microsoft (R) Build Engine version 12.0.40629.0
            19:34:54 [Microsoft .NET Framework, version 4.0.30319.42000]
            19:34:54 Copyright (C) Microsoft Corporation. All rights reserved.
            19:34:54 
            19:34:54 Build started 10/11/2018 11:34:54 PM.
            

            to being output on only the lines corresponding to the initiating step in the Jenkinsfile, like this:

            09:27:21 [veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A] Running batch script
            
            C:\Jenkins\workspace\veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A>C:\PROGRA~2\MSBuild\12.0\Bin\amd64\MSBuild.exe Build.proj /t:OpenCover /p:CoverageHistory=True 
            Microsoft (R) Build Engine version 12.0.40629.0
            [Microsoft .NET Framework, version 4.0.30319.42000]
            Copyright (C) Microsoft Corporation. All rights reserved.
            
            Build started 10/15/2018 1:27:21 PM.
            

            I could imagine that was expected behavior, although it is a change for us. In our case, our Jenkinsfile commands tend to be fairly minimal and in turn invoke other commands (like MSBuild) that do the majority of the work, so this resulted in the timestamps effectively disappearing from the meat of the build. If this is intended, it would remove much of the utility of the timestamps option for us.

            In the case I tested, timestamps were enabled via the timestamps() command in a Declarative Pipeline options block. The command in question above is a bat invocation of msbuild.exe with several command-line arguments.

            Show
            medianick Nick Jones added a comment - Ah, I may see the difference now – and reading through the comments on JENKINS-48344 made me realize it. The timestamps appear to have gone from being output on every line, like this: 19:34:54 [veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A] Running batch script 19:34:54 19:34:54 C:\Jenkins\workspace\veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A>C:\PROGRA~2\MSBuild\12.0\Bin\amd64\MSBuild.exe Build.proj /t:OpenCover /p:CoverageHistory=True 19:34:54 Microsoft (R) Build Engine version 12.0.40629.0 19:34:54 [Microsoft .NET Framework, version 4.0.30319.42000] 19:34:54 Copyright (C) Microsoft Corporation. All rights reserved. 19:34:54 19:34:54 Build started 10/11/2018 11:34:54 PM. to being output on only the lines corresponding to the initiating step in the Jenkinsfile , like this: 09:27:21 [veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A] Running batch script C:\Jenkins\workspace\veTest_declarative_pipeline-DUNYTRF5PBRWZGVAXXMHOQ6SGIJAYT2ZBLXDTW7Z24E72PESHD5A>C:\PROGRA~2\MSBuild\12.0\Bin\amd64\MSBuild.exe Build.proj /t:OpenCover /p:CoverageHistory=True Microsoft (R) Build Engine version 12.0.40629.0 [Microsoft .NET Framework, version 4.0.30319.42000] Copyright (C) Microsoft Corporation. All rights reserved. Build started 10/15/2018 1:27:21 PM. I could imagine that was expected behavior, although it is a change for us. In our case, our Jenkinsfile commands tend to be fairly minimal and in turn invoke other commands (like MSBuild) that do the majority of the work, so this resulted in the timestamps effectively disappearing from the meat of the build. If this is intended, it would remove much of the utility of the timestamps option for us. In the case I tested, timestamps were enabled via the timestamps() command in a Declarative Pipeline options block. The command in question above is a bat invocation of msbuild.exe with several command-line arguments.
            Hide
            jglick Jesse Glick added a comment -

            No that is not intentional. While I look into this, the likely hotfix is to run with the JVM option -Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=false which would disable one of the code paths I presume is contributing to this.

            Show
            jglick Jesse Glick added a comment - No that is not intentional. While I look into this, the likely hotfix is to run with the JVM option -Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=false which would disable one of the code paths I presume is contributing to this.
            Hide
            medianick Nick Jones added a comment -

            Thanks Jesse Glick – I can confirm that the JVM option provided does indeed restore the expected timestamp behavior (on every line, not just every Jenkinsfile step). Is there a downside (overhead, etc.) to running with that option? As of now I only have the newer Pipeline Job 2.26 in our test environment, so the question is whether to hold off on upgrading production to 2.26 until there is a fix, or to do so but use the JVM option along with it.

            Show
            medianick Nick Jones added a comment - Thanks Jesse Glick  – I can confirm that the JVM option provided does indeed restore the expected timestamp behavior (on every line, not just every Jenkinsfile step). Is there a downside (overhead, etc.) to running with that option? As of now I only have the newer Pipeline Job 2.26 in our test environment, so the question is whether to hold off on upgrading production to 2.26 until there is a fix, or to do so but use the JVM option along with it.
            Hide
            jglick Jesse Glick added a comment -

            It is less efficient, but same as before the workflow-durable-task-step 2.22 update.

            Show
            jglick Jesse Glick added a comment - It is less efficient, but same as before the workflow-durable-task-step 2.22 update.
            jglick Jesse Glick made changes -
            Link This issue relates to SECURITY-382 [ SECURITY-382 ]
            Hide
            jglick Jesse Glick added a comment -

            I think I see the issue—the plugin is still attempting to produce timestamp notes for lines from sh steps, but due to SECURITY-382 these notes are not trusted and so are suppressed from output.

            Not sure if there is any good fix besides the far more efficient annotation already developed in JENKINS-48344.

            Show
            jglick Jesse Glick added a comment - I think I see the issue—the plugin is still attempting to produce timestamp notes for lines from sh steps, but due to SECURITY-382 these notes are not trusted and so are suppressed from output. Not sure if there is any good fix besides the far more efficient annotation already developed in JENKINS-48344 .
            jglick Jesse Glick made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            jglick Jesse Glick made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            Hide
            jglick Jesse Glick added a comment -

            The PR for JENKINS-48344 addresses this: you can turn on a flag to enable timestamps throughout every Pipeline build; if you leave it off, the timestamps step enables them only within its body; either way, it is using lightweight annotations.

            Show
            jglick Jesse Glick added a comment - The PR for JENKINS-48344 addresses this: you can turn on a flag to enable timestamps throughout every Pipeline build; if you leave it off, the timestamps step enables them only within its body; either way, it is using lightweight annotations.
            Hide
            jglick Jesse Glick added a comment -

            For anyone interested in trying this, use this build.

            Show
            jglick Jesse Glick added a comment - For anyone interested in trying this, use this build .
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-54133 [ JENKINS-54133 ]
            Hide
            kaylinche Kay Wegner added a comment - - edited

            Jesse Glick I hereby confirm that 'timestamper-1.8.11-rc427.9b19c6eab4e0.hpi' worked for us. As side effect it also seems fixing issues reported in JENKINS-49836. Thank You.

            Show
            kaylinche Kay Wegner added a comment - - edited Jesse Glick I hereby confirm that 'timestamper-1.8.11-rc427.9b19c6eab4e0.hpi' worked for us. As side effect it also seems fixing issues reported in JENKINS-49836 . Thank You.
            Hide
            framillien Florian Ramillien added a comment - - edited

            Hi, after upgrading to last Jenkins LTS with all plugin update (pipeline + timestamps) we fall on this missing timestamp + a hudge side effect : Windows builders disconnected and builds are aborted. (maybe linux too, but this project build only on windows)

            After many tests, this is related to log volume and timestamp plugin with pipeline job. We have some compiling task (step bat running python scripts) generating huge log volume (3-5Mo), and we see :

            • Slow down of log display on jenkins UI (maybe build is slow down too, but not sure)
            • Agent is disconnected

            Trying with some other configuration it's working:

            • Same log volume but without timestamp plugin
            • timestamp plugin with less log output
            • Same log volume + Timestamp, but on a "classic" job, not a pipeline job.

            I suspect that all logs for a timestamp are buffered somewhere and cause this issue. Fixing timestamp not handled on each output lines should fix this too.

            Error, we can see in traces are like:
            [Pipeline] End of PipelineERROR: script apparently exited with code 0 but asynchronous notification was lost
            Finished: FAILURE
            Or more random errors like:

            2018-10-23 15:01:30 Cannot contact win-xxxx-xx: java.lang.InterruptedException
            hudson.remoting.RequestAbortedException: java.nio.channels.ClosedChannelException

            We will try your patch and/or durable task configuration option described here. Do you want I open a new bug report for this ?

            Show
            framillien Florian Ramillien added a comment - - edited Hi, after upgrading to last Jenkins LTS with all plugin update (pipeline + timestamps) we fall on this missing timestamp + a hudge side effect : Windows builders disconnected and builds are aborted. (maybe linux too, but this project build only on windows) After many tests, this is related to log volume and timestamp plugin with pipeline job. We have some compiling task (step bat running python scripts) generating huge log volume (3-5Mo), and we see : Slow down of log display on jenkins UI (maybe build is slow down too, but not sure) Agent is disconnected Trying with some other configuration it's working: Same log volume but without timestamp plugin timestamp plugin with less log output Same log volume + Timestamp, but on a "classic" job, not a pipeline job. I suspect that all logs for a timestamp are buffered somewhere and cause this issue. Fixing timestamp not handled on each output lines should fix this too. Error, we can see in traces are like: [Pipeline] End of PipelineERROR: script apparently exited with code 0 but asynchronous notification was lost Finished: FAILURE Or more random errors like: 2018-10-23 15:01:30 Cannot contact win-xxxx-xx: java.lang.InterruptedException hudson.remoting.RequestAbortedException: java.nio.channels.ClosedChannelException We will try your patch and/or durable task configuration option described here. Do you want I open a new bug report for this ?
            Hide
            framillien Florian Ramillien added a comment - - edited

            Our tests results are:

            • Standard JOB + Timestamper 1.8.10 => Build OK in less than 10 mn with expected timestamp on each line
            • Pipeline Job without Timestamper => Build OK in less than 10 mn
            • Pipeline Job + Timestamper RC 1.8.11 => Build Reported Fail in 19 mn with expected timestamp on each line.
            • Pipeline Job + Timestamper RC 1.8.11 + USE_WATCHING=false => Build OK in less than 10 mn with expected timestamp

            I say "Reported fail" because if we look on slave, build is correct and in "durable-xxxx" directory we could see that :

            • job result is OK (jenkins-result.txt)
            • delta time between "jenkins-main.bat" and "jenkins-result.txt" is less than 10mn (expected build time).
            • Log file (jenkins-logs.txt) size for this step is 3.5 Mo

            Looking further on log on Jenkins UI, I could see that pipeline end in the middle of the log and 9 mn later some more logs are displayed (but not the full logs) and job fail:
            **

            2018-10-24 10:18:24 Some CPP compiler outputs
            2018-10-24 10:18:24 [Pipeline] }[Pipeline] // timestamps[Pipeline] }
            2018-10-24 10:27:34 Some CPP compiler outputs
            2018-10-24 10:27:34 [Pipeline] // sshagent Some CPP compiler outputs
            2018-10-24 10:27:34 Some CPP compiler outputs
            ... many outputs lines with time stamp ...
            2018-10-24 10:27:34 Some CPP compiler outputs
            ERROR: script apparently exited with code 0 but asynchronous notification was lost[ 2018-10-24T10:27:34.892Z
            Finished: FAILURE
            

             

            Show
            framillien Florian Ramillien added a comment - - edited Our tests results are: Standard JOB + Timestamper 1.8.10 => Build OK in less than 10 mn with expected timestamp on each line Pipeline Job without Timestamper => Build OK in less than 10 mn Pipeline Job + Timestamper RC 1.8.11 => Build Reported Fail in 19 mn with expected timestamp on each line. Pipeline Job + Timestamper RC 1.8.11 + USE_WATCHING=false => Build OK in less than 10 mn with expected timestamp I say "Reported fail" because if we look on slave, build is correct and in "durable-xxxx" directory we could see that : job result is OK (jenkins-result.txt) delta time between "jenkins-main.bat" and "jenkins-result.txt" is less than 10mn (expected build time). Log file (jenkins-logs.txt) size for this step is 3.5 Mo Looking further on log on Jenkins UI, I could see that pipeline end in the middle of the log and 9 mn later some more logs are displayed (but not the full logs) and job fail: ** 2018-10-24 10:18:24 Some CPP compiler outputs 2018-10-24 10:18:24 [Pipeline] }[Pipeline] // timestamps[Pipeline] } 2018-10-24 10:27:34 Some CPP compiler outputs 2018-10-24 10:27:34 [Pipeline] // sshagent Some CPP compiler outputs 2018-10-24 10:27:34 Some CPP compiler outputs ... many outputs lines with time stamp ... 2018-10-24 10:27:34 Some CPP compiler outputs ERROR: script apparently exited with code 0 but asynchronous notification was lost[ 2018-10-24T10:27:34.892Z Finished: FAILURE  
            Hide
            jglick Jesse Glick added a comment -

            Windows builders disconnected and builds are aborted

            Maybe JENKINS-53888.

            Show
            jglick Jesse Glick added a comment - Windows builders disconnected and builds are aborted Maybe JENKINS-53888 .
            Hide
            framillien Florian Ramillien added a comment -

            The result is the same, yes. But I don't think the cause was the same, in our case connection with agent is working unless some specific combinaison of components:

            • A long build with a simple task (ping during 20mn) is working
            • A shorter build (10mn) with hudge log generated by "bat" step, fail (see previous comment).
            • Removing "timestamps" step from pipeline fix this issue
            • Reverting from "push" to "pull" logs in "durable-task" fix this issue too.

            In our case, something occurs at the end of the job between master and slave, and master never receive the "OK" result from slave (nor the full logs). And after 9mn of inactivity build fail and agent is disconnected. It's always reproduced with hudge logs, but maybe logs size is just a factor triggering another hidden synchro/lock problem.

            For now "USE_WATCHING=false" is set in our Jenkins master and is an acceptable solution for us.

            Show
            framillien Florian Ramillien added a comment - The result is the same, yes. But I don't think the cause was the same, in our case connection with agent is working unless some specific combinaison of components: A long build with a simple task (ping during 20mn) is working A shorter build (10mn) with hudge log generated by "bat" step, fail (see previous comment). Removing "timestamps" step from pipeline fix this issue Reverting from "push" to "pull" logs in "durable-task" fix this issue too. In our case, something occurs at the end of the job between master and slave, and master never receive the "OK" result from slave (nor the full logs). And after 9mn of inactivity build fail and agent is disconnected. It's always reproduced with hudge logs, but maybe logs size is just a factor triggering another hidden synchro/lock problem. For now "USE_WATCHING=false" is set in our Jenkins master and is an acceptable solution for us.
            Hide
            jglick Jesse Glick added a comment -

            Florian Ramillien please discuss in JENKINS-53888.

            Show
            jglick Jesse Glick added a comment - Florian Ramillien please discuss in JENKINS-53888 .
            vivek Vivek Pandey made changes -
            Labels regression regression triaged-2018-11
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-52165 [ JENKINS-52165 ]
            jglick Jesse Glick made changes -
            Released As 1.9
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            jglick Jesse Glick made changes -
            Component/s workflow-job-plugin [ 21716 ]
            Hide
            ljubisap Ljubisa Punosevac added a comment - - edited

            Hi, 

            Unfortunately, this problem still prevails on Jenkins ver. 2.190.1 and timestamper version 1.10.
            I tried also older versions of this plugin for which has been written here to work, but again with the same results.
            Also, the following option has been set on Jenkins master as JVM parameter, but again with the same outcome:

            -Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=false
            

            All our jobs are pipelines and timestamps appear only in a few places. Most of the time they are gone.

            [Pipeline] configFileProvider
            [2019-10-11T11:22:10.289Z] provisioning config files...
            [2019-10-11T11:22:10.299Z] copy managed file [live-env-configuration.properties] to file:/var/lib/jenkins/workspace/generic-test-junit@tmp/config11258587709499260226tmp
            [Pipeline] {
            [Pipeline] readProperties
            [Pipeline] }
            [2019-10-11T11:22:10.350Z] Deleting 1 temporary files
            [Pipeline] // configFileProvider
            [Pipeline] sh
            [2019-10-11T11:22:09.383Z] Creating folder: /var/lib/jenkins/.m2
            [2019-10-11T11:22:09.388Z] Creating file: /var/lib/jenkins/.m2/settings.xml
            [2019-10-11T11:22:09.395Z] Creating folder: /var/lib/jenkins/workspace/generic-test-junit/.repository
            [2019-10-11T11:22:10.683Z] `s3/ec-test-release-pipeline/191011019/pipeline.properties` -> `pipeline.properties`
            [2019-10-11T11:22:10.683Z] Total: 962 B, Transferred: 962 B, Speed: 37.11 KiB/s
            [Pipeline] script
            [Pipeline] {
            [Pipeline] readProperties
            [Pipeline] }
            [Pipeline] // script
            [Pipeline] lock
            [2019-10-11T11:22:10.789Z] Trying to acquire lock on [Label: s3, Quantity: 1]
            [2019-10-11T11:22:10.789Z] Lock acquired on [Label: s3, Quantity: 1]
            [Pipeline] {
            [Pipeline] configFileProvider
            [2019-10-11T11:22:10.852Z] provisioning config files...
            [2019-10-11T11:22:10.862Z] copy managed file [live-env-configuration.properties] to file:/var/lib/jenkins/workspace/generic-test-junit@tmp/config1796990335769048953tmp
            [Pipeline] {
            [Pipeline] readProperties
            [Pipeline] }
            [2019-10-11T11:22:10.916Z] Deleting 1 temporary files
            [Pipeline] // configFileProvider
            [Pipeline] withCredentials
            [2019-10-11T11:22:10.958Z] Masking supported pattern matches of $S3_USERNAME or $S3_PASSWORD
            [Pipeline] {
            [Pipeline] sh
            Added `s3` successfully.
            [Pipeline] }
            [Pipeline] // withCredentials
            [Pipeline] withEnv
            [Pipeline] {
            [Pipeline] withEnv
            [Pipeline] {
            [Pipeline] fileExists
            [Pipeline] dir
            Running in /var/lib/jenkins/ramdisk
            [Pipeline] {
            [Pipeline] configFileProvider
            provisioning config files...
            copy managed file [live-env-configuration.properties] to file:/var/lib/jenkins/ramdisk@tmp/config2573695607279314921tmp
            [Pipeline] {
            [Pipeline] readProperties
            [Pipeline] }
            Deleting 1 temporary files
            [Pipeline] // configFileProvider
            

            Is there a solution to this problem?

            Best,
            Ljubisa.
             

            Show
            ljubisap Ljubisa Punosevac added a comment - - edited Hi,  Unfortunately, this problem still prevails on Jenkins ver. 2.190.1 and timestamper version 1.10 . I tried also older versions of this plugin for which has been written here to work, but again with the same results. Also, the following option has been set on Jenkins master as JVM parameter, but again with the same outcome: -Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING= false All our jobs are pipelines and timestamps appear only in a few places. Most of the time they are gone. [Pipeline] configFileProvider [2019-10-11T11:22:10.289Z] provisioning config files... [2019-10-11T11:22:10.299Z] copy managed file [live-env-configuration.properties] to file:/ var /lib/jenkins/workspace/ generic -test-junit@tmp/config11258587709499260226tmp [Pipeline] { [Pipeline] readProperties [Pipeline] } [2019-10-11T11:22:10.350Z] Deleting 1 temporary files [Pipeline] // configFileProvider [Pipeline] sh [2019-10-11T11:22:09.383Z] Creating folder: / var /lib/jenkins/.m2 [2019-10-11T11:22:09.388Z] Creating file: / var /lib/jenkins/.m2/settings.xml [2019-10-11T11:22:09.395Z] Creating folder: / var /lib/jenkins/workspace/ generic -test-junit/.repository [2019-10-11T11:22:10.683Z] `s3/ec-test-release-pipeline/191011019/pipeline.properties` -> `pipeline.properties` [2019-10-11T11:22:10.683Z] Total: 962 B, Transferred: 962 B, Speed: 37.11 KiB/s [Pipeline] script [Pipeline] { [Pipeline] readProperties [Pipeline] } [Pipeline] // script [Pipeline] lock [2019-10-11T11:22:10.789Z] Trying to acquire lock on [Label: s3, Quantity: 1] [2019-10-11T11:22:10.789Z] Lock acquired on [Label: s3, Quantity: 1] [Pipeline] { [Pipeline] configFileProvider [2019-10-11T11:22:10.852Z] provisioning config files... [2019-10-11T11:22:10.862Z] copy managed file [live-env-configuration.properties] to file:/ var /lib/jenkins/workspace/ generic -test-junit@tmp/config1796990335769048953tmp [Pipeline] { [Pipeline] readProperties [Pipeline] } [2019-10-11T11:22:10.916Z] Deleting 1 temporary files [Pipeline] // configFileProvider [Pipeline] withCredentials [2019-10-11T11:22:10.958Z] Masking supported pattern matches of $S3_USERNAME or $S3_PASSWORD [Pipeline] { [Pipeline] sh Added `s3` successfully. [Pipeline] } [Pipeline] // withCredentials [Pipeline] withEnv [Pipeline] { [Pipeline] withEnv [Pipeline] { [Pipeline] fileExists [Pipeline] dir Running in / var /lib/jenkins/ramdisk [Pipeline] { [Pipeline] configFileProvider provisioning config files... copy managed file [live-env-configuration.properties] to file:/ var /lib/jenkins/ramdisk@tmp/config2573695607279314921tmp [Pipeline] { [Pipeline] readProperties [Pipeline] } Deleting 1 temporary files [Pipeline] // configFileProvider Is there a solution to this problem? Best, Ljubisa.  
            ljubisap Ljubisa Punosevac made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            jglick Jesse Glick added a comment -

            Ljubisa Punosevac it is hard to know offhand what your issue is. If you are consistently missing timestamps, it would be better to file a fresh bug with complete, self-contained steps to reproduce your problem from scratch, and link it to this one.

            Show
            jglick Jesse Glick added a comment - Ljubisa Punosevac it is hard to know offhand what your issue is. If you are consistently missing timestamps, it would be better to file a fresh bug with complete, self-contained steps to reproduce your problem from scratch , and link it to this one.
            jglick Jesse Glick made changes -
            Resolution Fixed [ 1 ]
            Status Reopened [ 4 ] Resolved [ 5 ]
            ljubisap Ljubisa Punosevac made changes -
            Link This issue is related to JENKINS-59788 [ JENKINS-59788 ]
            Hide
            ljubisap Ljubisa Punosevac added a comment -

            Jesse GlickCreated new ticket JENKINS-59788 with simple dummy pipeline how to reproduce it.

            Show
            ljubisap Ljubisa Punosevac added a comment - Jesse Glick Created new ticket JENKINS-59788 with simple dummy pipeline how to reproduce it.

              People

              Assignee:
              jglick Jesse Glick
              Reporter:
              medianick Nick Jones
              Votes:
              9 Vote for this issue
              Watchers:
              19 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: