[JIRA] (JENKINS-37584) P4 plugin : P4_CHANGELIST not available in workflow (pipeline)
Title: Message Title
Phil McArdle commented on JENKINS-37584
Re: P4 plugin : P4_CHANGELIST not available in workflow (pipeline)
Liran Vaknin, I'm not sure how to disable the groovy sandbox for scripts loaded from SCM, if you can, but you can alternatively add a function to the pipeline shared library to call the function for you. e.g. https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-steps
// vars/getEnvironmentWrapper.groovy
def call(String variableName) {
return currentBuild.rawBuild.getEnvironment()[variableName]
}
rawBuild isn't serializable, but you should get away with that in a standalone function. I can't say for sure because I have my helper function written into a larger class.
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-37584) P4 plugin : P4_CHANGELIST not available in workflow (pipeline)
Title: Message Title
Phil McArdle edited a comment on JENKINS-37584
Re: P4 plugin : P4_CHANGELIST not available in workflow (pipeline)
Liran Vaknin [~liranv] , I'm not sure how to disable the groovy sandbox for scripts loaded from SCM, if you can, but you can alternatively add a function to the [pipeline shared library|https://jenkins.io/doc/book/pipeline/shared-libraries/] to call the function for you.e.g.https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-steps{code:java}// vars/getEnvironmentWrapper.groovydef call(String variableName) {return currentBuild.rawBuild.getEnvironment()[variableName]}{code}rawBuild isn't serializable, but you should get away with that in a standalone function. I can't say for sure because I have my helper function written into a larger class.
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-41156) [Pipeline] Have shell and batch steps be renameable
Title: Message Title Phil McArdle commented on JENKINS-41156 Re: [Pipeline] Have shell and batch steps be renameable Looks like I wanted JENKINS-38442 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-41156) [Pipeline] Have shell and batch steps be renameable
Title: Message Title
Phil McArdle edited a comment on JENKINS-41156
Re: [Pipeline] Have shell and batch steps be renameable
Is there a separate bug for Blue Ocean not being able to visualize this, then? {code:java} node() {stage('Run Everything') {parallel firstBranch: {stage('Get Current Working Directory') {sh(script: 'pwd')}}, secondBranch: {stage('Test') {println 'Second Branch Test'}}}} {code}!screenshot.2255.jpg |thumbnail !
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-41156) [Pipeline] Have shell and batch steps be renameable
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41156 [Pipeline] Have shell and batch steps be renameable Change By: Phil McArdle Attachment: screenshot.2255.jpg 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-41156) [Pipeline] Have shell and batch steps be renameable
Title: Message Title
Phil McArdle commented on JENKINS-41156
Re: [Pipeline] Have shell and batch steps be renameable
Is there a separate bug for Blue Ocean not being able to visualize this, then? node() { stage('Run Everything') { parallel firstBranch: { stage('Get Current Working Directory') { sh(script: 'pwd') } }, secondBranch: { stage('Test') { println 'Second Branch Test' } } } }
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-41432) Perforce plugin doesn't always show changes in pipeline jobs
Title: Message Title
Phil McArdle commented on JENKINS-41432
Re: Perforce plugin doesn't always show changes in pipeline jobs
I think I finally figured this out. I've solved it by not using the 'pin' parameter, and instead using the magic 'change' parameter, and using #head instead of now. I think I had two problems. I finally noticed this in the log:
... p4 changes //workspace/...@no___ -
15:01:13 p4 changes //workspace/...@now,6242
Which, obviously, no changes. In this scenario the previous build had been run at the default 'now' using
pin: "${BUILD_CHANGELIST}"
and the current build had been sent 6242 as a parameter by the polling job. So I tried switching to #head as the default for the BUILD_CHANGELIST parameter, except:
... p4 changes //workspace/...@#h___ -
16:07:13 p4 changes //workspace/...@#head,6247
16:07:13
16:07:13 Unintelligible revision specification ''.
Again, same scenario, the previous build has been run successfully, manually, with #head as BUILD_CHANGELIST, and the current build has been sent 6247 from the polling job. So I tried switching to 'head', which works in the 'change' parameter, but pin doesn't accept that:
16:17:06 P4: Unable to find client/label/counter: head
So I'm now using the 'change' parameter, and I'm using 'head' as the default for it. New output:
16:43:19 [ParallelStageName] (p4):cmd:... p4 changes //workspace/___
16:43:19 [ParallelStageName] p4 changes //workspace/...@6251,6253
16:43:19 [ParallelStageName]
16:43:19 [ParallelStageName] Change 6253 on 2017/02/02 by phil.mcardle@PHIL-WS 'Test change
16:43:19 [ParallelStageName] '
16:43:19 [ParallelStageName] Change 6251 on 2017/02/02 by phil.mcardle@PHIL-WS 'Test change
16:43:19 [ParallelStageName] '
Again, the previous build was ran with 'change' 'head', but for the purposes of calling p4 changes in the current build, perforce has stored 6251 instead of head or now, so I get proper change detection. This is working, as far as I can tell, completely perfectly within the parallel setup I have, with only one of 3 syncs sending changelog: true to checkout as described in the description.
[JIRA] (JENKINS-41156) [Pipeline] Have shell and batch steps be renameable
Title: Message Title Phil McArdle commented on JENKINS-41156 Re: [Pipeline] Have shell and batch steps be renameable Excellent, 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-41432) Perforce plugin doesn't always show changes in pipeline jobs
Title: Message Title
Phil McArdle updated an issue
Jenkins / JENKINS-41432
Perforce plugin doesn't always show changes in pipeline jobs
Change By:
Phil McArdle
I wish I had a clean repro for this. I think it's likely to be due to the parallel though, as I assume if this was an issue normally someone else would have reported it.The visible evidence of the problem is that a given run of the job doesn't show changes in the UI (on the summary page for that job run, or the changes page), nor does the API show the changes when called directly (currentBuild.changeSets)However, the console output of the job will show output similar to:{noformat}[ParallelStageName] (p4):cmd:... p4 changes -m1 -ssubmitted //workspace___[ParallelStageName] p4 changes -m1 -ssubmitted //workspace/...[ParallelStageName] [ParallelStageName] Change number on date by user@workspace 'description[ParallelStageName] '...[ParallelStageName] P4 Task: saving built changes.OR (see code below)[ParallelStageName] P4 Task: changeLogFile not set. Not saving built changes.{noformat}Code is similar to:{code:java}def buildCommon(Map args) {checkout changelog: args.updateChangelog, poll: false, scm: [$class: 'PerforceScm', credential: '', populate: [$class: 'SyncOnlyImpl', have: true, modtime: false, pin: "${BUILD_CHANGELIST}", quiet: false, revert: true], workspace: [$class: 'TemplateWorkspaceImpl', charset: 'none', format: "", pinHost: true, templateName: ""]]}def buildVS(Map args) {buildCommon(args)}def buildGCC(Map args) {buildCommon(args)}def stages = [[, updateChangelog:true, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildGCC],]def builders = [:]for (stage in stages) {builders[] = {stage() {node() {ws() {buildCommand()}}}}}parallel builders{code}I've removed any variable names, and simplified a few things, but included every element that I think might be relevant.From one job run to the next I can't see any difference that explains why the perforce plugin isn't showing the changes in this run but did for several prior.Nor am I 100% sure how to cause it to work again. On some occasions, setting updateChangelog to true for all 3 syncs will cause it to work for a while, and then at some point later it will break and no subsequent job run will show changes.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: variable, which p4sync doesn't seem to expose. I suspect JENKINS-30614 might make this issue go away completely?Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the pol
[JIRA] (JENKINS-41432) Perforce plugin doesn't always show changes in pipeline jobs
Title: Message Title
Phil McArdle updated an issue
Jenkins / JENKINS-41432
Perforce plugin doesn't always show changes in pipeline jobs
Change By:
Phil McArdle
I wish I had a clean repro for this. I think it's likely to be due to the parallel though, as I assume if this was an issue normally someone else would have reported it. The visible evidence of the problem is that a given run of the job doesn't show changes in the UI (on the summary page for that job run, or the changes page), nor does the API show the changes when called directly (currentBuild.changeSets)However, the console output of the job will show output similar to:{noformat}[ParallelStageName] (p4):cmd:... p4 changes -m1 -ssubmitted //workspace___[ParallelStageName] p4 changes -m1 -ssubmitted //workspace/...[ParallelStageName] [ParallelStageName] Change number on date by user@workspace 'description[ParallelStageName] '...[ParallelStageName] P4 Task: saving built changes.OR (see code below)[ParallelStageName] P4 Task: changeLogFile not set. Not saving built changes.{noformat} Code is similar to:{code:java}def buildCommon(Map args) {checkout changelog: args.updateChangelog, poll: false, scm: [$class: 'PerforceScm', credential: '', populate: [$class: 'SyncOnlyImpl', have: true, modtime: false, pin: "${BUILD_CHANGELIST}", quiet: false, revert: true], workspace: [$class: 'TemplateWorkspaceImpl', charset: 'none', format: "", pinHost: true, templateName: ""]]}def buildVS(Map args) {buildCommon(args)}def buildGCC(Map args) {buildCommon(args)}def stages = [[, updateChangelog:true, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildGCC],]def builders = [:]for (stage in stages) {builders[] = {stage() {node() {ws() {buildCommand()}}}}}parallel builders{code}I've removed any variable names, and simplified a few things, but included every element that I think might be relevant.From one job run to the next I can't see any difference that explains why the perforce plugin isn't showing the changes in this run but did for several prior.Nor am I 100% sure how to cause it to work again. On some occasions, setting updateChangelog to true for all 3 syncs will cause it to work for a while, and then at some point later it will break and no subsequent job run will show changes.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: variable, which p4sync doesn't seem to expose. I suspect JENKINS-30614 might make this issue go away completely?Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the p
[JIRA] (JENKINS-41432) Perforce plugin doesn't always show changes
Title: Message Title
Phil McArdle updated an issue
Jenkins / JENKINS-41432
Perforce plugin doesn't always show changes
Change By:
Phil McArdle
Originally, I wish I had two pipeline jobs which are identical in a clean repro for this. I think it's likely to be due to the raw XML view parallel though , the newer of which experiences as I assume if this problem when trying was an issue normally someone else would have reported it.Code is similar to fetch P4 changes :{code:java}def buildCommon(Map args) {checkout changelog: args . Now updateChangelog , even poll: false, scm: [$class: 'PerforceScm', credential: '', populate: [$class: 'SyncOnlyImpl', have: true, modtime: false, pin: "${BUILD_CHANGELIST}", quiet: false, revert: true], workspace: [$class: 'TemplateWorkspaceImpl', charset: 'none', format: "", pinHost: true, templateName: ""]]}def buildVS(Map args) {buildCommon(args)}def buildGCC(Map args) {buildCommon(args)}def stages = [[, updateChangelog:true, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildGCC],]def builders = [:]for (stage in stages) {builders[] = {stage() {node() {ws() {buildCommand()}}}}}parallel builders{code}I've removed any variable names, and simplified a few things, but included every element that I think might be relevant.From one job run to the original jobs next I can show 't see any difference that explains why the same issue perforce plugin isn't showing the changes in this run but did for several prior . Nor am I 100% sure how to cause it to work again. On some occasions, setting updateChangelog to true for all 3 syncs will cause it to work for a while, and then at some point later it will break and no subsequent job run will show changes. In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables variable , which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the polling filter rules. This job is XML identical to an earlier job, and the newer one has the same problem - no changes seen in the UI or the API.(As an aside, when running perforce in the checkout step, I'm not sure it obeys poll:false but it's difficult to tell because the polling might have been setup from running p4sync once?)-To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.-This worked for a w
[JIRA] (JENKINS-41432) Perforce plugin doesn't always show changes in pipeline jobs
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Perforce plugin doesn't always show changes in pipeline jobs Change By: Phil McArdle Comment: I guess JENKINS-30614 would fix one of my issues :) 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-41432) Perforce plugin doesn't always show changes in pipeline jobs
Title: Message Title
Phil McArdle updated an issue
Jenkins / JENKINS-41432
Perforce plugin doesn't always show changes in pipeline jobs
Change By:
Phil McArdle
Comment:
Another update, and I wish I had a clean repro for this, even one of the original jobs now doesn't show changes in the UI or API despite the p4 commands within the job seeing them.Code is similar to:{code:java}def buildCommon(Map args) {checkout changelog: args.updateChangelog, poll: false, scm: [$class: 'PerforceScm', credential: '', populate: [$class: 'SyncOnlyImpl', have: true, modtime: false, pin: "${BUILD_CHANGELIST}", quiet: false, revert: true], workspace: [$class: 'TemplateWorkspaceImpl', charset: 'none', format: "", pinHost: true, templateName: ""]]}def buildVS(Map args) {buildCommon(args)}def buildGCC(Map args) {buildCommon(args)}def stages = [[, updateChangelog:true, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildGCC],]def builders = [:]for (stage in stages) {builders[] = {stage() {node() {ws() {buildCommand()}}}}}parallel builders{code}I've removed any variable names, and simplified a few things, but included every element that I think might be relevant.From one job run to the next I can't see any difference that explains why the perforce plugin isn't showing the changes in this run but did for several prior.Nor am I 100% sure how to cause it to work again.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41432) Perforce plugin doesn't always show changes in pipeline jobs
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Perforce plugin doesn't always show changes in pipeline jobs Change By: Phil McArdle Summary: Perforce plugin doesn't always show changes in pipeline jobs 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-41432) Perforce plugin doesn't always show changes
Title: Message Title
Phil McArdle updated an issue
Jenkins / JENKINS-41432
Perforce plugin doesn't always show changes
Change By:
Phil McArdle
I wish I had a clean repro for this. I think it's likely to be due to the parallel though, as I assume if this was an issue normally someone else would have reported it.Code is similar to:{code:java}def buildCommon(Map args) {checkout changelog: args.updateChangelog, poll: false, scm: [$class: 'PerforceScm', credential: '', populate: [$class: 'SyncOnlyImpl', have: true, modtime: false, pin: "${BUILD_CHANGELIST}", quiet: false, revert: true], workspace: [$class: 'TemplateWorkspaceImpl', charset: 'none', format: "", pinHost: true, templateName: ""]]}def buildVS(Map args) {buildCommon(args)}def buildGCC(Map args) {buildCommon(args)}def stages = [[, updateChangelog:true, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildVS],[, updateChangelog:false, buildCommand:this.&buildGCC],]def builders = [:]for (stage in stages) {builders[] = {stage() {node() {ws() {buildCommand()}}}}}parallel builders{code}I've removed any variable names, and simplified a few things, but included every element that I think might be relevant.From one job run to the next I can't see any difference that explains why the perforce plugin isn't showing the changes in this run but did for several prior.Nor am I 100% sure how to cause it to work again. On some occasions, setting updateChangelog to true for all 3 syncs will cause it to work for a while, and then at some point later it will break and no subsequent job run will show changes.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: variable, which p4sync doesn't seem to expose. I suspect JENKINS-30614 might make this issue go away completely? Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the polling filter rules. This job is XML identical to an earlier job, and evidences the newer one has the same problem - no changes seen in the UI or the API symptoms .(As an aside, when running perforce in the checkout step, I'm not sure it obeys poll:false but it's difficult to tell because the polling might have been setup from running p4sync once?) -To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.-This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built ch
[JIRA] (JENKINS-41432) Perforce plugin doesn't always show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Perforce plugin doesn't always show changes Change By: Phil McArdle Summary: Checkout step Perforce plugin doesn't always show changes 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-41432) Checkout step doesn't always show changes
Title: Message Title
Phil McArdle edited a comment on JENKINS-41432
Re: Checkout step doesn't always show changes
Another update, and I wish I had a clean repro for this, even one of the original jobs now doesn't show changes in the UI or API despite the p4 commands within the job seeing them.Code is similar to:{code:java}def buildCommon(Map args) { checkout changelog: args.updateChangelog, poll: false, scm: [$class: 'PerforceScm', credential: '', populate: [$class: 'SyncOnlyImpl', have: true, modtime: false, pin: "${BUILD_CHANGELIST}", quiet: false, revert: true], workspace: [$class: 'TemplateWorkspaceImpl', charset: 'none', format: "", pinHost: true, templateName: ""]]}def buildVS(Map args) { buildCommon(args)}def buildGCC(Map args) { buildCommon(args)}def stages = [[, updateChangelog:true, buildCommand:this.&buildVS], [, updateChangelog:false, buildCommand:this.&buildVS], [, updateChangelog:false, buildCommand:this.&buildGCC],]def builders = [:]for (stage in stages) { builders[] = { stage() {node() {ws() { buildCommand()}}}}}parallel builders{code}I've removed any variable names, and simplified a few things, but included every element that I think might be relevant.From one job run to the next I can't see any difference that explains why the perforce plugin isn't showing the changes in this run but did for several prior.Nor am I 100% sure how to cause it to work again.
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 uns
[JIRA] (JENKINS-41432) Checkout step doesn't always show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't always show changes Change By: Phil McArdle Originally, I had two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes. Now, even the original jobs can show the same issue.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the polling filter rules. This job is XML identical to an earlier job, and the newer one has the same problem - no changes seen in the UI or the API.(As an aside, when running perforce in the checkout step, I'm not sure it obeys poll:false but it's difficult to tell because the polling might have been setup from running p4sync once?)-To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.-This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built changes." and the command output as seen in the log sees the changes.I'm sorry I can't report a better bug for this. Latest comment might be more helpful: https://issues.jenkins-ci.org/browse/JENKINS-41432?focusedCommentId=285888&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-285888 Add Comment
[JIRA] (JENKINS-41432) Checkout step doesn't always show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't always show changes Change By: Phil McArdle Originally, I have had two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes. Now, even the original jobs can show the same issue. In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the polling filter rules. This job is XML identical to an earlier job, and the newer one has the same problem - no changes seen in the UI or the API.(As an aside, when running perforce in the checkout step, I'm not sure it obeys poll:false but it's difficult to tell because the polling might have been setup from running p4sync once?)-To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.-This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built changes." and the command output as seen in the log sees the changes. To clarify some more, I have 3 stages that run in parallel, all of which call checkout, and two of which send updateChangelog: false. In my latest case of it not working, I set all 3 stages to updateChangelog: true, ran it once, got 3 sets of identical changes, set 1 stage to true and the other 2 stages to false again, ran it again and it was fine.I 'm sorry I can't report a better bug for this. Add Comment
[JIRA] (JENKINS-41432) Checkout step doesn't show changes
Title: Message Title
Phil McArdle commented on JENKINS-41432
Re: Checkout step doesn't show changes
Another update, and I wish I had a clean repro for this, even one of the original jobs now doesn't show changes in the UI or API despite the p4 commands within the job seeing them. Code is similar to:
def buildCommon(Map args) {
checkout changelog: args.updateChangelog, poll: false, scm: [$class: 'PerforceScm', credential: '', populate: [$class: 'SyncOnlyImpl', have: true, modtime: false, pin: "${BUILD_CHANGELIST}", quiet: false, revert: true], workspace: [$class: 'TemplateWorkspaceImpl', charset: 'none', format: "", pinHost: true, templateName: ""]]
}
def buildVS(Map args) {
buildCommon(args)
}
def buildGCC(Map args) {
buildCommon(args)
}
def stages = [
[, updateChangelog:true, buildCommand:this.&buildVS],
[, updateChangelog:false, buildCommand:this.&buildVS],
[, updateChangelog:false, buildCommand:this.&buildGCC],
]
def builders = [:]
for (stage in stages) {
builders[] = {
stage() {
node() {
ws() {
buildCommand()
}
}
}
}
}
parallel builders
I've removed any variable names, and simplified a few things, but included every element that I think might be relevant. From one job run to the next I can't see any difference that explains why the perforce plugin isn't showing the changes in this run but did for several prior. Nor am I 100% sure how to cause it to work again.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41432) Checkout step doesn't always show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't always show changes Change By: Phil McArdle Summary: Checkout step doesn't always show changes 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-41571) Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods count java.lang.String java.lang.String and no option to whitelist
Title: Message Title Phil McArdle commented on JENKINS-41571 Re: Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods count java.lang.String java.lang.String and no option to whitelist I've found out, sort of, why the method doesn't show on the scriptApproval page. In my original job, the method call is nested deep within methods within a method adapted to a closure and ran from within parallel. I don't know exactly which part of that causes the problem, but, if I try the method from a vanilla pipeline job, I get a prompt on scriptApproval and the approval works everywhere. 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-41432) Checkout step doesn't show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't show changes Change By: Phil McArdle I have two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the polling filter rules. This job is XML identical to an earlier job, and the newer one has the same problem - no changes seen in the UI or the API.(As an aside, when running perforce in the checkout step, I'm not sure it obeys poll:false but it's difficult to tell because the polling might have been setup from running p4sync once?)-To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.-This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built changes." and the command output as seen in the log sees the changes.To clarify some more, I have 3 stages that run in parallel, all of which call checkout, and two of which send updateChangelog: false. In my latest case of it not working, I set all 3 stages to updateChangelog: true, ran it once, got 3 sets of identical changes, set 1 stage to true and the other 2 stages to false again, ran it again and it was fine.I'm sorry I can't report a better bug for this. Add Comment
[JIRA] (JENKINS-41432) Checkout step doesn't show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't show changes Change By: Phil McArdle I have two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync.I poll on a different job, but also using the checkout step, as the p4sync step doesn't expose the polling filter rules. This job is XML identical to an earlier job, and the newer one has the same problem - no changes seen in the UI or the API.(As an aside, when running perforce in the checkout step, I'm not sure it obeys poll:false but it's difficult to tell because the polling might have been setup from running p4sync once?)-To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.-This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built changes." and the command output as seen in the log sees the changes. To clarify some more, I have 3 stages that run in parallel, all of which call checkout, and two of which send updateChangelog: false. In my latest case of it not working, I set all 3 stages to updateChangelog: true, ran it once, got 3 sets of identical changes, set 1 to true and 2 to false again, ran it again and it was fine.I'm sorry I can't report a better bug for this. Add Comment
[JIRA] (JENKINS-41432) Checkout step doesn't show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't show changes Change By: Phil McArdle I have two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes. Firstly, in the UI, it shows 'No connection to perforce', despite the job itself having successfully used perforce multiple times. In currentBuild.changeSets I have one P4ChangeSet with one P4ChangeEntry which has empty msg fields, and a null id.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync. Also, I would like to only poll on one of these workspaces a different job , but it also using the checkout step, as the p4sync step doesn't seem expose the polling filter rules. This job is XML identical to obey an earlier job, and the newer one has the same problem - no changes seen in the UI or the API.(As an aside, when running perforce in the checkout step, I ' s m not sure it obeys poll:false setting - which isn but it ' t a huge issue for me as they're all addressing s difficult to tell because the same path. polling might have been setup from running p4sync once?) -To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.-This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built changes." and the command output as seen in the log sees the changes. Add Comment
[JIRA] (JENKINS-41432) Checkout step doesn't show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't show changes Change By: Phil McArdle Summary: Differences between checkout and p4sync Checkout step doesn't show changes 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-41432) Checkout step doesn't show changes
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Checkout step doesn't show changes Change By: Phil McArdle Attachment: summary_of_changes.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41432) Differences between checkout and p4sync
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Differences between checkout and p4sync Change By: Phil McArdle I have two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes.Firstly, in the UI, it shows 'No connection to perforce', despite the job itself having successfully used perforce multiple times.In currentBuild.changeSets I have one P4ChangeSet with one P4ChangeEntry which has empty msg fields, and a null id.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync. Also, I would like to only poll on one of these workspaces, but it doesn't seem to obey checkout's poll:false setting - which isn't a huge issue for me as they're all addressing the same path. ~ - To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time. ~ - This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built changes." and the command output as seen in the log sees the changes. Add Comment
[JIRA] (JENKINS-41432) Differences between checkout and p4sync
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-41432 Differences between checkout and p4sync Change By: Phil McArdle I have two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes.Firstly, in the UI, it shows 'No connection to perforce', despite the job itself having successfully used perforce multiple times.In currentBuild.changeSets I have one P4ChangeSet with one P4ChangeEntry which has empty msg fields, and a null id.In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose.Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync. Also, I would like to only poll on one of these workspaces, but it doesn't seem to obey checkout's poll:false setting - which isn't a huge issue for me as they're all addressing the same path. ~ To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time. ~This worked for a while, but once again both of the 'new' jobs using checkout don't report changes in the UI, though the console log says "saving built changes." and the command output as seen in the log sees the changes. Add Comment
[JIRA] (JENKINS-41156) [Pipeline] Have shell and batch steps be renameable
Title: Message Title Phil McArdle commented on JENKINS-41156 Re: [Pipeline] Have shell and batch steps be renameable Sean Sutherland, I'm looking for this same functionality, and I was keen to try your workaround, but I don't know where to get CpsThread from? 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-41571) Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods count java.lang.String java.lang.String and no option to whitelist
Title: Message Title Phil McArdle created an issue Jenkins / JENKINS-41571 Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods count java.lang.String java.lang.String and no option to whitelist Issue Type: Bug Assignee: Unassigned Components: script-security-plugin Created: 2017/Jan/30 7:22 PM Environment: Jenkins LTS: ver. 2.32.1 Script Security Plugin: 1.25 Priority: Minor Reporter: Phil McArdle Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods count java.lang.String java.lang.String Similar to JENKINS-35199, I have no option to whitelist this method on the script approvals page. Add Comment
[JIRA] (JENKINS-40879) Locked areas are executed multiple times in parallel
Title: Message Title
Phil McArdle commented on JENKINS-40879
Re: Locked areas are executed multiple times in parallel
I believe I hit the same issue. I have multiple stages queued to run in parallel, with some of them waiting on the same locks. My experience was that when any lock was released, all the locks seemed to be.
Lock acquired on resource 1 {
Lock acquired on resource 2 {
}
Lock acquired on resource 1 {
}
}
In my case, a second lock was being acquired on resource 1 long before the log or the pipeline steps view showed it being released. I've downgraded to 1.10 and it runs correctly. I'm not using inversePrecedence, quantity or label.
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-41446) ws step does not update WORKSPACE environment variable
Title: Message Title
Phil McArdle created an issue
Jenkins / JENKINS-41446
ws step does not update WORKSPACE environment variable
Issue Type:
Bug
Assignee:
Unassigned
Components:
workflow-durable-task-step-plugin
Created:
2017/Jan/25 6:14 PM
Environment:
Jenkins LTS ver. 2.32.1 Nodes and Processes Plugin 2.8
Priority:
Major
Reporter:
Phil McArdle
I consider this a bug, but feel free to reclassify.
node {
ws ('workspace/customDir') {
println "workspace: ${env.WORKSPACE}"
}
}
[Pipeline] node
Running on in E:\JenkinsRoot\workspace\Experiments\Test_Workspace
[Pipeline] {
[Pipeline] ws
Running in E:\JenkinsRoot\workspace\customDir
[Pipeline] {
[Pipeline] echo
workspace: E:\JenkinsRoot\workspace\Experiments\Test_Workspace
[Pipeline] }
[Pipeline] // ws
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
I can't find a way, in code, to get the path to the workspace after using the ws step. At the moment the only way I've found is to run a batch or shell script and get the current working directory from there. Please tell me if I'm missing something
[JIRA] (JENKINS-37584) P4 plugin : P4_CHANGELIST not available in workflow (pipeline)
Title: Message Title Phil McArdle commented on JENKINS-37584 Re: P4 plugin : P4_CHANGELIST not available in workflow (pipeline) For what it's worth, I just hit this. I get null unless I use the rawBuild workaround. Jenkins LTS ver. 2.32.1 p4-plugin 1.4.13 Jenkins is running on Debian 8.4, the slave that Jenkins chose for the job was Debian 8.6 Same behaviour when triggered by polling or manually. 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-41432) Differences between checkout and p4sync
Title: Message Title Phil McArdle commented on JENKINS-41432 Re: Differences between checkout and p4sync I guess JENKINS-30614 would fix one of my issues 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-41432) Differences between checkout and p4sync
Title: Message Title Phil McArdle created an issue Jenkins / JENKINS-41432 Differences between checkout and p4sync Issue Type: Bug Assignee: Unassigned Attachments: summary_of_changes.png Components: p4-plugin Created: 2017/Jan/25 3:26 PM Environment: Jenkins LTS ver. 2.32.1 p4-plugin 1.4.13 Priority: Major Reporter: Phil McArdle I have two pipeline jobs which are identical in the raw XML view, the newer of which experiences this problem when trying to fetch P4 changes. Firstly, in the UI, it shows 'No connection to perforce', despite the job itself having successfully used perforce multiple times. In currentBuild.changeSets I have one P4ChangeSet with one P4ChangeEntry which has empty msg fields, and a null id. In the job, I use the checkout step with PerforceScm, instead of using p4sync, because I need access to checkout's changelog: and poll: variables, which p4sync doesn't seem to expose. Use case: I sync the same depot path to multiple workspaces across multiple slaves in parallel for different tests, but if I don't use the checkout step with changelog: false, I will get identical sets of changes for as many times as I call p4sync. Also, I would like to only poll on one of these workspaces, but it doesn't seem to obey checkout's poll:false setting - which isn't a huge issue for me as they're all addressing the same path. To "fix" the new job, I replace every instance of checkout with a p4sync with otherwise identical parameters, run the job once, and then replace them with checkout again. After this, the job reports changes properly every time.
[JIRA] (JENKINS-40129) Extend GitChangeSet to get the repository name
Title: Message Title Phil McArdle commented on JENKINS-40129 Re: Extend GitChangeSet to get the repository name This would be a boon for us too. I don't mind having the changes, but I'd like to be able to filter 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-40046) Add option to disable internal shared library
Title: Message Title Phil McArdle commented on JENKINS-40046 Re: Add option to disable internal shared library Yep, sorry, meant to clarify. Totally in support of your request 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-40046) Add option to disable internal shared library
Title: Message Title Phil McArdle commented on JENKINS-40046 Re: Add option to disable internal shared library I just hit this. I don't know why or when it chooses to use the internal library, in my case. It was almost as if some files were from the new library, and some from the old, given my errors. I've deleted the contents of the internal library now. 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-34247) Option to use full populate options on p4sync pipeline step
Title: Message Title Phil McArdle resolved as Fixed Looks like this has been in for a while now, though I don't know when precisely Jenkins / JENKINS-34247 Option to use full populate options on p4sync pipeline step Change By: Phil McArdle Status: Open Resolved 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, v
[JIRA] [p4-plugin] (JENKINS-24490) 'Poll Only' or 'Disable Sync' option
Title: Message Title Phil McArdle commented on JENKINS-24490 Re: 'Poll Only' or 'Disable Sync' option I'm one of those people using 'Preview check only' for polling, once I got used to the behaviour. It's invaluable 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] [email-ext-plugin] (JENKINS-33980) Document (List) Pipeline features of email-ext-plugin
Title: Message Title
Phil McArdle edited a comment on JENKINS-33980
Re: Document (List) Pipeline features of email-ext-plugin
I'm fairly sure there's code for this on Stack Overflow somewhere, but, here's what I'm doing, if it'll help you. Obvious caveats for my primary use case at present is Perforce, I've cribbed this from a helper class I wrote for my own usage, and modified the opening line so you can see where I'm getting the data from. I've removed most comments - most of them say that I'm guessing the behaviour of specific classes or methods. Otherwise I just read the API docs and source code and iterate live in pipeline until I find the data I want. Edit: To caveat, I am neither an experienced Java or Groovy programmer. {code}def changeLogSets = currentBuild.rawBuild.changeSetsif (changeLogSets.size() > 0) {for (changeLogSet in changeLogSets) {// Not everyone implements ChangeLogSet the same way, so check for those we supportif (changeLogSet.class == org.jenkinsci.plugins.p4.changes.P4ChangeSet) {for (changeLog in changeLogSet) {def change = [:]// Common fieldschange.msg = changeLog.msgchange.msgAnnotated = changeLog.msgAnnotatedchange.msgEscaped = changeLog.msgEscapedchange.timestamp = changeLog.timestampchange.author = changeLog.authorchange.affectedPaths = changeLog.affectedPaths// Common fields not implemented the same by Perforcechange.affectedFiles = []for (file in changeLog.files) {// This is horrible, but Perforce returns files as FileSpec, while// Jenkins standard for affectedFiles is ChangeLogSet.AffectedFile, // and neither are compatible, so just return a fully annotated path insteadchange.affectedFiles.add("${file.toString()} ${file.getAction().toString()}")}change.commitId = changeLog.idchange.timestamp = changeLog.date// Perforce-specific fields (not a complete list)change.clientId = changeLog.clientIdm_Changes.add(change)}}}}{code}
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [email-ext-plugin] (JENKINS-33980) Document (List) Pipeline features of email-ext-plugin
Title: Message Title
Phil McArdle commented on JENKINS-33980
Re: Document (List) Pipeline features of email-ext-plugin
I'm fairly sure there's code for this on Stack Overflow somewhere, but, here's what I'm doing, if it'll help you. Obvious caveats for my primary use case at present is Perforce, I've cribbed this from a helper class I wrote for my own usage, and modified the opening line so you can see where I'm getting the data from. I've removed most comments - most of them say that I'm guessing the behaviour of specific classes or methods. Otherwise I just read the API docs and source code and iterate live in pipeline until I find the data I want.
def changeLogSets = currentBuild.rawBuild.changeSets
if (changeLogSets.size() > 0) {
for (changeLogSet in changeLogSets) {
// Not everyone implements ChangeLogSet the same way, so check for those we support
if (changeLogSet.class == org.jenkinsci.plugins.p4.changes.P4ChangeSet) {
for (changeLog in changeLogSet) {
def change = [:]
// Common fields
change.msg = changeLog.msg
change.msgAnnotated = changeLog.msgAnnotated
change.msgEscaped = changeLog.msgEscaped
change.timestamp = changeLog.timestamp
change.author = changeLog.author
change.affectedPaths = changeLog.affectedPaths
// Common fields not implemented the same by Perforce
change.affectedFiles = []
for (file in changeLog.files) {
// This is horrible, but Perforce returns files as FileSpec, while
// Jenkins standard for affectedFiles is ChangeLogSet.AffectedFile,
// and neither are compatible, so just return a fully annotated path instead
change.affectedFiles.add("${file.toString()} ${file.getAction().toString()}")
}
change.commitId = changeLog.id
change.timestamp = changeLog.date
// Perforce-specific fields (not a complete list)
change.clientId = changeLog.clientId
m_Changes.add(change)
}
}
}
}
Add Comment
This message was sent by Atlassian JIRA (v6
[JIRA] [p4-plugin] (JENKINS-34247) Option to use full populate options on p4sync pipeline step
Title: Message Title Phil McArdle updated an issue Jenkins / JENKINS-34247 Option to use full populate options on p4sync pipeline step Change By: Phil McArdle Apologies if this is already possible and I'm not seeing it, but would value (and eventually need) the full suite of populate options that the sync task has in regular freestyle projects, in pipeline jobs.e.g. 'Auto cleanup and sync', 'Forced clean and sync', 'Preview check only', 'Sync only', and their respective options.!populateoptions.png |thumbnail !I believe, from log output, that the p4sync step is using 'Auto cleanup and sync' at the moment, which is only really viable for us on smaller 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] [p4-plugin] (JENKINS-34247) Option to use full populate options on p4sync pipeline step
Title: Message Title Phil McArdle created an issue Jenkins / JENKINS-34247 Option to use full populate options on p4sync pipeline step Issue Type: Improvement Assignee: Unassigned Attachments: populateoptions.png Components: p4-plugin Created: 2016/Apr/14 3:49 PM Environment: Jenkins 1.656 p4-plugin 1.3.8 Pipeline 2.0 Priority: Major Reporter: Phil McArdle Apologies if this is already possible and I'm not seeing it, but would value (and eventually need) the full suite of populate options that the sync task has in regular freestyle projects, in pipeline jobs. e.g. 'Auto cleanup and sync', 'Forced clean and sync', 'Preview check only', 'Sync only', and their respective options. I believe, from log output, that the p4sync step is using 'Auto cleanup and sync' at the moment, which is only really viable for us on smaller jobs.
[JIRA] [p4-plugin] (JENKINS-33880) Option for viewing changes only without updating perfroce server
Title: Message Title Phil McArdle commented on JENKINS-33880 Re: Option for viewing changes only without updating perfroce server I don't know what your use case is, and I know this isn't a fix, but I worked around this by having a separate poll job apart from any of my 'worker' jobs with its own workspace, that triggered other jobs as appropriate. (I also needed this at the time because if I built one of the 'workers' at an older CL when polling was on the same workspace, it would immediately trigger polling - I don't know if this is still the case) Phil 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-26538) Less-trusted workflow-cps-global-lib
Title: Message Title Phil McArdle commented on JENKINS-26538 Re: Less-trusted workflow-cps-global-lib I would be curious as to what 'lesser permissions' would be here. I would be concerned about having every Jenkins user in my instance have access to edit scripts in cps-global-lib. (Also, this appears to be the only place that the permission required for this is documented.) 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-25979) Finish Groovy CPS coverage
Title: Message Title Phil McArdle commented on JENKINS-25979 Re: Finish Groovy CPS coverage Forgive me if part of this task is also adding the UnsupportedOperationException for these operators - only, the wording suggests the exception is already present, otherwise, I've stumbled across this because I tried to use a spread method call and received the following exception instead: hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: java.util.Collections$UnmodifiableRandomAccessList.getShortDescription() is applicable for argument types: () values: [] def rawCauses = currentBuild.rawBuild.getCauses() def causes = rawCauses*.getShortDescription() I then tried to use collect, and of course found JENKINS-26481 (I switched to a for loop) In both cases, it would be a huge advantage to someone learning Pipeline and Groovy if Jenkins would reject these with clear exceptions. 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] [p4-plugin] (JENKINS-31714) Truncated changelist description
Title: Message Title Phil McArdle commented on JENKINS-31714 Re: Truncated changelist description Duplicate of JENKINS-31748? 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] [p4-plugin] (JENKINS-24490) 'Poll Only' or 'Disable Sync' option
Title: Message Title Phil McArdle commented on JENKINS-24490 Re: 'Poll Only' or 'Disable Sync' option Thanks Paul, I thought it might turn out to be that, so I'll work with it I was sort of hoping that it was keeping track of a primitive 'polled changelist', but, the implemented solution is the better. 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] [p4-plugin] (JENKINS-24490) 'Poll Only' or 'Disable Sync' option
Title: Message Title Phil McArdle commented on JENKINS-24490 Re: 'Poll Only' or 'Disable Sync' option Forgive me, but, "Poll Only" and "the Workspace's have list is updated." seem to be at odds with each other? I'd have to use a different workspace for polling than I do for syncing to account for that, which, I can do, but isn't what I understood the intent of this feature request to be. 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] [p4-plugin] (JENKINS-24490) 'Poll Only' or 'Disable Sync' option
Title: Message Title Phil McArdle commented on JENKINS-24490 Re: 'Poll Only' or 'Disable Sync' option Sorry, Paul Allen, I fail to see how http://jenkins-ci.org/commit/p4-plugin/a03ebbaca53d95d5e9cfee83714c9e59cdea9080 relates to this feature request, nor can I see a Poll Only or Disable Sync feature in p4-plugin 1.3.3? 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] [p4-plugin] (JENKINS-31169) NullPointerException if user doesn't exist when collecting changes
Title: Message Title Phil McArdle created an issue Jenkins / JENKINS-31169 NullPointerException if user doesn't exist when collecting changes Issue Type: Bug Assignee: Unassigned Components: p4-plugin Created: 26/Oct/15 12:26 PM Environment: Jenkins: 1.634 P4 Plugin: 1.3.2 Priority: Minor Reporter: Phil McArdle (p4):stop:6 (p4):cmd:... p4 user -o username p4 user -o username (p4):stop:7 Unable to get current change: java.lang.NullPointerException FATAL: null java.lang.NullPointerException at org.jenkinsci.plugins.p4.changes.P4ChangeSet.store(P4ChangeSet.java:74) at org.jenkinsci.plugins.p4.PerforceScm.checkout(PerforceScm.java:346) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) Finished: FAILURE
