[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)
Title: Message Title Quentin Dufour commented on JENKINS-37263 Re: Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash) I've setup a fresh Jenkins instance (v2.7.3) on Linux with the recommended plugins. I reproduced the steps above, but I couldn't reproduce the bug. I tried with the following behaviours activated : Nothing Clone to a local branch '**' Clone to a local branch '**' + checkout timeout + clone timeout + clean before checkout But the fact that I didn't succeed to reproduce the bug doesn't necessarily mean that this bug is totally fixed. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)
Title: Message Title Quentin Dufour commented on JENKINS-37263 Re: Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash) I'm not sure to understand what you expect of me. You want that I reproduce the bug with the new version of the plugin without any patch ? While awaiting your answer, I'll do that. I've also opened a pull request here with a non complete proposed fix, but waiting for your or others feedbacks: https://github.com/jenkinsci/git-plugin/pull/435 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37727) Jobs of a multibranch pipeline project are not anymore deleted in upstream
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37727 Jobs of a multibranch pipeline project are not anymore deleted in upstream Change By: Quentin Dufour h2. ProblemIf you compile git-plugin from the source, and set 'Discard old items' in the multibranch pipeline, deleted branches on the SCM are not deleted from the job list. If you install the 2.5.3 version of this plugin and restart Jenkins, these branches are deleted.h2. How to reproduce it*Configure a Jenkins installation*# Download a fresh Jenkins (2.7.2), rename your current home# Start it: java -jar jenkins.war# Choose the default packages option during the first boot# Clone git-plugin repository, compile it (mvn.cmd '-Dmaven.test.skip=true' clean install hpi:hpi)# Import your git-plugin (the one you compiled) in Jenkins (advanced tab)# Restart Jenkins*See the error*# Create a test git repository with a Jenkinsfile on many branches# Add a new multibranch pipeline, select "Discard old items"# Save, check that your branches appear in the list# Delete a branch from your repository. git push origin :features/a-random-branch# Run a branch indexing# See that your branch was not deleted*Check that 2.5.3 is working*# Restore the git-plugin in its original version, 2.5.3# Restart Jenkins# Rerun branch indexing, see that your branch has disappeared ! h2. InvestigationsI didn't have the time to run a Jenkins instance in debug, or to read the commits yet. So I've no idea why this bug happens. I'll update this section later if I've time. Add Comment
[JIRA] (JENKINS-37727) Jobs of a multibranch pipeline project are not anymore deleted in upstream
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37727 Jobs of a multibranch pipeline project are not anymore deleted in upstream Change By: Quentin Dufour h2. ProblemIf you compile git-plugin from the source, and set 'Discard old items' in the multibranch pipeline, deleted branches on the SCM are not deleted from the job list. If you install the 2.5.3 version of this plugin and restart Jenkins, these branches are deleted.h2. How to reproduce it *Configure a Jenkins installation* # Download a fresh Jenkins (2.7.2), rename your current home# Start it: java -jar jenkins.war# Choose the default packages for option during the first boot# Clone git-plugin repository, compile it (mvn.cmd '-Dmaven.test.skip=true' clean install hpi:hpi)# Import your git-plugin (the one you compiled) in Jenkins (advanced tab)# Restart Jenkins *See the error* # Create a test git repository with a Jenkinsfile on many branches# Add a new multibranch pipeline, select "Discard old items"# Save, check that your branches appear in the list# Delete a branch from your repository. git push origin :features/a-random-branch# Run a branch indexing# See that your branch was not deleted *Check that 2.5.3 is working* # Restore the git-plugin in its original version, 2.5.3# Restart Jenkins# Rerun branch indexing, see that your branch has disappeared ! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37727) Jobs of a multibranch pipeline project are not anymore deleted in upstream
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37727 Jobs of a multibranch pipeline project are not anymore deleted in upstream Change By: Quentin Dufour Summary: Branches Jobs of a multibranch pipelines pipeline project are not anymore deleted in upstream Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37727) Branches of multibranch pipelines are not anymore deleted in upstream
Title: Message Title Quentin Dufour created an issue Jenkins / JENKINS-37727 Branches of multibranch pipelines are not anymore deleted in upstream Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2016/Aug/26 7:42 PM Environment: git-plugin compiled from master. This bug does not exist in git-plugin 2.5.3 Priority: Minor Reporter: Quentin Dufour Problem If you compile git-plugin from the source, and set 'Discard old items' in the multibranch pipeline, deleted branches on the SCM are not deleted from the job list. If you install the 2.5.3 version of this plugin and restart Jenkins, these branches are deleted. How to reproduce it Download a fresh Jenkins (2.7.2), rename your current home Start it: java -jar jenkins.war Choose the default packages for the first boot Clone git-plugin repository, compile it (mvn.cmd '-Dmaven.test.skip=true' clean install hpi:hpi) Import your git-plugin (the one you compiled) in Jenkins (advanced tab) Restart Jenkins Create a test git repository with a Jenkinsfile on many branches Add a new multibranch pipeline, select "Discard old items" Save, check that your branches appear in the list
[JIRA] (JENKINS-37575) Jenkins node keeps sending the same logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the same logs indefinitely Change By: Quentin Dufour Summary: Jenkins node keeps sending the sames same logs indefinitely Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour Component/s: remoting Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures occurs more often when I restart Jenkins while there are some tasks running. But I'm not sure. It also seems that the problem is linked to a high load/network on the master/node. We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning that I have 3 jenkins nodes on the same machine , and that my JENKINS-HOME is located on a network drive (CIFS/SMB) ._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning that I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning that I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning that I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning but that I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning but I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning but I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning but I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!_I think it's worth mentionning but I have 3 jenkins nodes on the same machine._h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail! _I think it's worth mentionning but I have 3 jenkins nodes on the same machine._ h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour Attachment: Capture d'écran de 2016-08-20 23-41-53.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemSometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines.It seems that the problem occures more when I restart Jenkins while there are some tasks running.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! *Update 4:* It seems that when the master deserializes the response of the node, it returns a null object instead of the logs when it comes to Write Logs... !Capture d'écran de 2016-08-20 23-41-53.png|thumbnail! h1. How
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. Problem The Sometimes, after a certain amount of builds, the build never ends on the node. It sends forever the same 20-30 lines. It seems that the problem occures more when I restart Jenkins while there are some tasks running. We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3:* It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. I had to put my production in debug to inspect the error.As I don't understand why it fails, I can't create a reproduce protocol
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!*Update 1:* It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.*Update 2:* It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!*Update 3: *It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... So it saves the log but interrupt the task, send to the slave that it has interrupted the task. The slave thinks that the logs has not been saved, and resend it to the master, which don't find the node workspace in it's local filesystem, etc. !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail! * Update 1: * It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now. * Update 2: * It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail! * Update 3: * It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. When executing the green line on the following screenshot. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! The error is catched in DurableTaskStep$Execution.check, as it seems to be a workspace error. It seems that Jenkins doesn't find the workspace folder, as it's searching the jenkins node workspace in its local file system. C:\\ci\\int12\\ocoint... !Capture d'écran de 2016-08-20 19-35-13.png|thumbnail! h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour Attachment: Capture d'écran de 2016-08-20 19-35-13.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution)!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.(Yes, it's really stored in the JENKINS_HOME)!jekins_10GB_log.png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot)!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail! Edit Update 1: It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now. Edit Update 2: It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson.remoting.ProxyOutputStream.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail! Update 3: It seems that the Jenkins Master is guilty. I've connected my debugger to this one. The error occurs when it tries to write the log in its JENKINS_HOME. !Capture d'écran de 2016-08-20 19-35-36.png|thumbnail! h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour Attachment: Capture d'écran de 2016-08-20 19-35-36.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines. We can see the difference between the timestamper date (put when received by the master) and the log date (written during the Powershell execution) !Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process. (Yes, it's really stored in the JENKINS_HOME) !jekins_10GB_log.png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase. The process is terminated, the log file is not bigger than 3MB (and can be seen in the upper left corner of the screenshot) !Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!Edit 1: It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.Edit 2: It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop in hudson . remoting.ProxyOutputStream. !Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.!Capture d'écran de 2016-08-20 16-35-18.png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.! jenkins_10GB_log jekins_10GB_log .png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.!Capture d'écran de 2016-08-20 17-04-34.png|thumbnail!Edit 1: It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.Edit 2: It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.!Capture d'écran de 2016-08-20 19 16 - 02 35 - 41 18 .png|thumbnail!Some logs files can be bigger than 10GB before I kill the process.! Capture d'écran de 2016-08-20 19-02-41 jenkins_10GB_log .png|thumbnail!h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase. !Capture d'écran de 2016-08-20 17-04-34.png|thumbnail! Edit 1: It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.Edit 2: It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop.!Capture d'écran de 2016-08-20 19-02-41.png|thumbnail!h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines. !Capture d'écran de 2016-08-20 19-02-41.png|thumbnail! Some logs files can be bigger than 10GB before I kill the process. !Capture d'écran de 2016-08-20 19-02-41.png|thumbnail! h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.Edit 1: It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.Edit 2: It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop.!Capture d'écran de 2016-08-20 19-02-41.png |thumbnail ! h2. ScreenshotsOn the first one we can see the logs. Especially that the date from timestamper is different from the date of the logs. It's a good indication that we have a problem.On the second screenshot, I've connected netbeans on the node which handle the job. I've stopped the thread and also put a breakpoint on sink.write(buf). When I hit continue, I've seen that this function is always called. We can see some variables, especially the file descriptor and its associated size. The folder of this file is open on the top left of this screenshot. We can see that the size of this file is arround 3MB.On the last screenshot, it's just an example at how big the file becomes before crashing Jenkins in an Out of Memory Exception... h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.Some logs files can be bigger than 10GB before I kill the process.h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.Edit 1: It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now.Edit 2: It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop. !Capture d'écran de 2016-08-20 19-02-41.png! h2. ScreenshotsOn the first one we can see the logs. Especially that the date from timestamper is different from the date of the logs. It's a good indication that we have a problem.On the second screenshot, I've connected netbeans on the node which handle the job. I've stopped the thread and also put a breakpoint on sink.write(buf). When I hit continue, I've seen that this function is always called. We can see some variables, especially the file descriptor and its associated size. The folder of this file is open on the top left of this screenshot. We can see that the size of this file is arround 3MB.On the last screenshot, it's just an example at how big the file becomes before crashing Jenkins in an Out of Memory Exception...h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour Attachment: Capture d'écran de 2016-08-20 19-02-41.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.Some logs files can be bigger than 10GB before I kill the process.h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase. Edit 1: It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now. Edit 2: It seems that it comes from the network, as I've captured a java.io.InterruptedIOException in this loop. h2. ScreenshotsOn the first one we can see the logs. Especially that the date from timestamper is different from the date of the logs. It's a good indication that we have a problem.On the second screenshot, I've connected netbeans on the node which handle the job. I've stopped the thread and also put a breakpoint on sink.write(buf). When I hit continue, I've seen that this function is always called. We can see some variables, especially the file descriptor and its associated size. The folder of this file is open on the top left of this screenshot. We can see that the size of this file is arround 3MB.On the last screenshot, it's just an example at how big the file becomes before crashing Jenkins in an Out of Memory Exception...h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.Some logs files can be bigger than 10GB before I kill the process.h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase. It seems that Jenkins read the whole file. If it fails, it will return 0. I suspect that Jenkins is failing to close the file descriptor. So the lastLocation is not updated. But the data are sent. Jenkins retries to read the file, fail again, etc. That's only a supposition for now. h2. ScreenshotsOn the first one we can see the logs. Especially that the date from timestamper is different from the date of the logs. It's a good indication that we have a problem.On the second screenshot, I've connected netbeans on the node which handle the job. I've stopped the thread and also put a breakpoint on sink.write(buf). When I hit continue, I've seen that this function is always called. We can see some variables, especially the file descriptor and its associated size. The folder of this file is open on the top left of this screenshot. We can see that the size of this file is arround 3MB.On the last screenshot, it's just an example at how big the file becomes before crashing Jenkins in an Out of Memory Exception...h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.Some logs files can be bigger than 10GB before I kill the process.h1. Investigationh2. StepsI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase.h2. ScreenshotsOnthe first one we can see the logs. Especially that the date from timestamper is different from the date of the logs. It's a good indication that we have a problem. On the second screenshot, I've connected netbeans on the node which handle the job. I've stopped the thread and also put a breakpoint on sink.write(buf). When I hit continue, I've seen that this function is always called. We can see some variables, especially the file descriptor and its associated size. The folder of this file is open on the top left of this screenshot. We can see that the size of this file is arround 3MB.On the last screenshot, it's just an example at how big the file becomes before crashing Jenkins in an Out of Memory Exception... h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.Some logs files can be bigger than 10GB before I kill the process.h1. Investigation h2. Steps I've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase. (check the attached screenshots above) h2. Screenshots On h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour Attachment: jekins_10GB_log.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Change By: Quentin Dufour Attachment: Capture d'écran de 2016-08-20 17-04-34.png Attachment: Capture d'écran de 2016-08-20 16-35-18.png h1. ProblemThe build never ends on the node. It sends forever the same 20-30 lines.Some logs files can be bigger than 10GB before I kill the process.h1. InvestigationI've found on Wireshark that the node keeps sending the same logs forever.So the jenkins master is not (directly) the culprit.After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.javaThe same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase. (check the attached screenshots above) h1. How to reproduceI've tried to reproduce this bug for 3 days but didn't achieve to. Add Comment
[JIRA] (JENKINS-37575) Jenkins node keeps sending the sames logs indefinitely
Title: Message Title Quentin Dufour created an issue Jenkins / JENKINS-37575 Jenkins node keeps sending the sames logs indefinitely Issue Type: Bug Assignee: Jesse Glick Components: durable-task-plugin Created: 2016/Aug/20 9:15 PM Environment: Windows Server 2012 R2 Jenkins 2.7.2 Priority: Major Reporter: Quentin Dufour Problem The build never ends on the node. It sends forever the same 20-30 lines. Some logs files can be bigger than 10GB before I kill the process. Investigation I've found on Wireshark that the node keeps sending the same logs forever. So the jenkins master is not (directly) the culprit. After enabling the debugguer on the slave, I've found that the method FileMonitoringTask$FileMonitoringController$WriteLog.invoke is called in an infinite loop somewhere in this file: durable-task-plugin\src\main\java\org\jenkinsci\plugins\durabletask\FileMonitoringTask.java The same file is read again and again with a lastLocation of 1930670. lastLocation represent the bytes already read. But I don't understand why it doesn't increase. How to reproduce I've tried to reproduce this bug for 3 days but didn't achieve to.
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)
Title: Message Title Quentin Dufour commented on JENKINS-37263 Re: Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash) A huge thanks for your reply Mark Waite. I agree that modifying the git plugin would be more universal. If you don't have time, I can try to work on a fix this week-end, as usual no promise, I'll do my best. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37345) Throttle automatic git checkout to prevent timeouts/overload on first indexing
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37345 Throttle automatic git checkout to prevent timeouts/overload on first indexing Change By: Quentin Dufour Summary: Throttle automatic git checkout to prevent timeouts/overload on first indexing Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37345) Throttle automatic git checkout
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37345 Throttle automatic git checkout Change By: Quentin Dufour h2. ProblemI have a huge repository (~500MB) with many branches (~30) with each containing a Jenkinsfile. The first indexing is quite painful.Jenkins will detect all branches, and trigger a build for each one. Each build will start by cloning the git repository on the master to fetch the Jenkinsfile. But this tasks will not use/require a free executor on the master. So, the 30 git clone will be launched at the same time, trying to download 30 times the same 500MB repository. It will end with a really slow Jenkins and a timeout.I'll have to manually relaunch every branch, one or two at a time to fix this problem.h2. Possible solutionIs it possible to use an executor on the master during the checkout ? To throttle the git clones ?h2. How to reproduce it * Create a git repository* Create a Jenkinsfile with something in it (echo 'hello world')* Add a huge file (an ISO of your favorite Linux distribution or something else)* Commit it* Create 30 branches* Add this project in your Jenkins as a Multibranch Pipeline. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37345) Throttle automatic git checkout
Title: Message Title Quentin Dufour created an issue Jenkins / JENKINS-37345 Throttle automatic git checkout Issue Type: Bug Assignee: Manuel Recena Soto Components: workflow-multibranch-plugin Created: 2016/Aug/11 2:15 PM Priority: Minor Reporter: Quentin Dufour Problem I have a huge repository (~500MB) with many branches (~30) with each containing a Jenkinsfile. The first indexing is quite painful. Jenkins will detect all branches, and trigger a build for each one. Each build will start by cloning the git repository on the master to fetch the Jenkinsfile. But this tasks will not use/require a free executor on the master. So, the 30 git clone will be launched at the same time, trying to download 30 times the same 500MB repository. It will end with a really slow Jenkins and a timeout. I'll have to manually relaunch every branch, one or two at a time to fix this problem. Possible solution Is it possible to use an executor on the master during the checkout ? To throttle the git clones ? How to reproduce it Add Comment
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)
Title: Message Title Quentin Dufour started work on JENKINS-37263 Change By: Quentin Dufour Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37185) Checkout timeout is not honored when used with local branch parameter
Title: Message Title Quentin Dufour started work on JENKINS-37185 Change By: Quentin Dufour Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project configured with the local branch extension and many branch following the git flow model (features/). When I push a commit on the feature branch, this commit is detected by Jenkins, and pulled by the master to read the Jenkinsfile. The first time it works, but after that, the local branch is selected instead of the remote branch, amd the new commits are not fetch. The bug only occurs on branches with a slash in their names.h2. InvestigationI've connected my debugger to my Jenkins installation. !jenkins-local-branch-bug-1.PNG|thumbnail! It appears that Jenkins has detected 2 branches matching the name. One local and one remote. The local one is created by the local branch git extension.I can't explicitly specify to Jenkins to use the remote one because I use the pipeline plugin, and this checkout is made automatically to retrieve the Jenkinsfile. So, the git implementation takes the first one, which is generally the local branch which is not yet updated...{code:java}Revision marked = candidates.iterator().next();{code}h2. Logs{noformat}16:10:31 Multiple candidate revisions16:10:31 Checking out Revision 604398f062b459c797f31d6c13b568dd7612362d (features/my-feature-branch)16:10:31 > git.exe config core.sparsecheckout # timeout=3016:10:31 > git.exe checkout -f 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe branch -a -v --no-abbrev # timeout=3016:10:32 > git.exe branch -D features/my-feature-branch # timeout=3016:10:32 > git.exe checkout -b features/my-feature-branch 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30{noformat}h2. How to fix itPossibilities I see : * Update the workflow-multibranch-plugin / branch-api-plugin to checkout on origin (prefix with refs/remotes/origin/) * Update the git-plugin to order the list, and prioritize remote branchesPersonally, I think the first one is safer, but I've not yet played with this plugin. Here is my proposition on Github: https://github.com/jenkinsci/branch-api-plugin/pull/47 h2. How to reproduce# Create a new repository and initialize it (on github, with a README.md for example)# Clone it on your computer: {noformat}git clone https://lausivoiduts.visualstudio.com/QuarahMC/_git/JENKINS-37263cd JENKINS-37263{noformat}# Create a new branch: {noformat}git checkout -b features/this-bug{noformat}# Add something in the Jenkinsfile: {noformat}echo "echo 'first commit' " > Jenkinsfile{noformat}# Commit and push it: {noformat}git add Jenkinfilegit commit -m "first commit" git push --set-upstream origin features/this-bug{noformat}# Add a new Multibranch Pipeline Project in Jenkins, add as Source your git repository. Click on "Add Behaviour", select "Checkout to a local
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project configured with the local branch extension and many branch following the git flow model (features/). When I push a commit on the feature branch, this commit is detected by Jenkins, and pulled by the master to read the Jenkinsfile. The first time it works, but after that, the local branch is selected instead of the remote branch, amd the new commits are not fetch. The bug only occurs on branches with a slash in their names.h2. InvestigationI've connected my debugger to my Jenkins installation. !jenkins-local-branch-bug-1.PNG|thumbnail! It appears that Jenkins has detected 2 branches matching the name. One local and one remote. The local one is created by the local branch git extension.I can't explicitly specify to Jenkins to use the remote one because I use the pipeline plugin, and this checkout is made automatically to retrieve the Jenkinsfile. So, the git implementation takes the first one, which is generally the local branch which is not yet updated...{code:java}Revision marked = candidates.iterator().next();{code}h2. Logs{noformat}16:10:31 Multiple candidate revisions16:10:31 Checking out Revision 604398f062b459c797f31d6c13b568dd7612362d (features/my-feature-branch)16:10:31 > git.exe config core.sparsecheckout # timeout=3016:10:31 > git.exe checkout -f 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe branch -a -v --no-abbrev # timeout=3016:10:32 > git.exe branch -D features/my-feature-branch # timeout=3016:10:32 > git.exe checkout -b features/my-feature-branch 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30{noformat}h2. How to fix itPossibilities I see : * Update the workflow-multibranch-plugin to checkout on origin (prefix with refs/remotes/origin/) * Update the git-plugin to order the list, and prioritize remote branchesPersonally, I think the first one is safer, but I've not yet played with this plugin.h2. How to reproduce# Create a new repository and initialize it (on github, with a README.md for example)# Clone it on your computer: {noformat}git clone https://lausivoiduts.visualstudio.com/QuarahMC/_git/JENKINS-37263 ; cd JENKINS-37263{noformat}# Create a new branch: {noformat} git checkout -b features/this-bug {noformat} # Add something in the Jenkinsfile: {noformat} echo "echo 'first commit' " > Jenkinsfile {noformat} # Commit and push it: {noformat} git add Jenkinfile ; git commit -m "first commit" ;git push --set-upstream origin features/this-bug {noformat} # Add a new Multibranch Pipeline Project in Jenkins, add as Source your git repository.Click on "Add Behaviour", select "Checkout to a local branch".Set its value to "**" (without the quotes).Validate it.#
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash) Change By: Quentin Dufour Summary: Jenkins checkout the wrong commit when used with the local branch extension behaviour on a branch with a / (slash) Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project configured with the local branch extension and many branch following the git flow model (features/). When I push a commit on the feature branch, this commit is detected by Jenkins, and pulled by the master to read the Jenkinsfile. The first time it works, but after that, the local branch is selected instead of the remote branch, amd the new commits are not fetch. The bug only occurs on branches with a slash in their names.h2. InvestigationI've connected my debugger to my Jenkins installation. !jenkins-local-branch-bug-1.PNG|thumbnail! It appears that Jenkins has detected 2 branches matching the name. One local and one remote. The local one is created by the local branch git extension.I can't explicitly specify to Jenkins to use the remote one because I use the pipeline plugin, and this checkout is made automatically to retrieve the Jenkinsfile. So, the git implementation takes the first one, which is generally the local branch which is not yet updated...{code:java}Revision marked = candidates.iterator().next();{code}h2. Logs{noformat}16:10:31 Multiple candidate revisions16:10:31 Checking out Revision 604398f062b459c797f31d6c13b568dd7612362d (features/my-feature-branch)16:10:31 > git.exe config core.sparsecheckout # timeout=3016:10:31 > git.exe checkout -f 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe branch -a -v --no-abbrev # timeout=3016:10:32 > git.exe branch -D features/my-feature-branch # timeout=3016:10:32 > git.exe checkout -b features/my-feature-branch 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30{noformat}h2. How to fix itPossibilities I see : * Update the workflow-multibranch-plugin to checkout on origin (prefix with refs/remotes/origin/) * Update the git-plugin to order the list, and prioritize remote branchesPersonally, I think the first one is safer, but I've not yet played with this plugin.h2. How to reproduce# Create a new repository and initialize it (on github, with a README.md for example)# Clone it on your computer: {noformat} git clone https://lausivoiduts.visualstudio.com/QuarahMC/_git/JENKINS-37263 ; cd JENKINS-37263 {noformat} # Create a new branch: git checkout -b features/this-bug# Add something in the Jenkinsfile: echo "echo 'first commit' " > Jenkinsfile# Commit and push it: git add Jenkinfile ; git commit -m "first commit" ; git push --set-upstream origin features/this-bug# Add a new Multibranch Pipeline Project in Jenkins, add as Source your git repository. Click on "Add Behaviour", select "Checkout to a local branch". Set its value to "**" (without the quotes). Validate it.# Check that the branch was built, and the message "first commit" appears in the log# Modify
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project configured with the local branch extension and many branch following the git flow model (features/). When I push a commit on the feature branch, this commit is detected by Jenkins, and pulled by the master to read the Jenkinsfile. The first time it works, but after that, the local branch is selected instead of the remote branch, amd the new commits are not fetch. The bug only occurs on branches with a slash in their names.h2. InvestigationI've connected my debugger to my Jenkins installation. !jenkins-local-branch-bug-1.PNG|thumbnail! It appears that Jenkins has detected 2 branches matching the name. One local and one remote. The local one is created by the local branch git extension.I can't explicitly specify to Jenkins to use the remote one because I use the pipeline plugin, and this checkout is made automatically to retrieve the Jenkinsfile. So, the git implementation takes the first one, which is generally the local branch which is not yet updated...{code:java}Revision marked = candidates.iterator().next();{code}h2. Logs{noformat}16:10:31 Multiple candidate revisions16:10:31 Checking out Revision 604398f062b459c797f31d6c13b568dd7612362d (features/my-feature-branch)16:10:31 > git.exe config core.sparsecheckout # timeout=3016:10:31 > git.exe checkout -f 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe branch -a -v --no-abbrev # timeout=3016:10:32 > git.exe branch -D features/my-feature-branch # timeout=3016:10:32 > git.exe checkout -b features/my-feature-branch 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30{noformat}h2. How to fix itPossibilities I see : * Update the workflow-multibranch-plugin to checkout on origin (prefix with refs/remotes/origin/) * Update the git-plugin to order the list, and prioritize remote branchesPersonally, I think the first one is safer, but I've not yet played with this plugin.h2. How to reproduce I # Create a new repository and initialize it (on github, with a README.md for example)# Clone it on your computer: git clone https://lausivoiduts.visualstudio.com/QuarahMC/_git/JENKINS-37263 ; cd JENKINS-37263# Create a new branch: git checkout -b features/this-bug# Add something in the Jenkinsfile: echo "echo ' first commit' " > Jenkinsfile# Commit and push it: git add Jenkinfile ; git commit - m working "first commit" ; git push --set-upstream origin features/this-bug# Add a new Multibranch Pipeline Project in Jenkins, add as Source your git repository. Click on an easy "Add Behaviour", select "Checkout to reproduce example a local branch" . I Set its value to "**" (without the quotes). Validate it.# Check that the branch was built, and the message "first commit"
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch extension on a branch with a /
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / Change By: Quentin Dufour Summary: Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project configured with the local branch extension and many branch following the git flow model (features/) . Sometimes, when When I push a commit (ex: b) on the feature branch , this commit is detected by Jenkins, and pull pulled by the master to read the Jenkinsfile. After The first time it works, but after that, the slave has to pull local branch is selected instead of the repository (using checkout scm) remote branch , but sometimes it checkout to amd the wrong commit (previous one, let's say a instead of b) new commits are not fetch . The bug only occurs on branches with a slash in their names. h2. InvestigationI've connected my debugger to my Jenkins installation. !jenkins-local-branch-bug-1.PNG|thumbnail! It appears that Jenkins has detected 2 branches matching the name. One local and one remote. The local one is created by the local branch git extension.I can't explicitly specify to Jenkins to use the remote one because I use the pipeline plugin, and this checkout is made automatically to retrieve the Jenkinsfile. So, the git implementation takes the first one, which is generally the local branch which is not yet updated...{code:java}Revision marked = candidates.iterator().next();{code}h2. Logs{noformat}16:10:31 Multiple candidate revisions16:10:31 Checking out Revision 604398f062b459c797f31d6c13b568dd7612362d (features/my-feature-branch)16:10:31 > git.exe config core.sparsecheckout # timeout=3016:10:31 > git.exe checkout -f 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe branch -a -v --no-abbrev # timeout=3016:10:32 > git.exe branch -D features/my-feature-branch # timeout=3016:10:32 > git.exe checkout -b features/my-feature-branch 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30{noformat}h2. How to fix itPossibilities I see : * Update the workflow-multibranch-plugin to checkout on origin (prefix with refs/remotes/origin/) * Update the git-plugin to order the list, and prioritize remote branchesPersonally, I think the first one is safer, but I've not yet played with this plugin.h2. How to reproduceI'm working on an easy to reproduce example. I'll update this post when I've found it.
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash)
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash) Change By: Quentin Dufour Summary: Jenkins checkout the wrong commit when used with the local branch extension on a branch with a / (slash) Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) Jenkins checkout the wrong commit when used with the local branch extension
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 Jenkins checkout the wrong commit when used with the local branch extension Change By: Quentin Dufour Summary: Jenkins checkout to the wrong commit when used with the local branch extension Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
checkout to the wrong commit when used with local branch
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project configured with the local branch extension . Sometimes, when I push a commit (ex: b), this commit is detected by Jenkins, and pull by the master to read the Jenkinsfile. After that, the slave has to pull the repository (using checkout scm), but sometimes it checkout to the wrong commit (previous one, let's say a instead of b).h2. InvestigationI've connected my debugger to my Jenkins installation. !jenkins-local-branch-bug-1.PNG|thumbnail! It appears that Jenkins has detected 2 branches matching the name. One local and one remote. The local one is created by the local branch git extension. I can't explicitly specify to Jenkins to use the re remote one because I use the pipeline plugin, and this checkout is made automatically to retrieve the Jenkinsfile. So, the git implementation takes the first one, which is generally the local branch which is not yet updated... {code:java}Revision marked = candidates.iterator().next();{code} h2. Logs{noformat}16:10:31 Multiple candidate revisions16:10:31 Checking out Revision 604398f062b459c797f31d6c13b568dd7612362d (features/my-feature-branch)16:10:31 > git.exe config core.sparsecheckout # timeout=3016:10:31 > git.exe checkout -f 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe branch -a -v --no-abbrev # timeout=3016:10:32 > git.exe branch -D features/my-feature-branch # timeout=3016:10:32 > git.exe checkout -b features/my-feature-branch 604398f062b459c797f31d6c13b568dd7612362d # timeout=12016:10:32 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30{noformat} h2. How to reproduce fix it Possibilities I see : * Update the workflow - multibranch - Not plugin to checkout on origin (prefix with refs/remotes/origin/) * Update the git-plugin to order the list, and prioritize remote branchesPersonally, I think the first one is safer, but I've not yet found a way played with this plugin.h2. How to easily reproduce I'm working on an easy to reproduce example. I'll update this post when I've found it -- .
Add
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 checkout to the wrong commit when used with local branch Change By: Quentin Dufour Component/s: workflow-multibranch-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
checkout to the wrong commit when used with local branch
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project. Sometimes, when I push a commit (ex: b), this commit is detected by Jenkins, and pull by the master to read the Jenkinsfile. After that, the slave has to pull the repository (using checkout scm), but sometimes it checkout to the wrong commit (previous one, let's say a instead of b).h2. Jenkinsfile Investigation {code:java}node( I ' build') { checkout scm}{code} h2. Logs{noformat}Started by user anonymousSetting origin to https:// ve connected my -server.com/repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=30Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=30Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=30Resetting working tree > git.exe reset --hard # timeout=30 > git.exe clean -fdx # timeout=30Fetching upstream changes from https://my-server.com/repo.git > git.exe --version # timeout=30using .gitcredentials debugger to set credentials > git.exe config --local credential.username MyUsername # timeout=30 > git.exe config --local credential.helper store --file=\"C:\Users\Someone\AppData\Local\Temp\git3518615989109492530.credentials\" # timeout=30 > git.exe -c core.askpass=true fetch --tags --progress https:// my -server Jenkins installation . com/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=120 > git.exe config !jenkins - - local - -remove-section credential # timeout=30 > git.exe rev-parse "features/my-feature- branch ^{commit}" # timeout=30 > git.exe rev - parse "refs/remotes/origin/features/my bug - feature-branch^{commit}" # timeout=30Checking out Revision 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d (features/my-feature-branch) > git 1 . exe config core.sparsecheckout # timeout=30 PNG|thumbnail!> git.exe checkout -f 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe branch -a -v --no-abbrev # timeout=30 > git.exe branch -D features/my-feature-branch # timeout=30 > git.exe checkout -b features/my-feature-branch 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30[Pipeline] timestamps[Pipeline] {[Pipeline] stage (Commit)16:10:21 Entering stage Commit16:10:21 Proceeding[Pipeline] node16:10:21 Running on commit02 in D:\agent\workspace\b\076b57f2[Pipeline] {[Pipeline] ws16:10:21 Running in D:\agent\build[Pipeline] {[Pipeline] checkout16:10:27 > git.exe rev-parse --is-inside-work-tree # timeout=3016:10:28 Fetching changes from It appears that Jenkins has detected 2 branches matching the remote Git repository16:10:28 > git name . exe config One local and one remote. origin.url https://my-server.com/repo.git # timeout=30 16:10:28 Cleaning workspace16:10:28 > git.exe rev-parse --verify HEAD # timeout=3016:10:28 Resetting
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 checkout to the wrong commit when used with local branch Change By: Quentin Dufour Attachment: jenkins-local-branch-bug-1.PNG Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
checkout to the wrong commit when used with local branch
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project. Sometimes, when I push a commit (ex: b), this commit is detected by Jenkins, and pull by the master to read the Jenkinsfile. After that, the slave has to pull the repository (using checkout scm), but sometimes it checkout to the wrong commit (previous one, let's say a instead of b).h2. Jenkinsfile{code:java}node('build') { checkout scm}{code} h2. Logs{noformat}Started by user anonymousSetting origin to https://my-server.com/repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=30Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=30Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=30Resetting working tree > git.exe reset --hard # timeout=30 > git.exe clean -fdx # timeout=30Fetching upstream changes from https://my-server.com/repo.git > git.exe --version # timeout=30using .gitcredentials to set credentials > git.exe config --local credential.username MyUsername # timeout=30 > git.exe config --local credential.helper store --file=\"C:\Users\Someone\AppData\Local\Temp\git3518615989109492530.credentials\" # timeout=30 > git.exe -c core.askpass=true fetch --tags --progress https://my-server.com/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=120 > git.exe config --local --remove-section credential # timeout=30 > git.exe rev-parse "features/my-feature-branch^{commit}" # timeout=30 > git.exe rev-parse "refs/remotes/origin/features/my-feature-branch^{commit}" # timeout=30Checking out Revision 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d (features/my-feature-branch) > git.exe config core.sparsecheckout # timeout=30 > git.exe checkout -f 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe branch -a -v --no-abbrev # timeout=30 > git.exe branch -D features/my-feature-branch # timeout=30 > git.exe checkout -b features/my-feature-branch 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30[Pipeline] timestamps[Pipeline] {[Pipeline] stage (Commit)16:10:21 Entering stage Commit16:10:21 Proceeding[Pipeline] node16:10:21 Running on commit02 in D:\agent\workspace\b\076b57f2[Pipeline] {[Pipeline] ws16:10:21 Running in D:\agent\build[Pipeline] {[Pipeline] checkout16:10:27 > git.exe rev-parse --is-inside-work-tree # timeout=3016:10:28 Fetching changes from the remote Git repository16:10:28 > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=3016:10:28 Cleaning workspace16:10:28 > git.exe rev-parse --verify HEAD # timeout=3016:10:28 Resetting working tree16:10:28 > git.exe reset --hard # timeout=3016:10:28 > git.exe clean -fdx # timeout=3016:10:28 Fetching upstream changes from https://my-server.com/repo.git16:10:28 > git.exe --version #
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 checkout to the wrong commit when used with local branch Change By: Quentin Dufour Labels: git multibranch Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 checkout to the wrong commit when used with local branch Change By: Quentin Dufour Component/s: git-plugin Component/s: workflow-multibranch-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) checkout to the wrong commit when used with local branch
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37263 checkout to the wrong commit when used with local branch Change By: Quentin Dufour Summary: " checkout scm" retrieves to the wrong commit on the slave when used with local branch Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37263) "checkout scm" retrieves the wrong commit on the slave
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
"checkout scm" retrieves the wrong commit on the slave
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project. Sometimes, when I push a commit (ex: b), this commit is detected by Jenkins, and pull by the master to read the Jenkinsfile. After that, the slave has to pull the repository (using checkout scm), but sometimes it checkout to the wrong commit (previous one, let's say a instead of b).h2. Jenkinsfile{code:java}node('build') { checkout scm}{code} h2. Logs{noformat}Started by user anonymousSetting origin to https://my-server.com/repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=30Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=30Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=30Resetting working tree > git.exe reset --hard # timeout=30 > git.exe clean -fdx # timeout=30Fetching upstream changes from https://my-server.com/repo.git > git.exe --version # timeout=30using .gitcredentials to set credentials > git.exe config --local credential.username MyUsername # timeout=30 > git.exe config --local credential.helper store --file=\"C:\Users\Someone\AppData\Local\Temp\git3518615989109492530.credentials\" # timeout=30 > git.exe -c core.askpass=true fetch --tags --progress https://my-server.com/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=120 > git.exe config --local --remove-section credential # timeout=30 > git.exe rev-parse "features/my-feature-branch^{commit}" # timeout=30 > git.exe rev-parse "refs/remotes/origin/features/my-feature-branch^{commit}" # timeout=30Checking out Revision 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d (features/my-feature-branch) > git.exe config core.sparsecheckout # timeout=30 > git.exe checkout -f 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe branch -a -v --no-abbrev # timeout=30 > git.exe branch -D features/my-feature-branch # timeout=30 > git.exe checkout -b features/my-feature-branch 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30[Pipeline] timestamps[Pipeline] {[Pipeline] stage (Commit)16:10:21 Entering stage Commit16:10:21 Proceeding[Pipeline] node16:10:21 Running on commit02 in D:\agent\workspace\b\076b57f2[Pipeline] {[Pipeline] ws16:10:21 Running in D:\agent\build[Pipeline] {[Pipeline] checkout16:10:27 > git.exe rev-parse --is-inside-work-tree # timeout=3016:10:28 Fetching changes from the remote Git repository16:10:28 > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=3016:10:28 Cleaning workspace16:10:28 > git.exe rev-parse --verify HEAD # timeout=3016:10:28 Resetting working tree16:10:28 > git.exe reset --hard # timeout=3016:10:28 > git.exe clean -fdx # timeout=3016:10:28 Fetching upstream changes from https://my-server.com/repo.git16:10:28 > git.exe --version #
[JIRA] (JENKINS-37263) "checkout scm" retrieves the wrong commit on the slave
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
"checkout scm" retrieves the wrong commit on the slave
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project. Sometimes, when I push a commit (ex: b), this commit is detected by Jenkins, and pull by the master to read the Jenkinsfile. After that, the slave has to pull the repository (using checkout scm), but sometimes it checkout to the wrong commit (previous one, let's say a instead of b).h2. Jenkinsfile{code:java}node('build') { checkout scm}{code} h2. Logs{noformat}Started by user anonymousSetting origin to https://my-server.com/repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=30Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=30Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=30Resetting working tree > git.exe reset --hard # timeout=30 > git.exe clean -fdx # timeout=30Fetching upstream changes from https://my-server.com/repo.git > git.exe --version # timeout=30using .gitcredentials to set credentials > git.exe config --local credential.username MyUsername # timeout=30 > git.exe config --local credential.helper store --file=\"C:\Users\Someone\AppData\Local\Temp\git3518615989109492530.credentials\" # timeout=30 > git.exe -c core.askpass=true fetch --tags --progress https://my-server.com/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=120 > git.exe config --local --remove-section credential # timeout=30 > git.exe rev-parse "features/my-feature-branch^{commit}" # timeout=30 > git.exe rev-parse "refs/remotes/origin/features/my-feature-branch^{commit}" # timeout=30Checking out Revision 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d (features/my-feature-branch) > git.exe config core.sparsecheckout # timeout=30 > git.exe checkout -f 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe branch -a -v --no-abbrev # timeout=30 > git.exe branch -D features/my-feature-branch # timeout=30 > git.exe checkout -b features/my-feature-branch 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30[Pipeline] timestamps[Pipeline] {[Pipeline] stage (Commit)16:10:21 Entering stage Commit16:10:21 Proceeding[Pipeline] node16:10:21 Running on commit02 in D:\agent\workspace\b\076b57f2[Pipeline] {[Pipeline] ws16:10:21 Running in D:\agent\build[Pipeline] {[Pipeline] checkout16:10:27 > git.exe rev-parse --is-inside-work-tree # timeout=3016:10:28 Fetching changes from the remote Git repository16:10:28 > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=3016:10:28 Cleaning workspace16:10:28 > git.exe rev-parse --verify HEAD # timeout=3016:10:28 Resetting working tree16:10:28 > git.exe reset --hard # timeout=3016:10:28 > git.exe clean -fdx # timeout=3016:10:28 Fetching upstream changes from https://my-server.com/repo.git16:10:28 > git.exe --version #
[JIRA] (JENKINS-37263) "checkout scm" retrieves the wrong commit on the slave
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37263
"checkout scm" retrieves the wrong commit on the slave
Change By:
Quentin Dufour
h2. Description of the problemI've a multibranch pipeline project. Sometimes, when I push a commit (ex: b), this commit is detected by Jenkins, and pull by the master to read the Jenkinsfile. After that, the slave has to pull the repository (using checkout scm), but sometimes it checkout to the wrong commit (previous one, let's say a instead of b).h2. Jenkinsfile{code:java}node('build') { checkout scm}{code} h2. Logs{noformat}Started by user anonymousSetting origin to https://my-server.com/repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=30Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=30Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=30Resetting working tree > git.exe reset --hard # timeout=30 > git.exe clean -fdx # timeout=30Fetching upstream changes from https://my-server.com/repo.git > git.exe --version # timeout=30using .gitcredentials to set credentials > git.exe config --local credential.username MyUsername # timeout=30 > git.exe config --local credential.helper store --file=\"C:\Users\Someone\AppData\Local\Temp\git3518615989109492530.credentials\" # timeout=30 > git.exe -c core.askpass=true fetch --tags --progress https://my-server.com/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=120 > git.exe config --local --remove-section credential # timeout=30 > git.exe rev-parse "features/my-feature-branch^{commit}" # timeout=30 > git.exe rev-parse "refs/remotes/origin/features/my-feature-branch^{commit}" # timeout=30Checking out Revision 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d (features/my-feature-branch) > git.exe config core.sparsecheckout # timeout=30 > git.exe checkout -f 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe branch -a -v --no-abbrev # timeout=30 > git.exe branch -D features/my-feature-branch # timeout=30 > git.exe checkout -b features/my-feature-branch 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=120 > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30[Pipeline] timestamps[Pipeline] {[Pipeline] stage (Commit)16:10:21 Entering stage Commit16:10:21 Proceeding[Pipeline] node16:10:21 Running on commit02 in D:\agent\workspace\b\076b57f2[Pipeline] {[Pipeline] ws16:10:21 Running in D:\agent\build[Pipeline] {[Pipeline] checkout16:10:27 > git.exe rev-parse --is-inside-work-tree # timeout=3016:10:28 Fetching changes from the remote Git repository16:10:28 > git.exe config remote.origin.url https://my-server.com/repo.git # timeout=3016:10:28 Cleaning workspace16:10:28 > git.exe rev-parse --verify HEAD # timeout=3016:10:28 Resetting working tree16:10:28 > git.exe reset --hard # timeout=3016:10:28 > git.exe clean -fdx # timeout=3016:10:28 Fetching upstream changes from https://my-server.com/repo.git16:10:28 > git.exe --version #
[JIRA] (JENKINS-37263) "checkout scm" retrieves the wrong commit on the slave
Title: Message Title
Quentin Dufour created an issue
Jenkins / JENKINS-37263
"checkout scm" retrieves the wrong commit on the slave
Issue Type:
Bug
Assignee:
Manuel Recena Soto
Components:
workflow-multibranch-plugin
Created:
2016/Aug/08 8:31 PM
Environment:
Jenkins 2.16 Windows Server 2012 R2
Labels:
git multibranch
Priority:
Minor
Reporter:
Quentin Dufour
Description of the problem I've a multibranch pipeline project. Sometimes, when I push a commit (ex: b), this commit is detected by Jenkins, and pull by the master to read the Jenkinsfile. After that, the slave has to pull the repository (using checkout scm), but sometimes it checkout to the wrong commit (previous one, let's say a instead of b). Jenkinsfile
node('build') {
checkout scm
}
Logs
Started by user anonymous
Setting origin to https://my-server.com/repo.git
Fetching origin...
> git.exe rev-parse --is-inside-work-tree # timeout=30
Fetching changes from the remote Git repository
> git.exe config remote.origin.url https://my-server.com/repo.git # timeout=30
Cleaning workspace
> git.exe rev-parse --verify
[JIRA] (JENKINS-27008) hudson.util.HudsonFailedToLoad: org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException
Title: Message Title Quentin Dufour edited a comment on JENKINS-27008 Re: hudson.util.HudsonFailedToLoad: org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException If you find this I've found issue during a while searching this error on Google Search .As this issue is referenced in search engines , I'm updating it .It might be because you're trying to run a very old Jenkins version with Java 8.I had this error while editing the git-client-plugin, which use Jenkins 1.532.2.I switched from JDK 1.8 to JDK 1.7 in Netbeans, and the error was fixed. But keep in mind that, indeed a stack trace is not enough. It could be an other error. Hope it will be useful to someone... Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27008) hudson.util.HudsonFailedToLoad: org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException
Title: Message Title Quentin Dufour commented on JENKINS-27008 Re: hudson.util.HudsonFailedToLoad: org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException If you find this issue during a Google Search, it might be because you're trying to run a very old Jenkins version with Java 8. I had this error while editing the git-client-plugin, which use Jenkins 1.532.2. I switched from JDK 1.8 to JDK 1.7 in Netbeans, and the error was fixed. Hope it will be useful to someone... Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37185) Checkout timeout is not honored when used with local branch parameter
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37185 Checkout timeout is not honored when used with local branch parameter Change By: Quentin Dufour *Expectation:* When I set the checkout timeout, I'm expecting that Jenkins uses it when it comes to checkout a commit.*Problem:* However, it appears that when you select the "Check out to a specific local branch", the first checkout command does not set correctly the timeout.*Why it's a problem:* I'm using git lfs, and git lfs files are downloaded during the checkout option. For other reasons I can't use the git lfs pull command. Especially during the first checkout command.*How to reproduce it:* Use any version of git-plugin and git-client-plugin. Create a freestyle project, add the following parameters: Timeout=120 for Advanced checkout option, and Checkout to a specific local branch. Build the project. The first checkout will be displayed with a timeout of 10 instead of 120. _I've a Here is my proposition to fix this error: https://github . Not yet linked because I need the JIRA id before_ com/jenkinsci/git-client-plugin/pull/214 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37185) Checkout timeout is not honored when used with local branch parameter
Title: Message Title Quentin Dufour created an issue Jenkins / JENKINS-37185 Checkout timeout is not honored when used with local branch parameter Issue Type: Bug Assignee: Quentin Dufour Components: git-client-plugin Created: 2016/Aug/04 5:33 PM Priority: Minor Reporter: Quentin Dufour Expectation: When I set the checkout timeout, I'm expecting that Jenkins uses it when it comes to checkout a commit. Problem: However, it appears that when you select the "Check out to a specific local branch", the first checkout command does not set correctly the timeout. Why it's a problem: I'm using git lfs, and git lfs files are downloaded during the checkout option. For other reasons I can't use the git lfs pull command. Especially during the first checkout command. How to reproduce it: Use any version of git-plugin and git-client-plugin. Create a freestyle project, add the following parameters: Timeout=120 for Advanced checkout option, and Checkout to a specific local branch. Build the project. The first checkout will be displayed with a timeout of 10 instead of 120. I've a fix. Not yet linked because I need the JIRA id before Add Comment
[JIRA] (JENKINS-34230) Display the reason when branch indexing fails
Title: Message Title Quentin Dufour commented on JENKINS-34230 Re: Display the reason when branch indexing fails You'll probably have more information in the file named "jenkins.err.log" I believe that by default this file is located in your jenkins home folder. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37037) When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37037
When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Change By:
Quentin Dufour
*Description*When git checkout crash (for example, due to a timeout) before the Jenkinsfile execution, the internal multibranch workspace is broken. Indeed, git add .lock files in its repository when it runs. If git crash, these files are not removed. When you try to restart the build, it will fails because git finds a .lock file and think another git operation is running.*Workaround*You have to manually remove the workspace of your branch in the Jenkins Home (or at least the .lock files)*Logs*Here is the git crash caused by a timeout (probably a problem with my internet connection).{noformat}Started by user anonymousSetting origin to https://my.server.com/my-repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=10Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my.server.com/my-repo.git # timeout=10Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10Fetching upstream changes from https://my.server.com/my-repo.git > git.exe --version # timeout=10using GIT_ASKPASS to set credentials vsts > git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1 # timeout=120ERROR: Timeout after 120 minutesERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://my.server.com/my-repo.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:85) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:206) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404)Caused by: hudson.plugins.git.GitException: Command "git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1" returned status code -1:stdout: stderr: Fatal: InvalidOperationException encountered.remote: Microsoft (R) Visual Studio (R) Team Servicesremote: remote: Found 459 objects to send.remote: Found 5449 objects to send. (14062 ms)Receiving objects: 0% (1/5449) Receiving objects: 1% (55/5449) Receiving objects: 2% (109/5449) Receiving objects: 3% (164/5449) Receiving objects: 4% (218/5449) Receiving objects: 5% (273/5449) Receiving objects: 6% (327/5449) Receiving objects: 7% (382/5449) Receiving objects: 8%
[JIRA] (JENKINS-37037) When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37037
When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Change By:
Quentin Dufour
*Description*When git checkout crash (for example, due to a timeout) before the Jenkinsfile execution, the internal multibranch workspace is broken. Indeed, git add .lock files in its repository when it runs. If git crash, these files are not removed. When you try to restart the build, it will fails because git finds a .lock file and think another git operation is running.*Workaround*You have to manually remove the workspace of your branch in the Jenkins Home (or at least the .lock files)*Logs*Here is the git crash caused by a timeout (probably a problem with my internet connection).{noformat}Started by user anonymousSetting origin to https://my.server.com/my-repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=10Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my.server.com/my-repo.git # timeout=10Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10Fetching upstream changes from https://my.server.com/my-repo.git > git.exe --version # timeout=10using GIT_ASKPASS to set credentials vsts > git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1 # timeout=120ERROR: Timeout after 120 minutesERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://my.server.com/my-repo.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:85) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:206) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404)Caused by: hudson.plugins.git.GitException: Command "git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1" returned status code -1:stdout: stderr: Fatal: InvalidOperationException encountered.remote: Microsoft (R) Visual Studio (R) Team Servicesremote: remote: Found 459 objects to send.remote: Found 5449 objects to send. (14062 ms)Receiving objects: 0% (1/5449) Receiving objects: 1% (55/5449) Receiving objects: 2% (109/5449) Receiving objects: 3% (164/5449) Receiving objects: 4% (218/5449) Receiving objects: 5% (273/5449) Receiving objects: 6% (327/5449) Receiving objects: 7% (382/5449) Receiving objects: 8%
[JIRA] (JENKINS-37037) When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37037
When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Change By:
Quentin Dufour
*Description*When git checkout crash (for example, due to a timeout) before the Jenkinsfile execution, the internal multibranch workspace is broken. Indeed, git add .lock files in its repository when it runs. If git crash, these files are not removed. When you try to restart the build, it will fails because git finds a .lock file and think another git operation is running.*Workaround*You have to manually remove the workspace of your branch in the Jenkins Home (or at least the .lock files)*Logs*Here is the git crash caused by a timeout (probably a problem with my internet connection).{noformat}Started by user anonymousSetting origin to https://my.server.com/my-repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=10Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my.server.com/my-repo.git # timeout=10Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10Fetching upstream changes from https://my.server.com/my-repo.git > git.exe --version # timeout=10using GIT_ASKPASS to set credentials vsts > git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1 # timeout=120ERROR: Timeout after 120 minutesERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://my.server.com/my-repo.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:85) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:206) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404)Caused by: hudson.plugins.git.GitException: Command "git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1" returned status code -1:stdout: stderr: Fatal: InvalidOperationException encountered.remote: Microsoft (R) Visual Studio (R) Team Servicesremote: remote: Found 459 objects to send.remote: Found 5449 objects to send. (14062 ms)Receiving objects: 0% (1/5449) Receiving objects: 1% (55/5449) Receiving objects: 2% (109/5449) Receiving objects: 3% (164/5449) Receiving objects: 4% (218/5449) Receiving objects: 5% (273/5449) Receiving objects: 6% (327/5449) Receiving objects: 7% (382/5449) Receiving objects: 8%
[JIRA] (JENKINS-37037) When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-37037 When git fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken Change By: Quentin Dufour Summary: When git checkout fetch crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37037) When git checkout crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-37037
When git checkout crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Change By:
Quentin Dufour
*Description*When git checkout crash (for example, due to a timeout) before the Jenkinsfile execution, the internal multibranch workspace is broken. Indeed, git add .lock files in its repository when it runs. If git crash, these files are not removed. When you try to restart the build, it will fails because git finds a .lock file and think another git operation is running.*Workaround*You have to manually remove the workspace of your branch in the Jenkins Home (or at least the .lock files)*Logs*Here is the git crash caused by a timeout (probably a problem with my internet connection).{noformat}Started by user anonymousSetting origin to https://my.server.com/my-repo.gitFetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=10Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my.server.com/my-repo.git # timeout=10Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10Fetching upstream changes from https://my.server.com/my-repo.git > git.exe --version # timeout=10using GIT_ASKPASS to set credentials vsts > git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1 # timeout=120ERROR: Timeout after 120 minutesERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://my.server.com/my-repo.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:85) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:206) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404)Caused by: hudson.plugins.git.GitException: Command "git.exe fetch --tags --progress https://my.server.com/my-repo.git +refs/heads/*:refs/remotes/origin/* --depth=1" returned status code -1:stdout: stderr: Fatal: InvalidOperationException encountered.remote: Microsoft (R) Visual Studio (R) Team Servicesremote: remote: Found 459 objects to send.remote: Found 5449 objects to send. (14062 ms)Receiving objects: 0% (1/5449) Receiving objects: 1% (55/5449) Receiving objects: 2% (109/5449) Receiving objects: 3% (164/5449) Receiving objects: 4% (218/5449) Receiving objects: 5% (273/5449) Receiving objects: 6% (327/5449) Receiving objects: 7% (382/5449) Receiving objects: 8%
[JIRA] (JENKINS-37037) When git checkout crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken
Title: Message Title Quentin Dufour created an issue Jenkins / JENKINS-37037 When git checkout crash or timeout before the Jenkinsfile execution, the internal multibranch workspace is broken Issue Type: Bug Assignee: Manuel Recena Soto Components: workflow-multibranch-plugin Created: 2016/Jul/28 1:44 PM Environment: Jenkins 2.14 Windows Server 2012 R2 workflow-multibranch-plugin 2.8 Labels: timeout git Priority: Minor Reporter: Quentin Dufour Description When git checkout crash (for example, due to a timeout) before the Jenkinsfile execution, the internal multibranch workspace is broken. Indeed, git add .lock files in its repository when it runs. If git crash, these files are not removed. When you try to restart the build, it will fails because git finds a .lock file and think another git operation is running. Workaround You have to manually remove the workspace of your branch in the Jenkins Home (or at least the .lock files) Logs Here is the git crash caused by a timeout (probably a problem with my internet connection). Started by user anonymous Setting origin to https://my.server.com/my-repo.git Fetching origin... > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git.exe config remote.origin.url https://my.server.com/my-repo.git # timeout=10 Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10 Resetting
[JIRA] (JENKINS-22547) Git timeout setting does not work for checkout
Title: Message Title Quentin Dufour commented on JENKINS-22547 Re: Git timeout setting does not work for checkout After some investigation, I've fixed my problem by removing git lfs filters. Now, I'm manually calling "git lfs pull" in my build after the checkout step. Indeed, without git lfs this step is very fast and should not take too much time. But that's during this step that git lfs try to download its files. It might be the reason why you didn't need to set the timeout on this step during your development. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-22547) Git timeout setting does not work for checkout
Title: Message Title Quentin Dufour commented on JENKINS-22547 Re: Git timeout setting does not work for checkout Same problem as Mark Waite. I've set Checkout and Clone timeout to 120 minutes. It fails on the checkout command with timeout=10 I use Jenkins Pipeline with Jenkins 2.11 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-17212) Git clean broken on Windows
Title: Message Title Quentin Dufour commented on JENKINS-17212 Re: Git clean broken on Windows Just to confirm that I'm currently encountering the same problem with JGit on Windows (on build agent, Windows Server 2012 R2, a different file each time). Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-36044 A test (disallowed DOCTYPE) fails due to a localization error Change By: Quentin Dufour Priority: Major Minor Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36052) Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36052
Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Change By:
Quentin Dufour
I've tried to compile jenkinsci on my 32 bit Debian 9 server, and it failed because it can't build a link to download the correct node version. Indeed, there is no entry for Linux 32 bits.The error :{noformat}[WARNING] Could not get contentjava.lang.IllegalArgumentException: Illegal character in path at index 32: https://nodejs.org/dist/v4.0.0/${node.download.file}...[ERROR] Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error: Could not get content -> [Help 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error{noformat}You can find the full log here : http://dufour.tk/~quentin/logs/mvnlogs4.logI previously had the same problem for blueocean-plugin, as discussed in [this conversion on the mailing list|https://groups.google.com/forum/#!topic/jenkinsci-dev/lRTz19Yv1YY] and was solved by a [pull request on the plugin-pom repository|https://github.com/jenkinsci/plugin-pom/pull/28].I've read in the contributing guide, pull requests should be linked with an issue ID, which is why I'm creating this issue. You can find [the pull request on the github repository|https://github.com/jenkinsci/jenkins/pull/2414].As suggested by andresrc, it's also the opportunity to discuss about which architectures and OS should be supported for by jenkins during compilation. I'm thinking to arm for example. And maybe document that architecture limitation somewhere.I've also spotted 2 more files which are containing a dependency on node.js which should be updated if this pull request is accepted : * https://github.com/jenkinsci/js-builder/blob/master/res/sample_extract_pom.xml * https://github.com/jenkinsci/js-libs/blob/master/js-module-base/pom.xml
Add Comment
[JIRA] (JENKINS-36052) Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36052
Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Change By:
Quentin Dufour
I've tried to compile jenkinsci on my 32 bit Debian 9 server, and it failed because it can't build a link to download the correct node version. Indeed, there is no entry for Linux 32 bits.The error :{noformat}[ WARNING] Could not get contentjava.lang.IllegalArgumentException: Illegal character in path at index 32: https://nodejs.org/dist/v4.0.0/${node.download.file}...[ ERROR] Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error: Could not get content -> [Help 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error{noformat}You can find the full log here : http://dufour.tk/~quentin/logs/mvnlogs4.logI previously had the same problem for blueocean-plugin, as discussed in [this conversion on the mailing list|https://groups.google.com/forum/#!topic/jenkinsci-dev/lRTz19Yv1YY] and was solved by a [pull request on the plugin-pom repository|https://github.com/jenkinsci/plugin-pom/pull/28].I've read in the contributing guide, pull requests should be linked with an issue ID, which is why I'm creating this issue. You can find [the pull request on the github repository](https://github.com/jenkinsci/jenkins/pull/2414) As suggested by andresrc, it's also the opportunity to discuss about which architectures should be supported for jenkins compilation. I'm thinking to arm for example. And maybe document that architecture limitation somewhere.I've also spotted 2 more files which are containing a dependency on node.js which should be updated if this pull request is accepted : * https://github.com/jenkinsci/js-builder/blob/master/res/sample_extract_pom.xml * https://github.com/jenkinsci/js-libs/blob/master/js-module-base/pom.xml
Add Comment
[JIRA] (JENKINS-36052) Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36052
Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Change By:
Quentin Dufour
I've tried to compile jenkinsci on my 32 bit Debian 9 server, and it failed because it can't build a link to download the correct node version. Indeed, there is no entry for Linux 32 bits.The error :{noformat}[WARNING] Could not get contentjava.lang.IllegalArgumentException: Illegal character in path at index 32: https://nodejs.org/dist/v4.0.0/${node.download.file}...[ERROR] Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error: Could not get content -> [Help 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error{noformat}You can find the full log here : http://dufour.tk/~quentin/logs/mvnlogs4.logI previously had the same problem for blueocean-plugin, as discussed in [this conversion on the mailing list|https://groups.google.com/forum/#!topic/jenkinsci-dev/lRTz19Yv1YY] and was solved by a [pull request on the plugin-pom repository|https://github.com/jenkinsci/plugin-pom/pull/28].I've read in the contributing guide, pull requests should be linked with an issue ID, which is why I'm creating this issue. You can find [the pull request on the github repository ]( | https://github.com/jenkinsci/jenkins/pull/2414 ) ]. As suggested by andresrc, it's also the opportunity to discuss about which architectures should be supported for jenkins compilation. I'm thinking to arm for example. And maybe document that architecture limitation somewhere.I've also spotted 2 more files which are containing a dependency on node.js which should be updated if this pull request is accepted : * https://github.com/jenkinsci/js-builder/blob/master/res/sample_extract_pom.xml * https://github.com/jenkinsci/js-libs/blob/master/js-module-base/pom.xml
Add Comment
[JIRA] (JENKINS-36052) Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36052
Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Change By:
Quentin Dufour
I've tried to compile jenkinsci on my 32 bit Debian 9 server, and it failed because it can't build a link to download the correct node version. Indeed, there is no entry for Linux 32 bits.The error :{noformat}[ERROR] Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error: Could not get content -> [Help 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error{noformat}You can find the full log here : http://dufour.tk/~quentin/logs/mvnlogs4.logI previously had the same problem for blueocean-plugin, as discussed in [this conversion on the mailing list ]( | https://groups.google.com/forum/#!topic/jenkinsci-dev/lRTz19Yv1YY ) ] and was solved by a [pull request on the plugin-pom repository ]( | https://github.com/jenkinsci/plugin-pom/pull/28 ) ] .I've read in the contributing guide, pull requests should be linked with an issue ID, which is why I'm creating this issue. As suggested by andresrc, it's also the opportunity to discuss about which architectures should be supported for jenkins compilation. I'm thinking to arm for example. And maybe document that architecture limitation somewhere.I've also spotted 2 more files which are containing a dependency on node.js which should be updated if this pull request is accepted : * https://github.com/jenkinsci/js-builder/blob/master/res/sample_extract_pom.xml * https://github.com/jenkinsci/js-libs/blob/master/js-module-base/pom.xml
Add Comment
[JIRA] (JENKINS-36052) Add support for jenkins compilation on 32 bit linux (and other architectures ?)
Title: Message Title Quentin Dufour created an issue Jenkins / JENKINS-36052 Add support for jenkins compilation on 32 bit linux (and other architectures ?) Issue Type: Bug Assignee: Unassigned Components: core Created: 2016/Jun/17 11:06 PM Environment: Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 1.8.0_91, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-i386/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-1-686-pae", arch: "i386", family: "unix" Distribution: Debian 9 stretch/sid Priority: Minor Reporter: Quentin Dufour I've tried to compile jenkinsci on my 32 bit Debian 9 server, and it failed because it can't build a link to download the correct node version. Indeed, there is no entry for Linux 32 bits. The error : [ERROR] Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error: Could not get content -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (get-node) on project jenkins-war: IO Error You can find the full log here : http://dufour.tk/~quentin/logs/mvnlogs4.log I previously had the same problem for blueocean-plugin, as discussed in [this conversion on the mailing list](https://groups.google.com/forum/#!topic/jenkinsci-dev/lRTz19Yv1YY) and was solved by a [pull request on the plugin-pom
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36044
A test (disallowed DOCTYPE) fails due to a localization error
Change By:
Quentin Dufour
I 've just tried to compile jenkins on my machine and faced an error while running tests.I've followed the steps from this link : https://wiki.jenkins-ci.org/display/JENKINS/Building+JenkinsIt seems to be linked to my locale which is fr_FR.The error : {noformat}Expected: a string containing "DOCTYPE is disallowed" but: was "DOCTYPE n'est pas autorisé lorsque la fonctionnalité "http://apache.org/xml/features/disallow-doctype-decl" est définie sur True.".{noformat}Full log here : http://dufour.tk/~quentin/logs/mvnlogs3.logHow to reproduce ? Not sure but :* Install Debian 9 with fr_FR as default locale* Install openjdk-8-jdk, maven, git, etc* Follow steps from https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins (commit 8f7cad0659578cf6c4a786cc50da0f91173ea1b7)
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-36044 A test (disallowed DOCTYPE) fails due to a localization error Change By: Quentin Dufour Environment: Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 1.8.0_91 , vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-openjdk-i386/jre / Default locale: fr_FR / , platform encoding: UTF-8 / OS name: " linux ", version: "4.4.0-1-686-pae" , arch: "i386" , family: "unix" dsitribution Distribution : Debian 9 stretch/sid Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36044
A test (disallowed DOCTYPE) fails due to a localization error
Change By:
Quentin Dufour
{noformat}Apache Maven 3.3.9Maven home: /usr/share/mavenJava version: 1.8.0_91, vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-openjdk-i386/jreDefault locale: fr_FR, platform encoding: UTF-8OS name: "linux", version: "4.4.0-1-686-pae", arch: "i386", family: "unix"Distribution: Debian 9 stretch/sid{noformat} I just tried to compile jenkins on my machine and faced an error while running tests.I've followed the steps from this link : https://wiki.jenkins-ci.org/display/JENKINS/Building+JenkinsIt seems to be linked to my locale which is fr_FR.The error : {noformat}Expected: a string containing "DOCTYPE is disallowed" but: was "DOCTYPE n'est pas autorisé lorsque la fonctionnalité "http://apache.org/xml/features/disallow-doctype-decl" est définie sur True.".{noformat}Full log here : http://dufour.tk/~quentin/logs/mvnlogs3.logHow to reproduce ? Not sure but :* Install Debian 9 with fr_FR as default locale* Install openjdk-8-jdk, maven, git, etc* Follow steps from https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins (commit 8f7cad0659578cf6c4a786cc50da0f91173ea1b7)
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-36044 A test (disallowed DOCTYPE) fails due to a localization error Change By: Quentin Dufour Environment: Apache Maven 3.3.9 Maven home: / usr/share/maven Java version: 1.8.0_91 , vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-openjdk-i386/jre Default / locale: fr_FR , / platform encoding: UTF-8 OS name: " / linux ", version: "4.4.0-1-686-pae" , arch: "i386" , family: "unix" Distribution dsitribution : Debian 9 stretch/sid Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title Quentin Dufour updated an issue Jenkins / JENKINS-36044 A test (disallowed DOCTYPE) fails due to a localization error Change By: Quentin Dufour Environment: Maven 3.3.9 / Java 1.8.0_91 /usr/lib/jvm/java-8-openjdk-i386/jre / locale: fr_FR / platform encoding: UTF-8 / linux version: "4.4.0-1-686-pae" arch: "i386" family: "unix" dsitribution: Debian 9 stretch/sid Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36044
A test (disallowed DOCTYPE) fails due to a localization error
Change By:
Quentin Dufour
{noformat}Apache Maven 3.3.9Maven home: /usr/share/mavenJava version: 1.8.0_91, vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-openjdk-i386/jreDefault locale: fr_FR, platform encoding: UTF-8OS name: "linux", version: "4.4.0-1-686-pae", arch: "i386", family: "unix"Distribution: Debian 9 stretch/sid{noformat} I just tried to compile jenkins on my machine and faced an error while running tests.I've followed the steps from this link : https://wiki.jenkins-ci.org/display/JENKINS/Building+JenkinsIt seems to be linked to my locale which is fr_FR.The error : {noformat}Expected: a string containing "DOCTYPE is disallowed" but: was "DOCTYPE n'est pas autorisé lorsque la fonctionnalité "http://apache.org/xml/features/disallow-doctype-decl" est définie sur True.".{noformat}Full log here : http://dufour.tk/~quentin/logs/mvnlogs3.logHow to reproduce ? Not sure but :* Install Debian 9 with fr_FR as default locale* Install openjdk-8-jdk, maven, git, etc* Follow steps from https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins (commit 8f7cad0659578cf6c4a786cc50da0f91173ea1b7)
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36044
A test (disallowed DOCTYPE) fails due to a localization error
Change By:
Quentin Dufour
I just tried to compile jenkins on my machine and faced an error while running tests.I've followed the steps from this link : https://wiki.jenkins-ci.org/display/JENKINS/Building+JenkinsIt seems to be linked to my locale which is fr_FR.The error : { { noformat} Expected: a string containing "DOCTYPE is disallowed" but: was "DOCTYPE n'est pas autorisé lorsque la fonctionnalité "http://apache.org/xml/features/disallow-doctype-decl" est définie sur True.". {noformat } } Full log here : http://dufour.tk/~quentin/logs/mvnlogs3.logHow to reproduce ? Not sure but :* Install Debian 9 with fr_FR as default locale* Install openjdk-8-jdk, maven, git, etc* Follow steps from https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins (commit 8f7cad0659578cf6c4a786cc50da0f91173ea1b7)
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title
Quentin Dufour updated an issue
Jenkins / JENKINS-36044
A test (disallowed DOCTYPE) fails due to a localization error
Change By:
Quentin Dufour
I just tried to compile jenkins on my machine and faced an error while running tests.I've followed the steps from this link : https://wiki.jenkins-ci.org/display/JENKINS/Building+JenkinsIt seems to be linked to my locale which is fr_FR.The error : {{ Expected: a string containing "DOCTYPE is disallowed" but: was "DOCTYPE n'est pas autorisé lorsque la fonctionnalité "http://apache.org/xml/features/disallow-doctype-decl" est définie sur True.". }}Full log here : http://dufour.tk/~quentin/logs/mvnlogs3.logHow to reproduce ? Not sure but :* Install Debian 9 with fr_FR as default locale* Install openjdk-8-jdk, maven, git, etc* Follow steps from https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins (commit 8f7cad0659578cf6c4a786cc50da0f91173ea1b7)
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received
[JIRA] (JENKINS-36044) A test (disallowed DOCTYPE) fails due to a localization error
Title: Message Title
Quentin Dufour created an issue
Jenkins / JENKINS-36044
A test (disallowed DOCTYPE) fails due to a localization error
Issue Type:
Bug
Assignee:
Unassigned
Components:
core
Created:
2016/Jun/17 2:58 PM
Environment:
Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 1.8.0_91, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-i386/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-1-686-pae", arch: "i386", family: "unix" Distribution: Debian 9 stretch/sid
Labels:
test
Priority:
Major
Reporter:
Quentin Dufour
I just tried to compile jenkins on my machine and faced an error while running tests. I've followed the steps from this link : https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins It seems to be linked to my locale which is fr_FR. The error : {{Expected: a string containing "DOCTYPE is disallowed" but: was "DOCTYPE n'est pas autorisé lorsque la fonctionnalité "http://apache.org/xml/features/disallow-doctype-decl" est définie sur True.". }} Full log here : http://dufour.tk/~quentin/logs/mvnlogs3.log How to reproduce ? Not sure but :
Install Debian 9 with fr_FR as default locale
Install openjdk-8-jdk, maven, git, etc
Follow steps from https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins (commit
[JIRA] (JENKINS-33020) Unable to Trigger builds remotely (e.g., from scripts)
Title: Message Title Quentin Dufour edited a comment on JENKINS-33020 Re: Unable to Trigger builds remotely (e.g., from scripts) I've the same problem. I can check the box and enter a token, but when I click on save, this field is reset.I'm on Jenkins 2. 8 9 (and also had this problem on previous versions) .Seems to be the same bug as JENKINS-35310 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-33020) Unable to Trigger builds remotely (e.g., from scripts)
Title: Message Title Quentin Dufour commented on JENKINS-33020 Re: Unable to Trigger builds remotely (e.g., from scripts) I've the same problem. I can check the box and enter a token, but when I click on save, this field is reset. I'm on Jenkins 2.8. Seems to be the same bug as JENKINS-35310 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
