[JIRA] (JENKINS-37538) classloading issue with xerces lib
Title: Message Title Martin Vehovsky commented on JENKINS-37538 Re: classloading issue with xerces lib Hi Jesse Glick, can you please elaborate why such common utilities from Groovy shouldn't be used? Besides possible serialization issues that can be avoided if used right. For me, having these utilities is one of the main reasons why I use pipelines. 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-37538) classloading issue with xerces lib
Title: Message Title Martin Vehovsky edited a comment on JENKINS-37538 Re: classloading issue with xerces lib Thank you very much Nikolay! You saved me a lot of time investigating the cause. I can confirm disabling the jacoco plugin helped.I'll be watching the linked issue for the fix. Best regardsMartin 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-37538) classloading issue with xerces lib
Title: Message Title Martin Vehovsky commented on JENKINS-37538 Re: classloading issue with xerces lib Thank you very much Nikolay! You saved me a lot of time investigating the cause. I can confirm disabling the jacoco plugin helped. Best regards Martin 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-37538) classloading issue with xerces lib
Title: Message Title Martin Vehovsky commented on JENKINS-37538 Re: classloading issue with xerces lib Hi Nikolay, I'm also having this issue with the official docker LTS 2.32.1 image. Did you find any solution/workaround? Thanks 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-38963) User-scoped credentials cannot be looked up in pipeline
Title: Message Title
Martin Vehovsky commented on JENKINS-38963
Re: User-scoped credentials cannot be looked up in pipeline
Just found out, that it's possible to look-up user-scoped sredentials with '${Credentials}'
node {
withCredentials([[$class : 'UsernamePasswordMultiBinding', credentialsId: '${Credentials}',
usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
}
}
Could someone please clarify documentation for this? Thank you
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-38963) User-scoped credentials cannot be looked up in pipeline
Title: Message Title
Martin Vehovsky updated an issue
Jenkins / JENKINS-38963
User-scoped credentials cannot be looked up in pipeline
Change By:
Martin Vehovsky
It's possible to look-up User-scoped credentials in Freestyle jobs with Bindings. The same seems not to work in pipeline jobs.{code:java}node {withCredentials([[$class : 'UsernamePasswordMultiBinding', credentialsId: 'bc047678-37b8-4747-95d8-c1a8b3df51a6', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {echo "${env.USERNAME}"}}{code}{code:java}org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: bc047678-37b8-4747-95d8-c1a8b3df51a6 at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:124) at org.jenkinsci.plugins.credentialsbinding.impl.UsernamePasswordMultiBinding.bind(UsernamePasswordMultiBinding.java:68) at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution.start(BindingStep.java:92){code} Plugin versions:_credentials-binding: 1.9__credentials: 2.1.5_
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-38963) User-scoped credentials cannot be looked up in pipeline
Title: Message Title Martin Vehovsky updated an issue Jenkins / JENKINS-38963 User-scoped credentials cannot be looked up in pipeline Change By: Martin Vehovsky Summary: User-scoped credentials cannot be looked up with in pipeline 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-38963) User-scoped credentials cannot be looked up in pipeline
Title: Message Title
Martin Vehovsky updated an issue
Jenkins / JENKINS-38963
User-scoped credentials cannot be looked up in pipeline
Change By:
Martin Vehovsky
It's possible to look-up User-scoped credentials in Freestyle jobs with Bindings. The same seems not to works work in pipeline jobs.{code:java}node {withCredentials([[$class : 'UsernamePasswordMultiBinding', credentialsId: 'bc047678-37b8-4747-95d8-c1a8b3df51a6', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {echo "${env.USERNAME}"}}{code}{code:java}org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: bc047678-37b8-4747-95d8-c1a8b3df51a6 at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:124) at org.jenkinsci.plugins.credentialsbinding.impl.UsernamePasswordMultiBinding.bind(UsernamePasswordMultiBinding.java:68) at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution.start(BindingStep.java:92){code}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-38963) User-scoped credentials cannot be looked up with pipeline
Title: Message Title
Martin Vehovsky created an issue
Jenkins / JENKINS-38963
User-scoped credentials cannot be looked up with pipeline
Issue Type:
Bug
Assignee:
Unassigned
Components:
credentials-binding-plugin
Created:
2016/Oct/13 12:15 PM
Priority:
Major
Reporter:
Martin Vehovsky
It's possible to look-up User-scoped credentials in Freestyle jobs with Bindings. The same seems not to works in pipeline jobs.
node {
withCredentials([[$class : 'UsernamePasswordMultiBinding', credentialsId: 'bc047678-37b8-4747-95d8-c1a8b3df51a6',
usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
echo "${env.USERNAME}"
}
}
org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: bc047678-37b8-4747-95d8-c1a8b3df51a6
at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:124)
at org.jenkinsci.plugins.credentialsbinding.impl.UsernamePasswordMultiBinding.bind(UsernamePasswordMultiBinding.java:68)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution.start(BindingStep.java:92)
[JIRA] (JENKINS-31389) SVN changelog per build not taking into account locations of script vs. checkout step
Title: Message Title Martin Vehovsky resolved as Cannot Reproduce Cannot reproduce anymore.. Jenkins / JENKINS-31389 SVN changelog per build not taking into account locations of script vs. checkout step Change By: Martin Vehovsky Status: Reopened Resolved Resolution: Cannot Reproduce 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
[JIRA] (JENKINS-37889) Regression: Invoking static methods on global variables
Title: Message Title Martin Vehovsky closed an issue as Fixed Fixed in 2.3 Jenkins / JENKINS-37889 Regression: Invoking static methods on global variables Change By: Martin Vehovsky Status: Open Closed Resolution: 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-37889) Regression: Invoking static methods on global variables
Title: Message Title
Martin Vehovsky created an issue
Jenkins / JENKINS-37889
Regression: Invoking static methods on global variables
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
pipeline
Created:
2016/Sep/01 11:59 AM
Priority:
Blocker
Reporter:
Martin Vehovsky
There seems to be issue with invoking static methods on global variables after updating to Pipeline Shared Groovy Libraries Plugin 2.1. (I reverted back to 2.0 already) Following is supposed to work: workflowLibs/vars/TEST.groovy
def testMethod(String options = '') {
...
}
hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: static TEST.testMethod() is applicable for argument types: (java.lang.String) values: [47380]
Possible solutions: testMethod(java.lang.String), testMethod()
at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1367)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1353)
at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:50)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:15)
at WorkflowScript.run(WorkflowScript:6)
[JIRA] (JENKINS-34416) workflow-cps-global-lib: global variables are not global singletons
Title: Message Title
Martin Vehovsky edited a comment on JENKINS-34416
Re: workflow-cps-global-lib: global variables are not global singletons
Now that is peculiar, because [documentation|https://github.com/jenkinsci/workflow-cps-global-lib-plugin#defining-global-variables] doesn't say a word about the fact that global variables shouldn't be available in the [{{shared code}}|https://github.com/jenkinsci/workflow-cps-global-lib-plugin#writing-shared-code]. So I say the they are definitely not wrong. In {{Zot}} i simply want to access global variable {{acme}}. And I am able to access it. It's just not the same instance of the {{acme}} as it was in the {{pipeline}}.
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-34416) workflow-cps-global-lib: global variables are not global singletons
Title: Message Title
Martin Vehovsky edited a comment on JENKINS-34416
Re: workflow-cps-global-lib: global variables are not global singletons
Now that is peculiar, because [documentation|https://github.com/jenkinsci/workflow-cps-global-lib-plugin#defining-global-variables] doesn't say a word about the fact that global variables shouldn't be available in the [{{shared code}}|https://github.com/jenkinsci/workflow-cps-global-lib-plugin#writing-shared-code]. So I way say the are definitely not wrong. In {{Zot}} i simply want to access global variable {{acme}}. And I am able to access it. It's just not the same instance of the {{acme}} as it was in the {{pipeline}}.
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-34416) workflow-cps-global-lib: global variables are not global singletons
Title: Message Title Martin Vehovsky commented on JENKINS-34416 Re: workflow-cps-global-lib: global variables are not global singletons Now that is peculiar, because documentation doesn't say a word about the fact that global variables shouldn't be available in the shared code. So I way the are definitely not wrong. In Zot i simply want to access global variable acme. And I am able to access it. It's just not the same instance of the acme as it was in the pipeline. 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-34517) Pipeline is unable to locate global libraries when build attempts to continue on restart
Title: Message Title Martin Vehovsky commented on JENKINS-34517 Re: Pipeline is unable to locate global libraries when build attempts to continue on restart Yes, but I really don't want to rewrite all my workflows, just because of regression. 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-34517) Pipeline is unable to locate global libraries when build attempts to continue on restart
Title: Message Title
Martin Vehovsky reopened an issue
This introduced major regression, see below: There seems to be issue with invoking static methods on global variables after updating to 2.1. (I reverted back to 2.0 already) Following is supposed to work: workflowLibs/vars/TEST.groovy
def testMethod(String options = '') {
...
}
hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: static TEST.testMethod() is applicable for argument types: (java.lang.String) values: [47380]
Possible solutions: testMethod(java.lang.String), testMethod()
at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1367)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1353)
at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:50)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:15)
at WorkflowScript.run(WorkflowScript:6)
Jenkins / JENKINS-34517
Pipeline is unable to locate global libraries when build attempts to continue on restart
Change By:
Martin Vehovsky
Resolution:
Fixed
Status:
Resolved Reopened
[JIRA] (JENKINS-34517) Pipeline is unable to locate global libraries when build attempts to continue on restart
Title: Message Title Martin Vehovsky commented on JENKINS-34517 Re: Pipeline is unable to locate global libraries when build attempts to continue on restart davidkarlsen I would expect some feedback from Jesse Glick ... 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-34517) Pipeline is unable to locate global libraries when build attempts to continue on restart
Title: Message Title
Martin Vehovsky commented on JENKINS-34517
Re: Pipeline is unable to locate global libraries when build attempts to continue on restart
There seems to be issue with invoking static methods on global variables after updating to 2.1. (I reverted back to 2.0 already) Following is supposed to work: workflowLibs/vars/TEST.groovy
def testMethod(String options = '') {
...
}
hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: static TEST.testMethod() is applicable for argument types: (java.lang.String) values: [47380]
Possible solutions: testMethod(java.lang.String), testMethod()
at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1367)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1353)
at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:50)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:15)
at WorkflowScript.run(WorkflowScript:6)
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] [workflow-plugin] (JENKINS-34428) workflow-cps-global-lib: inheritance (extends) not working
Title: Message Title
Martin Vehovsky created an issue
Jenkins / JENKINS-34428
workflow-cps-global-lib: inheritance (extends) not working
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
workflow-plugin
Created:
2016/Apr/25 11:35 AM
Priority:
Major
Reporter:
Martin Vehovsky
I'm not able to use inheritance in Workflow Global Library code.
Here is a simple example to demonstrate:
// src/com/test/MyMap.groovy
package com.test
class MyMap extends HashMap {
def test(String property) {
super.get(property)
}
}
Add Comment
[JIRA] [workflow-plugin] (JENKINS-34416) workflow-cps-global-lib: global variables are not global singletons
Title: Message Title
Martin Vehovsky updated an issue
Jenkins / JENKINS-34416
workflow-cps-global-lib: global variables are not global singletons
Change By:
Martin Vehovsky
Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."Here is a very basic example to demonstrate it's not the case:{code:java}// vars/acme.groovydef setFoo(v) {this.foo = v;}def getFoo() {return this.foo;}{code}{code:java}// src/ com/foo/Zot.groovypackage com.foodef printAcmeFoo() {try {echo acme.foo} catch (e){echo "acme.foo is undefined"}}{code}And here is a pipeline:{code:java}import com.foo.Zotnode{acme.foo = "5"echo acme.foo;Zot z = new Zot()z.printAcmeFoo()}{code}Actually it shows 2 issues:1/ scripts in the vars directory are not singletons2/ when accessing undefined field pipeline will hang indefinitely
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] [workflow-plugin] (JENKINS-34416) workflow-cps-global-lib: global variables are not global singletons
Title: Message Title
Martin Vehovsky updated an issue
Jenkins / JENKINS-34416
workflow-cps-global-lib: global variables are not global singletons
Change By:
Martin Vehovsky
Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."Here is a very basic example to demonstrate it's not the case:{code:java}// vars/acme.groovydef setFoo(v) {this.foo = v;}def getFoo() {return this.foo;}{code} { { code:java} // com/foo/Zot.groovy }} {{ package com.foodef printAcmeFoo() {try {echo acme.foo} catch (e){echo "acme.foo is undefined"}} {code } } And here is a pipeline:{ { code:java} import com.foo.Zotnode{acme.foo = "5"echo acme.foo;Zot z = new Zot()z.printAcmeFoo()} {code } } Actually it shows 2 issues:1/ scripts in the vars directory are not singletons2/ when accessing undefined field pipeline will hang indefinitely
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] [workflow-plugin] (JENKINS-34416) workflow-cps-global-lib: global variables are not global singletons
Title: Message Title
Martin Vehovsky updated an issue
Jenkins / JENKINS-34416
workflow-cps-global-lib: global variables are not global singletons
Change By:
Martin Vehovsky
Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."Here is a very basic example to demonstrate it's not the case: { { code:java} // vars/acme.groovy }} {{ def setFoo(v) {this.foo = v;}def getFoo() {return this.foo;} {code } } {{ // com/foo/Zot.groovy }}{{package com.foodef printAcmeFoo() {try {echo acme.foo} catch (e){echo "acme.foo is undefined"And here is a pipeline:{{import com.foo.Zotnode{acme.foo = "5"echo acme.foo;Zot z = new Zot()z.printAcmeFoo()}}}Actually it shows 2 issues:1/ scripts in the vars directory are not singletons2/ when accessing undefined field pipeline will hang indefinitely
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] [workflow-plugin] (JENKINS-34416) workflow-cps-global-lib: global variables are not global singletons
Title: Message Title
Martin Vehovsky created an issue
Jenkins / JENKINS-34416
workflow-cps-global-lib: global variables are not global singletons
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
workflow-plugin
Created:
2016/Apr/24 7:51 AM
Environment:
Tested on Jenkins docker images 1.642.4 / 2.0-beta-2
Priority:
Critical
Reporter:
Martin Vehovsky
Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."
Here is a very basic example to demonstrate it's not the case:
{{ // vars/acme.groovy }} {{ def setFoo(v) { this.foo = v; }
def getFoo() { return this.foo; }
}}
{{ // com/foo/Zot.groovy }} {{ package com.foo
def printAcmeFoo() { try { echo acme.foo }
catch (e) { echo "acme.foo is undefined" }
} }}
And here is a pipeline: {{ import com.foo.Zot
node { acme.foo = "5" echo acme.foo; Zot z = new Zot() z.printAcmeFoo() }
}}
[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog per build not taking into account locations of script vs. checkout step
Title: Message Title Martin Vehovsky commented on JENKINS-31389 Re: SVN changelog per build not taking into account locations of script vs. checkout step Alright it's all a little differently. First of all, very sorry for misleading info, colleague changed SCM path in job config to /trunk. Interesting is why, because we had no changelogs on the workflow job at all. (just changes in the /trunk/tools/jenkins/worflow) It was probably caused by syntax we used: checkout poll: true, scm: [$class : 'SubversionSCM', ... ] I regenerated, using the syntax from Snippet Generator and all looks good now! 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] [workflow-plugin] (JENKINS-31389) SVN changelog per build not taking into account locations of script vs. checkout step
Title: Message Title Martin Vehovsky commented on JENKINS-31389 Re: SVN changelog per build not taking into account locations of script vs. checkout step All looks good except the polling. 1/ Polling log shows only /trunk/tools/jenkins/worflow and not bot /trunk 2/ exacly same polling log for 3 builds in a row: Example: Polling Log Started on 06-Nov-2015 11:25:06 Received SCM poll call on master for -icm_job_flow on 06-Nov-2015 11:25:06 trunk/tools/jenkins/workflow is at revision 24,266 (changed from 24,264) Done. Took 1.6 sec Changes found 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] [workflow-plugin] (JENKINS-31389) SVN changelog per build not taking into account locations of script vs. checkout step
Title: Message Title Martin Vehovsky edited a comment on JENKINS-31389 Re: SVN changelog per build not taking into account locations of script vs. checkout step All looks good except the polling. 1/ Polling log shows only _/trunk/tools/jenkins/worflow_ and not bot _/trunk_2/ exacly same polling log for 3 builds in a row:Example:Polling LogStarted on 06-Nov-2015 11:25:06Received SCM poll call on master for -icm_job_flow on 06-Nov-2015 11:25:06trunk/tools/jenkins/workflow is at revision 24,266 (changed from 24,264)Done. Took 1.6 secChanges found 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] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Martin Vehovsky edited a comment on JENKINS-31389 Re: SVN changelog on wrong build How can you close this, saying this inconsistent behaviour is ok??Off course we use second option, just because having job definitions in SCM is quite convenient.I have to say, that it 's pretty crappy behaviour, you can't say nothing about your build with certainty as you know NOTHING about what what changes did actually made it to your build!Really really disappointed about this! 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] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Martin Vehovsky commented on JENKINS-31389 Re: SVN changelog on wrong build How can you close this, saying this inconsistent behaviour is ok?? Off course we use second option, just because having job definitions in SCM is quite convenient. I have to say, that it pretty crappy behaviour, you can't say nothing about your build with certainty as you know NOTHING about what what changes did actually made it to your build! Really really disappointed about this! 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] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Martin Vehovsky commented on JENKINS-31389 Re: SVN changelog on wrong build No, no, no they definitely could not! That is why I specify SCM path in job config as for example /trunk/tools/jenkins/worflow. Changes in that and only that folder could influence the workflow script itself. Imagine that your build will fail and you want to investigate the reason. You will check the changelog for this build and no you are not finished you will have to check all the other builds that did NOTHING but containing changelog informations that was really taken to account in this build. Even more, you can't even send email to possible culprits because you have no way of knowing who that is really. You would blame someone for breaking the build, but the real revision that broke it would be in some previous builds. Looks to me that you are just trying to justify current implementation. Which is very cumbersome for users of your product. This 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] [core] (JENKINS-31389) Workflow plugin - SVN changelog on wrong build
Title: Message Title Martin Vehovsky created an issue Jenkins / JENKINS-31389 Workflow plugin - SVN changelog on wrong build Issue Type: Bug Assignee: Jesse Glick Components: core, workflow-plugin Created: 04/Nov/15 10:29 AM Environment: CentOS 7.1 Jenkins ver. 1.631 Workflow plugin 1.10.1 Priority: Critical Reporter: Martin Vehovsky For the sake of argument let's say you have simple single stage build #1 build is triggered - executing stage 1 #2 build is triggered - waiting for #1 (there were SVN changes #22, #23) #3 build is triggered - Superseds #2, waiting for #1 (there were SVN changes #24, #25) Build #2 was never executed, so SVN update was actually never triggered (General SCM step is inside the stage this build was waiting for). But still the revisions #22, #23 are in changelog of build #2. Build #3 actually did the SVN update. In console output I can see that files from revision #22 and #23 were updated. But ONLY revision #24, #25 are part of the changelog. This cannot be intended behaviour right?
