[JIRA] (JENKINS-61912) Clicking failure cause link on build page does not highlight location in console output
Title: Message Title Edgars Batna updated an issue Jenkins / JENKINS-61912 Clicking failure cause link on build page does not highlight location in console output Change By: Edgars Batna I'm using multibranch pipelines. I've set up a few global failure causes and they are indeed shown on the build page as needed. But, clicking the failure link just shows the console output, not the exact location inside the output.I remember using this plugin extensively in freestyle projects few years ago and clicking the links always opened the exact location in the console output, so this must be a regression. The "regression" is not new and has always been happening with multibranch pipelines for us (since 2017). I assumed it will get fixed eventually, but so far I can't even find a similar issue.I don't see any exceptions in the analyzer log.The plugin is kinda pointless for us, if it doesn't show the location in the log. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received
[JIRA] (JENKINS-61912) Clicking failure cause link on build page does not highlight location in console output
Title: Message Title Edgars Batna updated an issue Jenkins / JENKINS-61912 Clicking failure cause link on build page does not highlight location in console output Change By: Edgars Batna I'm using multibranch pipelines. I've set up a few global failure causes and they are indeed shown on the build page as needed. But, clicking the failure link just shows the console output, not the exact location inside the output.I remember using this plugin extensively in freestyle projects few years ago and clicking the links always opened the exact location in the console output, so this must be a regression. This The "regression" is not new and has always been happening with multibranch pipelines for us (since 2017) , . I assumed it will get fixed eventually, but so far I can't even find a similar issue.I don't see any exceptions in the analyzer log.The plugin is kinda pointless for us, if it doesn't show the location in the log. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You
[JIRA] (JENKINS-61912) Clicking failure cause link on build page does not highlight location in console output
Title: Message Title Edgars Batna updated an issue Jenkins / JENKINS-61912 Clicking failure cause link on build page does not highlight location in console output Change By: Edgars Batna I'm using multibranch pipelines. I've set up a few global failure causes and they are indeed shown on the build page as needed. But, clicking the failure link just shows the console output, not the exact location inside the output.I remember using this plugin extensively in freestyle projects few years ago and clicking the links always opened the exact location in the console output, so this must be a regression. This has always been happening with multibranch pipelines for us (since 2017), I assumed it will get fixed eventually, but so far I can't even find a similar issue.I don't see any exceptions in the analyzer log. The plugin is kinda pointless for us, if it doesn't show the location in the log. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are
[JIRA] (JENKINS-61912) Clicking failure cause link on build page does not highlight location in console output
Title: Message Title Edgars Batna created an issue Jenkins / JENKINS-61912 Clicking failure cause link on build page does not highlight location in console output Issue Type: Bug Assignee: Tomas Westling Components: build-failure-analyzer-plugin Created: 2020-04-15 10:31 Environment: Jenkins 2.230 Build Failure Analyzer 1.25.1 latest other plugins Labels: regression multi-branch jenkinsfile Priority: Major Reporter: Edgars Batna I'm using multibranch pipelines. I've set up a few global failure causes and they are indeed shown on the build page as needed. But, clicking the failure link just shows the console output, not the exact location inside the output. I remember using this plugin extensively in freestyle projects few years ago and clicking the links always opened the exact location in the console output, so this must be a regression. This has always been happening with multibranch pipelines for us (since 2017), I assumed it will get fixed eventually, but so far I can't even find a similar issue. I don't see any exceptions in the analyzer log.
[JIRA] (JENKINS-61147) load build parameters during repository scan
Title: Message Title Edgars Batna edited a comment on JENKINS-61147 Re: load build parameters during repository scan I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios.This is a missing important feature. I see it as a bug, because it 's no longer possible to use makes using expressions for default values impossible . Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204677.1582120134000.2219.1583137260532%40Atlassian.JIRA.
[JIRA] (JENKINS-61147) load build parameters during repository scan
Title: Message Title Edgars Batna edited a comment on JENKINS-61147 Re: load build parameters during repository scan I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios.This is a missing important feature . and I can even see it as a bug, because it makes using expressions for default values impossible. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204677.1582120134000.2221.1583137260595%40Atlassian.JIRA.
[JIRA] (JENKINS-61147) load build parameters during repository scan
Title: Message Title Edgars Batna edited a comment on JENKINS-61147 Re: load build parameters during repository scan I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios.This is a missing important feature. I see it as a bug, because it's no longer possible to use expressions for default values. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204677.1582120134000.2215.1583137200173%40Atlassian.JIRA.
[JIRA] (JENKINS-61147) load build parameters during repository scan
Title: Message Title Edgars Batna commented on JENKINS-61147 Re: load build parameters during repository scan I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios. This is a missing important feature. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204677.1582120134000.2212.1583136960164%40Atlassian.JIRA.
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Edgars Batna commented on JENKINS-58604 Re: Full Stage View only showing one The stage view should be redone, as it's too flaky and keeps breaking on simple things. I've seen suggestions to use Blue Ocean, but there is a crucial flaw with this: the Chuck Norris plugin does not support it. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200764.1563816065000.9544.1576563600681%40Atlassian.JIRA.
[JIRA] (JENKINS-58960) Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-58960
Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Change By:
Edgars Batna
I'm not sure if this is a problem in xUnit or pipeline multibranch plugin. Please reassign this as required.We've got a Multibranch Pipeline project and we upload various test results using the xUnit plugin. It's somewhat like this:{code:java}stage("Reachable stage") {if (some condition)return; // Skip all subsequent stages. This appears to cause the problem.}stage("Potentially failing or unreachable stage") {try{ // This might fail and abort consequent stages.}finally{ // We still want all tests and artifacts that we can get, but we only care for artifacts whose unit tests were executed.xunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'unittests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]archiveArtifacts artifacts: '...', defaultExcludes: falsexunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'boxtests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]}}stage("Potentially unreachable stage") {}{code}The trend chart shows up when builds fail with or without tests or succeed with tests, but the chart disappears when the build skips stages which record the tests. To be entirely honest, I'm not sure what the current behavior is exactly (it's inconsistent).This should be fixed. As long as there are test results in any builds at all, they should be displayed regardless of test results in the latest build.
Add Comment
[JIRA] (JENKINS-58960) Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-58960
Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Change By:
Edgars Batna
I'm not sure if this is a problem in xUnit plugin. Please reassign this as required.We've got a Multibranch Pipeline project and we upload various test results using the xUnit plugin. It's somewhat like this:{code:java}stage("Reachable stage") {if (some condition)return; // Skip all subsequent stages. This appears to cause the problem.}stage("Potentially failing or unreachable stage") {try{ // This might fail and abort consequent stages.}finally{ // We still want all tests and artifacts that we can get, but we only care for artifacts whose unit tests were executed.xunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'unittests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]archiveArtifacts artifacts: '...', defaultExcludes: falsexunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'boxtests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]}}stage("Potentially unreachable stage") {}{code}The trend chart shows up when builds fail with or without tests or succeed with tests, but the chart disappears when the build skips stages which record the tests. To be entirely honest, I'm not sure what the current behavior is exactly (it's inconsistent). This should be fixed. As long as there are test results in any builds at all, they should be displayed regardless of test results in the latest build.
Add Comment
[JIRA] (JENKINS-58960) Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Title: Message Title Edgars Batna updated an issue Jenkins / JENKINS-58960 Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results Change By: Edgars Batna Component/s: multi-branch-project-plugin (not Pipeline) Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201307.1565943725000.3803.1565943900285%40Atlassian.JIRA.
[JIRA] (JENKINS-58960) Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-58960
Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Change By:
Edgars Batna
I'm not sure if this is a problem in xUnit plugin. Please reassign this as required. We've got a Multibranch Pipeline project and we upload various test results using the xUnit plugin. It's somewhat like this:{code:java}stage("Reachable stage") {if (some condition)return; // Skip all subsequent stages. This appears to cause the problem.}stage("Potentially failing or unreachable stage") {try{ // This might fail and abort consequent stages.}finally{ // We still want all tests and artifacts that we can get, but we only care for artifacts whose unit tests were executed.xunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'unittests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]archiveArtifacts artifacts: '...', defaultExcludes: falsexunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'boxtests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]}}stage("Potentially unreachable stage") {}{code}The trend chart shows up when builds fail with or without tests or succeed with tests, but the chart disappears when the build skips stages which record the tests.This should be fixed. As long as there are test results in any builds at all, they should be displayed regardless of test results in the latest build.
Add Comment
[JIRA] (JENKINS-58960) Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-58960
Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Change By:
Edgars Batna
I'm not sure if this is a problem in xUnit plugin. We've got a Multibranch Pipeline project and we upload various test results using the xUnit plugin. It's somewhat like this:{code:java}stage("Reachable stage") {if (some condition)return; // Skip all subsequent stages. This appears to cause the problem.}stage("Potentially failing or unreachable stage") {try{ // This might fail and abort consequent stages.}finally{ // We still want all tests and artifacts that we can get, but we only care for artifacts whose unit tests were executed.xunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'unittests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]archiveArtifacts artifacts: '...', defaultExcludes: falsexunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'boxtests.xml', skipNoTestFiles: false, stopProcessingIfError: true)]}}stage("Potentially unreachable stage") {}{code}The trend chart shows up when builds fail with or without tests or succeed with tests, but the chart disappears when the build skips stages which record the tests.This should be fixed. As long as there are test results in any builds at all, they should be displayed regardless of test results in the latest build.
Add Comment
[JIRA] (JENKINS-58960) Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Title: Message Title
Edgars Batna created an issue
Jenkins / JENKINS-58960
Test Result Trend chart not showing on Multibranch Pipeline branch if last build has no test results
Issue Type:
Bug
Assignee:
Nikolas Falco
Components:
xunit-plugin
Created:
2019-08-16 08:22
Environment:
Windows Server Jenkins 2.189 Latest plugins
Labels:
test-statistics-graph
Priority:
Minor
Reporter:
Edgars Batna
I'm not sure if this a problem in xUnit plugin. We've got a Multibranch Pipeline project and we upload various test results using the xUnit plugin. It's somewhat like this:
stage("Reachable stage") {
if (some condition)
return; // Skip all subsequent stages. This appears to cause the problem.
}
stage("Potentially failing or unreachable stage") {
try
{
// This might fail and abort consequent stages.
}
finally
{ // We still want all tests and artifacts that we can get, but we only care for artifacts whose unit tests were executed.
xunit testTimeMargin: '2000', thresholdMode: 1, thresholds: [skipped(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0'), failed(failureNewThreshold: '0', failureThreshold: '0', unstableNewThreshold: '0', unstableThreshold: '0')], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'unittests.xml', skipNoTestFiles: false, stopProcessingIfError:
[JIRA] (JENKINS-35093) Moving a Build Job to a Folder results in Exception and loss of build history
Title: Message Title Edgars Batna commented on JENKINS-35093 Re: Moving a Build Job to a Folder results in Exception and loss of build history Just happened to a large job for us. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title Edgars Batna edited a comment on JENKINS-44930 Re: Allow sh to return exit status, stdout and stderr all at once This should also be implemented for Windows batch 'bat' step. Inability to return both status and stdout is a huge drawback for us. Separate stdout and stderr would be a plus.Once we want both it could just return a map instead of a value. This seems trivial to implement and won't break anything as returning both doesn't work already. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title Edgars Batna commented on JENKINS-44930 Re: Allow sh to return exit status, stdout and stderr all at once Inability to return both status and stdout is a huge drawback for us. Separate stdout and stderr would be a plus. Once we want both it could just return a map instead of a value. This seems trivial to implement and won't break anything as returning both doesn't work already. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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-927) List all changes since last successful build
Title: Message Title Edgars Batna commented on JENKINS-927 Re: List all changes since last successful build This should be looked at, as it's annoying and I've been implementing workarounds ever since. Creation of the changeset should be provided as a parametrized post-build thing that we could also use in pipeline. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title Edgars Batna commented on JENKINS-53201 Re: Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. I tried the workaround regarding additional credentials above and it helped: checkout changelog: false, scm: [$class: 'SubversionSCM', additionalCredentials: [[credentialsId: 'uuid', realm: '//subversion.server.com:443> VisualSVN Server']], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: scm.locations as java.util.List, quietOperation: true, workspaceUpdater: [$class: 'UpdateWithCleanUpdater']] What I don't really know is what credentials these are, as I've been adding credentials all over the place to make it work recently. I might update my comment once I find out. I also think I've tried this before, so possible some recent Jenkins update helped too? Was it perhaps the realm that was missing? The credentials realm thing in Jenkins is a thing I've never used before. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM.Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])])...checkout changelog: false, scm: [$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: scm.locations as java.util.List, quietOperation: true, workspaceUpdater: [$class: 'UpdateWithCleanUpdater']]...{code}Multibranch job is configured to *not* trigger when scanning. SCM trigger on main repo change works, bot trigger on an external with this repo does not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into Subversion Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs. The main repo and all external repos are on the same server, I can't see any problems with credential configuration either.This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There are similar issues like JENKINS-31869 and JENKINS-29079 but they are from a different version, years older and are about checkouts not polling .Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM.Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])])...checkout changelog: false, scm: [$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: scm.locations as java.util.List, quietOperation: true, workspaceUpdater: [$class: 'UpdateWithCleanUpdater']]...{code}Multibranch job is configured to *not* trigger when scanning. SCM trigger on main repo change works, bot trigger on an external with this repo does not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into Subversion Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs. The main repo and all external repos are on the same server, I can't see any problems with credential configuration either.This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There are similar issues like JENKINS-31869 and JENKINS-29079 but they , are from a different version, years older and are about checkouts not polling. I think some of the similar issues are long fixed. Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) at
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM.Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])])...checkout changelog: false, scm: [$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: scm.locations as java.util.List, quietOperation: true, workspaceUpdater: [$class: 'UpdateWithCleanUpdater']]...{code}Multibranch job is configured to *not* trigger when scanning. SCM trigger on main repo change works, bot trigger on an external with this repo does not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into Subversion Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs. The main repo and all external repos are on the same server, I can't see any problems with credential configuration either.This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There is a are similar issue like https:// issues .jenkins-ci.org/browse/ like JENKINS-31869 But that is a completely and JENKINS-29079 but they, different version and , years older and are about checkouts not polling . I think some of the similar issues are long fixed. Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM.Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])]) ...checkout changelog: false, scm: [$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: scm.locations as java.util.List, quietOperation: true, workspaceUpdater: [$class: 'UpdateWithCleanUpdater']]... {code}Multibranch job is configured to *not* trigger when scanning. SCM trigger on main repo change works, bot trigger on an external with this repo does not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into Subversion Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs. The main repo and all external repos are on the same server, I can't see any problems with credential configuration either.This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There is a similar issue like https://issues.jenkins-ci.org/browse/JENKINS-31869But that is a completely different version and years older.Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM.Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])]){code}Multibranch job is configured to *not* trigger when scanning. SCM trigger on main repo change works, bot trigger on an external with this repo does not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into Subversion Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs. The main repo and all external repos are on the same server, I can't see any problems with credential configuration either. This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There is a similar issue like https://issues.jenkins-ci.org/browse/JENKINS-31869But that is a completely different version and years older.Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM.Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])]){code}Multibranch job is configured to *not* trigger when scanning. Trigger SCM trigger on main repo change works fine , but externals do bot trigger on an external with this repo does not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into SCM Subversion Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs.This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There is a similar issue like https://issues.jenkins-ci.org/browse/JENKINS-31869But that is a completely different version and years older.Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM.Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])]){code} Multibranch job is configured to *not* trigger when scanning. Trigger on main repo change works fine, but externals do not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into SCM Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs.This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There is a similar issue like https://issues.jenkins-ci.org/browse/JENKINS-31869But that is a completely different version and years older.Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53201
Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Change By:
Edgars Batna
None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM. Jobs are configured somewhat like this:{code:java}properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '2000', numToKeepStr: '400')), [$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])]){code} Trigger on main repo change works fine, but externals do not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into SCM Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs.This is a major problem as builds no longer get updated correctly without any feedback.I added three components to the ticket as it's not obvious to me what causes it.If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM.There is a similar issue like https://issues.jenkins-ci.org/browse/JENKINS-31869But that is a completely different version and years older.Polling log looks like this (multiply this a thousand times for large repos):{code:java}Started on Aug 23, 2018 1:34:29 AMReceived SCM poll call on master for trunk on Aug 23, 2018 1:34:29 AMUsing sole credentials in realm ‘ VisualSVN Server’ERROR: Failed to check repository revision for https://repo/trunkorg.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at
[JIRA] (JENKINS-53201) Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Title: Message Title Edgars Batna created an issue Jenkins / JENKINS-53201 Poll SCM not triggering on any externals: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. Issue Type: Bug Assignee: Vincent Latombe Components: pipeline, pollscm-plugin, subversion-plugin Created: 2018-08-23 06:47 Environment: Windows Server Jenkins 2.137 Subversion 2.11.1 Pipeline 2.5 Pipeline API 2.29 ... (generally latest Pipeline to nearly latest other plugins) Priority: Major Reporter: Edgars Batna None of the Multibranch Pipeline jobs seem to be able to cope with externals using Poll SCM. Trigger on main repo change works fine, but externals do not. I'm not sure if it ever worked, but it's broken and totally not obvious unless you go into SCM Polling Log. Not only should this error not happen, but Poll SCM should be able to indicate errors without having to scrub through all logs. This is a major problem as builds no longer get updated correctly without any feedback. I added three components to the ticket as it's not obvious to me what causes it. If builds are triggered manually, they build fine. Whenever SCM triggers a build it builds also fine. Similar bug was fixed this year when a build was failing with same error during checkout, so I guess same fix should be applied to the Poll SCM. There is a similar issue like https://issues.jenkins-ci.org/browse/JENKINS-31869 But that is a completely different version and years older. Polling log looks like this (multiply this a thousand times for large repos): Started on Aug 23, 2018 1:34:29 AM Received
[JIRA] (JENKINS-53135) Multibranch Pipeline job nondescript error due to missing comma in properties([parameters([...
Title: Message Title
Edgars Batna created an issue
Jenkins / JENKINS-53135
Multibranch Pipeline job nondescript error due to missing comma in properties([parameters([...
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2018-08-20 14:10
Environment:
Windows Server 2008 R2 Java 1.8 Jenkins 1.137 Updated all plugins two weeks ago
Priority:
Minor
Reporter:
Edgars Batna
I define a job somewhat like this:
properties([
[$class: 'ScannerJobProperty', doNotScan: false],
buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '120', numToKeepStr: '200')),
parameters([
booleanParam(defaultValue: true, description: '', name: 'PARAM1'),
[$class: 'ValidatingStringParameterDefinition', defaultValue: '', description: '', failedValidationMessage: '', name: 'PARAM2', regex: ''],
[$class: 'ValidatingStringParameterDefinition', defaultValue: '', description: '', failedValidationMessage: '', name: 'PARAM3', regex: '']
[$class: 'ValidatingStringParameterDefinition', defaultValue: '', description: 'trunk', failedValidationMessage: '', name: 'PARAM4', regex: '.*']
]),
[$class: 'ScannerJobProperty', doNotScan: false],
pipelineTriggers([pollSCM('H H(0-5) * * *')])
])
The actual definition is way larger. If a comma is missing between to 'parameters' elements, then some odd Groovy magic happens and this exception is thrown:
[JIRA] (JENKINS-53135) Multibranch Pipeline job nondescript error due to missing comma in properties([parameters([...
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-53135
Multibranch Pipeline job nondescript error due to missing comma in properties([parameters([...
Change By:
Edgars Batna
I define a job somewhat like this:{code:java}properties([[$class: 'ScannerJobProperty', doNotScan: false], buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '120', numToKeepStr: '200')), parameters([booleanParam(defaultValue: true, description: '', name: 'PARAM1'), [$class: 'ValidatingStringParameterDefinition', defaultValue: '', description: '', failedValidationMessage: '', name: 'PARAM2', regex: ''],[$class: 'ValidatingStringParameterDefinition', defaultValue: '', description: '', failedValidationMessage: '', name: 'PARAM3', regex: ''][$class: 'ValidatingStringParameterDefinition', defaultValue: '', description: 'trunk', failedValidationMessage: '', name: 'PARAM4', regex: '.*']]),[$class: 'ScannerJobProperty', doNotScan: false],pipelineTriggers([pollSCM('H H(0-5) * * *')])]){code}The actual definition is way larger. If a comma is missing between to 'parameters' elements, then some odd Groovy magic happens and this exception is thrown:{noformat}org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:General error during canonicalization: java.lang.UnsupportedOperationExceptionjava.lang.UnsupportedOperationException at com.cloudbees.groovy.cps.CpsTransformer.visitMapEntryExpression(CpsTransformer.java:944) at org.codehaus.groovy.ast.expr.MapEntryExpression.visit(MapEntryExpression.java:39) at com.cloudbees.groovy.cps.CpsTransformer.visit(CpsTransformer.java:346) at com.cloudbees.groovy.cps.CpsTransformer.visit(CpsTransformer.java:352) at com.cloudbees.groovy.cps.CpsTransformer$29.run(CpsTransformer.java:956) at com.cloudbees.groovy.cps.CpsTransformer.makeChildren(CpsTransformer.java:435) at com.cloudbees.groovy.cps.CpsTransformer.makeNode(CpsTransformer.java:398) at com.cloudbees.groovy.cps.CpsTransformer.visitListExpression(CpsTransformer.java:953) at org.codehaus.groovy.ast.expr.ListExpression.visit(ListExpression.java:64) at com.cloudbees.groovy.cps.CpsTransformer.visit(CpsTransformer.java:346) at com.cloudbees.groovy.cps.CpsTransformer$24.run(CpsTransformer.java:834) at com.cloudbees.groovy.cps.CpsTransformer.makeChildren(CpsTransformer.java:435) at com.cloudbees.groovy.cps.CpsTransformer.makeNode(CpsTransformer.java:398) at com.cloudbees.groovy.cps.CpsTransformer.visitBinaryExpression(CpsTransformer.java:829) at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:51) at com.cloudbees.groovy.cps.CpsTransformer.visit(CpsTransformer.java:346) at com.cloudbees.groovy.cps.CpsTransformer.visit(CpsTransformer.java:352) at com.cloudbees.groovy.cps.CpsTransformer$29.run(CpsTransformer.java:956) at com.cloudbees.groovy.cps.CpsTransformer.makeChildren(CpsTransformer.java:435) at com.cloudbees.groovy.cps.CpsTransformer.makeNode(CpsTransformer.java:398)
[JIRA] (JENKINS-52908) Newlines get ignored in failure message and possibly stack trace when uploading xUnitDotNet xml results
Title: Message Title Edgars Batna commented on JENKINS-52908 Re: Newlines get ignored in failure message and possibly stack trace when uploading xUnitDotNet xml results Glad it's fixed so quickly. Though, test result formatting is not purely cosmetic. If you can't read them, you can't fix them. I'm not talking exception messages, but formatted tables with a thousand lines and over 10 columns. Thanks for looking into this in any case! Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-52908) Newlines get ignored in failure message and possibly stack trace when uploading xUnitDotNet xml results
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-52908
Newlines get ignored in failure message and possibly stack trace when uploading xUnitDotNet xml results
Change By:
Edgars Batna
We upload test results using Jenkinsfile like this:{code:java}xunit testTimeMargin: '3000', thresholdMode: 1, thresholds: [failed(), skipped()], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'tests\\results\\results.xml', skipNoTestFiles: false, stopProcessingIfError: true)]{code}This is the content of the results.xml:{code:java} OK: TestProcess.Execution.ExitCode == 0FAIL: Output differs from reference. Left: data\ref Right: results\out {code}The failure messages can be quite large for us and the newlines getting ignored makes them basically useless, thus I set this to Major priority.Things I've tried so far: # Enable newline escaping (we use our own framework to generate this XML in C#; note that in C# only CR gets escaped unless resorting to manual voodoo. This shouldn't be required, as LF is a valid character that should be preserved when loading by XML spec: [https://www.w3.org/TR/2004/REC-xml11-20040204/#sec-line-ends] ). # Using only CR or only LF. # Replacing newline characters with HTML , tags (this probably can't work, as the text is displayed in a tag) # Putting the message in a CDATA block and all of the above but within CDATA.Newlines should be easier than that.
Add Comment
This message was sent by Atlassian JIRA
[JIRA] (JENKINS-52908) Newlines get ignored in failure message and stack trace when uploading xUnitDotNet xml results
Title: Message Title Edgars Batna updated an issue Jenkins / JENKINS-52908 Newlines get ignored in failure message and stack trace when uploading xUnitDotNet xml results Change By: Edgars Batna Environment: Windows Server 2008 Jenkins 2.128XUnit 2.0.3 Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-52908) Newlines get ignored in failure message and possibly stack trace when uploading xUnitDotNet xml results
Title: Message Title Edgars Batna updated an issue Jenkins / JENKINS-52908 Newlines get ignored in failure message and possibly stack trace when uploading xUnitDotNet xml results Change By: Edgars Batna Summary: Newlines get ignored in failure message and possibly stack trace when uploading xUnitDotNet xml results Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-52908) Newlines get ignored in failure message and stack trace when uploading xUnitDotNet xml results
Title: Message Title Edgars Batna created an issue Jenkins / JENKINS-52908 Newlines get ignored in failure message and stack trace when uploading xUnitDotNet xml results Issue Type: Bug Assignee: Nikolas Falco Components: xunit-plugin Created: 2018-08-07 05:46 Environment: Windows Server 2008 Priority: Major Reporter: Edgars Batna We upload test results using Jenkinsfile like this: xunit testTimeMargin: '3000', thresholdMode: 1, thresholds: [failed(), skipped()], tools: [xUnitDotNet(deleteOutputFiles: true, failIfNotNew: false, pattern: 'tests\\results\\results.xml', skipNoTestFiles: false, stopProcessingIfError: true)] This is the content of the results.xml: "1.0" encoding="utf-8"?> "Test.exe" environment="OS: Microsoft Windows NT 6.2.9200.0" run-date="2018-38-06" run-time="02:38:04" test-framework="Test Framework 0.1" total="1" passed="0" failed="1" skipped="0" errors="0"> "collection1" time="36.7820544" total="1" passed="0" failed="1" skipped="0"> "collection1\test.xml" type="" method="" time="36.7820544" result="Fail"> OK: TestProcess.Execution.ExitCode == 0 FAIL: Output differs from reference. Left: data\ref Right: results\out
[JIRA] (JENKINS-32167) ISVNAuthentication provider did not provide credentials
Title: Message Title Edgars Batna commented on JENKINS-32167 Re: ISVNAuthentication provider did not provide credentials Any rough estimates for an ETA? More than half of builds are effectively background noise in our build system due to this. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-44240) Green Balls colorblind support no longer works
Title: Message Title Edgars Batna commented on JENKINS-44240 Re: Green Balls colorblind support no longer works The greenballs plugin should disable itself for certain users. In latest Jenkins color blind mode still doesn't work. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-33997) SVN "Emulate clean checkout" strategy doesn't revert property changes
Title: Message Title Edgars Batna commented on JENKINS-33997 Re: SVN "Emulate clean checkout" strategy doesn't revert property changes This should be reported as a bug. If something does not get deleted or reverted, then it's not a clean checkout. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-41805) Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
Title: Message Title Edgars Batna edited a comment on JENKINS-41805 Re: Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace. Not even sure why these directories would even be required. There are system-wide temporary directories that should be used for this. The temporary directories, no matter what implementation detail, should not concern us users. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-41805) Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
Title: Message Title Edgars Batna commented on JENKINS-41805 Re: Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace. Not even sure why these directories would even be required. There are system-wide temporary directories that should be used for this. The temporary directories, no matter what implementation detail, should not concern us users. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-44172) Better scan of multibranch pipelines
Title: Message Title Edgars Batna edited a comment on JENKINS-44172 Re: Better scan of multibranch pipelines Following features need to be clearly separated: # Load Jobs into Jenkins from SCM # Execute these JobsThe scanning of a multibranch pipeline should not be triggering anything at all and I bet there are other problems that require workarounds because of this . Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-44172) Better scan of multibranch pipelines
Title: Message Title Edgars Batna commented on JENKINS-44172 Re: Better scan of multibranch pipelines Following features need to be clearly separated: Load Jobs into Jenkins from SCM Execute these Jobs The scanning of a multibranch pipeline should not be triggering anything at all. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-49732) java.util.LinkedHashMap$Entry not serializable in Pipeline
Title: Message Title Edgars Batna commented on JENKINS-49732 Re: java.util.LinkedHashMap$Entry not serializable in Pipeline The workaround helps. Even if not soon, it should be looked at, get fixed or get a better error message. The latter would be a time-saver. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-38204) SVN plugin show all checkouts twice in pipeline project
Title: Message Title Edgars Batna commented on JENKINS-38204 Re: SVN plugin show all checkouts twice in pipeline project Any idea if this ever going to get fixed? In my case changesets get multiplied by 5 and I made sure to use 'changelog: false' wherever possible. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-49732) Cannot pass variable to checkout step locations
Title: Message Title Edgars Batna updated an issue Jenkins / JENKINS-49732 Cannot pass variable to checkout step locations Change By: Edgars Batna Environment: Jenkins 2.108 latest plugins Master: Windows 2008 R2 x64, 2.Slave: Windows 10 Pro x64 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-49732) Cannot pass variable to checkout step locations
Title: Message Title
Edgars Batna updated an issue
Jenkins / JENKINS-49732
Cannot pass variable to checkout step locations
Change By:
Edgars Batna
{code:java}def remote_watch_urls = [ './branches': 'my url/branches', './releases': 'my url/releases' ]for ( loc in remote_watch_urls ){ echo "remote_watch_urls server: ${loc.key}: ${loc.value}"}stage ('Get extension API versions'){ node('BUILD_WIN_64') { ws("w/${env.JOB_NAME}".replace('%', '_')) { stage("Checkout") { for ( loc in remote_watch_urls ) { echo "remote_watch_urls slave: ${loc.key}: ${loc.value}" checkout changelog: false, scm: [$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: [[credentialsId: 'my credentialsid', depthOption: 'infinity', ignoreExternalsOption: true, local: loc.key, remote: loc.value]], quietOperation: true, workspaceUpdater: [$class: 'UpdateWithCleanUpdater']] } } } }}{code}This is a minial script for repro. The checkout step fails and I'm not sure why. The echo steps work fine. There's more steps and stages after the checkout steps that's not included, but actually nothing prior to the posted script . {noformat} [BFA] Scanning build for known causes...[BFA] No failure causes found[BFA] Done. 2san exception which occurred: in field com.cloudbees.groovy.cps.impl.BlockScopeEnv.locals in object com.cloudbees.groovy.cps.impl.LoopBlockScopeEnv@e92a85 in field com.cloudbees.groovy.cps.impl.ProxyEnv.parent in object com.cloudbees.groovy.cps.impl.BlockScopeEnv@1fc9156 in field com.cloudbees.groovy.cps.impl.ProxyEnv.parent in object com.cloudbees.groovy.cps.impl.BlockScopeEnv@190fed5 in field com.cloudbees.groovy.cps.impl.CallEnv.caller in object com.cloudbees.groovy.cps.impl.FunctionCallEnv@1864fef in field com.cloudbees.groovy.cps.Continuable.e in object org.jenkinsci.plugins.workflow.cps.SandboxContinuable@ad9bff in field org.jenkinsci.plugins.workflow.cps.CpsThread.program in object org.jenkinsci.plugins.workflow.cps.CpsThread@1c261a6 in field org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.threads in object org.jenkinsci.plugins.workflow.cps.CpsThreadGroup@bdabe9 in object org.jenkinsci.plugins.workflow.cps.CpsThreadGroup@bdabe9Caused: java.io.NotSerializableException: java.util.LinkedHashMap$Entry at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:860) at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65) at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56) at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:50) at org.jboss.marshalling.river.RiverObjectOutputStream.writeObjectOverride(RiverObjectOutputStream.java:179) at
[JIRA] (JENKINS-49732) Cannot pass variable to checkout step locations
Title: Message Title
Edgars Batna created an issue
Jenkins / JENKINS-49732
Cannot pass variable to checkout step locations
Issue Type:
Bug
Assignee:
Unassigned
Components:
subversion-plugin
Created:
2018-02-26 09:27
Environment:
Jenkins 2.108 Master: Windows 2008 R2 x64, 2. Slave: Windows 10 Pro x64
Priority:
Minor
Reporter:
Edgars Batna
def remote_watch_urls = [
'./branches': 'my url/branches',
'./releases': 'my url/releases'
]
for ( loc in remote_watch_urls )
{
echo "remote_watch_urls server: ${loc.key}: ${loc.value}"
}
stage ('Get extension API versions')
{
node('BUILD_WIN_64') {
ws("w/${env.JOB_NAME}".replace('%', '_')) {
stage("Checkout") {
for ( loc in remote_watch_urls )
{
echo "remote_watch_urls slave: ${loc.key}: ${loc.value}"
checkout changelog: false, scm: [$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: [[credentialsId: 'my credentialsid', depthOption: 'infinity', ignoreExternalsOption: true, local: loc.key, remote: loc.value]], quietOperation: true, workspaceUpdater: [$class: 'UpdateWithCleanUpdater']]
}
}
}
}
}
This is a minial script for repro. The checkout step fails and I'm not sure why. The echo steps work fine. There's
[JIRA] (JENKINS-22129) H/2 * * * * is polling every second minute, but H/1 * * * * only once per hour
Title: Message Title Edgars B. commented on JENKINS-22129 Re: H/2 * * * * is polling every second minute, but H/1 * * * * only once per hour Amending the help would help. But... can't you fix this in 2.0+ and amend the help in older release? We're already on the latest Jenkins and things are already expected to break. Unless your backup strategy is very lacking, I do not see how improper configuration (which it sort of is) should hamper resolving an inconsistency. You can mention it in the changelog. I know I *always *read them. 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-22129) H/2 * * * * is polling every second minute, but H/1 * * * * only once per hour
Title: Message Title Edgars B. commented on JENKINS-22129 Re: H/2 * * * * is polling every second minute, but H/1 * * * * only once per hour Please don't pile inconsistency. Resolve it so that people learning to use Jenkins don't waste hours looking for such pathetically simple answers while trying to set up a simple timer trigger. 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] [core] (JENKINS-9104) Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed
Title: Message Title Edgars B. edited a comment on JENKINS-9104 Re: Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed Stumbled upon this issue immediately after trying parallel builds. Been open for 5 years now, so I guess you can simply check for 'mspdbsrv.exe' and leave it alone? Please free us of our pain. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-9104) Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed
Title: Message Title Edgars B. commented on JENKINS-9104 Re: Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed Stumbled upon this issue immediately after trying parallel builds. Been open for 5 years now, so I guess you can simply check for 'mspdbsrv.exe' and leave it alone? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [parameterized-trigger-plugin] (JENKINS-27255) Pass a file parameter to downstream job
Title: Message Title Edgars B. commented on JENKINS-27255 Re: Pass a file parameter to downstream job Both issues rely on the fact that files are not actually treated as real parameters when triggering downstream jobs. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [parameterized-trigger-plugin] (JENKINS-27255) Pass a file parameter to downstream job
Title: Message Title Edgars B. commented on JENKINS-27255 Re: Pass a file parameter to downstream job I do not think the mentioned "ParameterFactories" feature is what this feature request is about. There's currently no way to pass specific files to specific builds and "Current build paramters" doesn't even pass any files, which would be very self-explanatory and intuitive. See https://issues.jenkins-ci.org/browse/JENKINS-34112 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [parameterized-trigger-plugin] (JENKINS-27255) Pass a file parameter to downstream job
Title: Message Title Edgars B. edited a comment on JENKINS-27255 Re: Pass a file parameter to downstream job I do not think the mentioned "ParameterFactories" feature is what this feature request is about. There's currently no way to pass specific files to specific builds and "Current build paramters" doesn't even pass any files, which would be very self-explanatory and intuitive. For me the "ParameterFactories" suggestion is useless. See https://issues.jenkins-ci.org/browse/JENKINS-34112 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [parameterized-trigger-plugin] (JENKINS-34112) Invoke one build with all matching files
Title: Message Title Edgars B. edited a comment on JENKINS-34112 Re: Invoke one build with all matching files I need this too. All we need is that "Current build parameters" does pass all parameters and that passing the files by name in parameter list also passes them. It's self-explanatory.Note that in another JIRA issue the question was misunderstood and closed prematurely: https://issues.jenkins-ci.org/browse/JENKINS- 28958 27255 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [parameterized-trigger-plugin] (JENKINS-34112) Invoke one build with all matching files
Title: Message Title Edgars B. edited a comment on JENKINS-34112 Re: Invoke one build with all matching files I need this too. All we need is that "Current build parameters" does pass all parameters and that passing the files by name in parameter list also passes them. It's self-explanatory.Note that in another JIRA issue the question was misunderstood and closed prematurely: https://issues.jenkins-ci.org/browse/JENKINS-28958 That issue should be reopened. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [parameterized-trigger-plugin] (JENKINS-34112) Invoke one build with all matching files
Title: Message Title Edgars B. edited a comment on JENKINS-34112 Re: Invoke one build with all matching files I need this too. All we need is that "Current build parameters" does pass all parameters and that passing the files by name in parameter list also passes them. It's self-explanatory.Note that in another JIRA issue the question was entirely misunderstood and closed prematurely: https://issues.jenkins-ci.org/browse/JENKINS-28958That issue should be reopened. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [parameterized-trigger-plugin] (JENKINS-34112) Invoke one build with all matching files
Title: Message Title Edgars B. commented on JENKINS-34112 Re: Invoke one build with all matching files I need this too. All we need is that "Current build parameters" does pass all parameters and that passing the files by name in parameter list also passes them. It's self-explanatory. Note that in another JIRA issue the question was entirely misunderstood and closed prematurely: https://issues.jenkins-ci.org/browse/JENKINS-28958 That issue should be reopened. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [subversion-plugin] (JENKINS-14541) Option to checkout with --quiet (or equivalent)
Title: Message Title Edgars B. commented on JENKINS-14541 Re: Option to checkout with --quiet (or equivalent) Need this option here as well. Some repos are over 100k files and 100% of time I do not care for the files SVN lists in its output. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-18276) Archiving artifacts from a slave node is extremely slow even with 1.509.1+
Title: Message Title Edgars B. commented on JENKINS-18276 Re: Archiving artifacts from a slave node is extremely slow even with 1.509.1+ I do not even know where to start. On our build machines (similar setup) Jenkins has just finished a build and has been sitting there doing absolutely nothing for the last 1h, so I looked up the issue online. Hope for improvements. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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.
